Crypto News & ICO Reviews
One of the problems with any changetip replacement is that it'd have to store people's BTC, requiring a large amount of trust. Here's a idea for a similar service that doesn't ever store BTC, somewhat inspired by old-Ripple. I just had this idea a couple hours ago, so what's written here is surely very rough, but I don't see why it couldn't work for small amounts. It's still centralized, and if the service was hacked or became evil then there would be some opportunity for theft due to misdirection, but it's quite a bit more limited than changetip was.
Alice, Bob, and Carol register as recipients with the service. They each give the service a receiving address (or, even better, a master public key so that addresses don't need to be reused). The registration process might be to mail the tipbot a message like, "register MY_ADDRESS".
Let's say that the service will avoid having people send transactions with a value lower than $20 to reduce total fees.
On separate occasions, Dean tells the tipbot "send Carol $5", "send Bob $10", and "send Alice $5". Dean doesn't actually pay anything yet. The service now has tables like this:
Dean's payments are listed as unconfirmed because he hasn't actually paid anything yet. When asked to pay for these tips later, he might refuse.
For the system to get bootstrapped, some users need to initially be marked as trusted, and their tips would immediately go into the To-Receive category. Eugene and Fred are two such trusted users. Eugene tells the tipbot to "send Alice $10" and "send Bob $10", and Fred tells the tipbot to "send Alice $5". The tables now look like:
Alice is now owed 20 total dollars: $15 in the trusted to-receive column, and $5 from Dean. Dean now receives mail form the tipbot telling him to send $20 in BTC (at the current price) to Alice's address. Note that nobody else but Dean could've been asked to pay for Dean's $5 tip, since this tip is unconfirmed. (In a database, you'd actually have an additional table with a schema like (Sender, Recipient) -> (Owed BTC).) Once Dean's BTC payment is confirmed, the tables look like:
The rest of the $20 that Dean sent earlier is now moved from the Unconfirmed to the To-Receive category, since that $20 is now entirely paid for. Now Bob is owed $20 (or more) and Eugene owes $20, so Eugene is asked to pay $20 to Bob, giving tables:
The result is that $45 dollars was sent by the system, $40 has reached its destination, and $5 is still pending. At no point did the system itself need to hold any BTC, though it did provide the addresses into which people should pay, which it could've lied about. For increased security, you could have the service publish all of its data and let everyone independently check that it's operating correctly. On Reddit, users could post their addresses to a Reddit wiki, and then senders could check the edit history of the wiki to confirm the address's ownership.
Note that I used dollars everywhere above. Because the values sit for a while, it's probably not good to use BTC as a unit of account here, since it is very price-volatile. If you denominated things in BTC, you could have someone send BTC worth $20 via the system one day and then have to settle for BTC worth $25 or something weeks later. You could still have people tell the tipbot "send Alice 1000 bits" or whatever, but then internally this should probably be converted to a more stable unit of account. (You could try denominating it in BTC, and the system wouldn't break, but I think that people would end up finding it uncomfortable.)
If an untrusted user defaults on his payments, nothing bad happens as long as no action was taken based on the payment. When recipients receive a notification of an incoming untrusted payment, it should be made clear that this is merely an IOU with absolutely no guarantee that it will actually be paid. Once it moves into the "to-receive" category, then recipients can be told that they will likely receive the payment at some point.
If a trusted user defaults on his payments, then some arbitrary recipients end up losing the defaulted-on value. Since the values are quite small, and a trusted user could be further limited to a total trusted debt of $100 or whatever (with any excess being listed as unconfirmed), I don't consider this to be a huge problem. I'm not sure how many trusted users / trusted payments will be needed. If there are too few trusted payments going on, then payments will keep getting stuck in the unconfirmed state.
If recipients want to cash out at a balance under the automatic payout limit ($20 in the above examples, though it could be anything), then they could still request a manual payout, but then a fee would be added to cover the on-chain transaction fee. So if Bob had a to-receive balance of $10, he could request an immediate payout. Then some random person with an appropriate amount of debt would be chosen to pay this, but although their debt would be reduced by $10, they would only have to pay ($10 – FEE) in BTC. FEE would be chosen to correspond to roughly the cost of a normal on-chain transaction at the time. Other than this, I am tentatively thinking that senders should always pay the on-chain fee when settling.
Senders could also choose to settle early. If you only tip small amounts very rarely, then it'd take you a long time to reach the $20 (or whatever) payout limit otherwise, and so your intended recipients would have to wait a long time to receive your money. There should also be a fee associated with this, since it fragments the recipient's wallet more than usual, increasing their future fees. (Ie. if you wanted to settle for $10, you'd actually have to pay $10 + SEND_FEE, plus the on-chain fee for the transaction itself.) Maybe the tipbot should encourage people to pay early if they retain an IOU balance for many months, since otherwise recipients might find the often-unpaid IOUs annoying.
So in summary, how it would work for recipients is:
- You send the tipbot a message
- Someone sends you a tip via the bot, and you get a notice telling you that you've received a very-low-reliability IOU.
- Eventually, you'll get a notice telling you that your very-low-reliability IOU has now moved into the "to-receive" category, and so you can now actually consider it really-received.
- Once your total to-receive balance is above the automatic payout limit, you'll eventually get that amount or less sent to your Bitcoin address on-chain, and your to-receive balance will be correspondingly reduced.
- Hopefully-very-rarely, a trusted user can default, in which case your to-receive balance will be reduced without you receiving any BTC. This happens when a trusted user is selected to settle your to-receive amount, but doesn't pay. Note that you cannot consider payments from the previous step to be invalid due to this, since those users were unrelated to the default.
How it would work for senders is:
- You send the tipbot a message
send $x to RECIPIENT.
- At some point, you'll receive mail from the tipbot saying
send $x to SOME_ADDRESS, where $x is no more than the value of all of your past unsettled tips. Usually this will happen shortly after the sender reaches an unsettled balance equal to the automatic payout limit, but it can also happen at other times.
If you think long enough about improving this system, you'll probably end up recreating old-Ripple or Lightning. For example, you can eliminate the concept of globally trusted users by instead having senders loan BTC in advance to chosen people, and then forming a web-of-trust lending network based on who people choose to lend to. That's old-Ripple, more-or-less. Add payment channels so that the loans are not really loans and you more-or-less have Lightning. But I'm just trying to present an easy-to-use and easy-to-implement Reddit tipbot here, not a revolutionary new way of making Bitcoin payments.