Subscriptions / recurring payments / standing orders

[jashan]

There may be more pressing issues right now, like wallet encryption and backup - but one issue I feel is a major limitation for quite a few use cases is that currently, there's no way of doing automatic recurring payments, e.g. for subscriptions.

Use case (this is just one example): A subscription based game service (multiplayer game). Players subscribe to the service and agree to do recurring payments. With the current client, I don't see a way to do this in any way that's convenient for the player. And when it's not convenient for the endusers, it will simply not be done. Other businesses that could benefit from such a feature would be magazines; for-pay online services (news services, professional networks etc.); support contracts and so on.

So, IMHO, as payments can only really be done from the client, the client needs some sort of subscription / recurring payment management. Basically, all it has to do is check whether there are any open recurring payments and if so, send them out. In case the client wasn't run for a longer while and it missed payments, the system might warn the user. The receiver would need to check if the subscription is still valid by checking whether or not the payment arrived in due time. So, the client would be responsible for sending it timely (one part of the "official protocol" could be: "subscriptions are cancelled by not paying in time"; and previous subscriptions could be resumed by paying again).

If you only switch your computer on every 3 days, you might want to send the payments 3 days early so you don't accidentally cancel one of your subscriptions. If you're away for a month, you might decide to do any upcoming payments for that time period immediately (which means that the receivers must be able to handle multiple simultaneous incoming payments; in other words: when I have a monthly subscription, and I get two payments one would be used for the current month, and the other one for the next).

Still, the greatest limitation of such a system is obviously that it only works when the user starts the client. So it should probably also be available for mobile, and ideally sync between different clients. It should be possible to prevent double-spending via the ordinary P2P-protocol (get the latest transactions from the blockchain, check if the necessary transaction was already done, if not, do it now). There's a little risk for simultaneous transactions - but that can be minimized by properly timing the different clients (e.g. have one client set to 8am, the other to 8pm, so there's 12 hours for the payment of the first client to distribute the transaction).

There might be optional 3rd party services that do the automated payments for you when you're offline (or even in general, if you so wish). Those could charge a little fee on top of the actual subscription rate. It should probably be a hard rule that each subscription *must* have its own receiving address (I think synching payments by receiving address is the most straightforward to implement). Using such a third party service, you could make sure that your local client sends the payment a day early; so usually the service would recognize it's already paid for and not do the transaction (which would save you the transaction fees). Only when your local client misses, it would kick in.

What might be really nice with such a system implemented directly into the client is that you have one central place where you store all the subscriptions you have. And unless you use a 3rd party service, your local computer is the only place where all your subscriptions are stored. Obviously, the client should provide some data with the subscription, like "Website of service provider", maybe even "terms and conditions that apply to the subscription", contact details. Basically, everything that's relevant to the subscription or pointers to that.

While having the currency itself decentralized, it's certainly much more customer friendly when we have all our subscriptions managed in one place (this is also one of the key selling factors for Apple's App Store subscriptions ... but they take 30%, and they all your subscriptions on their servers ... that's the problem when 3rd parties are involved; in the Bitcoin approach, 3rd parties would be completely optional). If there's 3rd party providers handling the payment of the subscriptions for you (as outlined above), there could be a protocol with which you can connect your client to your service provider, decide which subscription they should do, over which time that should work and transfer both the subscriptions and a few BTC so they can be paid for (and the subscriptions could automatically be sent with the "1-day delay" so things work smoothly without having to think of too much complex stuff ;-) ).

My feeling is that this can really be done in a way that makes it very easy and safe for the user, even though there might be quite a bit of complexity going on in the background.

So when this is done right, it could be one more step in Bitcoin taking over the world. While it's obviously possible to implement that as an extension, my feeling is that it would be wise to have this as a part of the "main package" because that way, a standard could be created that other implementations can follow. Ideally, if you change clients, your subscriptions would still work on the new client. IMHO, aside from some other, smaller usability issues and some pressing security issues, that's one "big thing" that could help Bitcoin become interesting for the masses.

There already are subscription services by Apple, and I think something similar is also available for Android (any PayPal also has it), and as a developer I can say: This is really great, I'd love to use it - BUT: I really don't want a 3rd party to take 30% ... and I think there's quite a few developers out there feeling that way, too. If Bitcoin could provide an alternative that just works - OMG, that would rock (admittedly, quite a bit of the infrastructure that Apple / Google are providing would have to be done by the developers in the Bitcoin approach; but saving 30% would probably be worth it in many cases ... even if you'd have to add the "Apple way" as an option to comply with their terms in their world)! ;-)

What do you think?

[sublimnl]

Very interesting... think I have a solution to provide

[theymos]

You could send transactions with an nLockTime equal to the subscription due date. (nLockTime is an already-existing feature that prohibits a transaction from being accepted into a block until a certain time.) Send this transaction to the service a month ahead of time, and then you don't need to be online at the payment time. You can cancel it at any time.

[jashan]

Ah, cool - I wasn't aware this already exists. So, probably 3rd party services aren't even needed - awesome, that simplifies things.

Are there any other fields currently not exposed that one should be aware of? Is there documentation available or does one have to read the source code to get that kind of information? Would that be: https://en.bitcoin.it/wiki/Protocol_specification ? So that would be lock_time there, right?

[theymos]

Yes, it's lock_time. Each input's "sequence" is also related to this.

There are many features that are not exposed. Check out:
https://en.bitcoin.it/wiki/Contracts
https://en.bitcoin.it/wiki/Script

[bji]

You could send transactions with an nLockTime equal to the subscription due date. (nLockTime is an already-existing feature that prohibits a transaction from being accepted into a block until a certain time.) Send this transaction to the service a month ahead of time, and then you don't need to be online at the payment time. You can cancel it at any time.

Cool.  So I can run miners out of disk space by just creating a zillion transactions with nLockTime 10 years in the future and they'll all have to store all of my transactions for 10 years?

[theymos]

They don't have to store it. The network will forget about your 0-confirmation transactions after a few days if you don't rebroadcast them.

[bji]

They don't have to store it. The network will forget about your 0-confirmation transactions after a few days if you don't rebroadcast them.

Then what's the point of broadcasting a 'subscription' transaction with an nLockTime days or months into the future, if the transaction is just going to get dropped long before the time it is 'due'?  Or am I misunderstanding the suggestion that was given for using nLockTime transactions for subscriptions?

Of course, I could still keep miner's disks pretty full if I broadcast say 1000 nLockTime transactions an hour.  Basically if i want to force miners to waste 100 MB of disk space, I just have to transmit 100 MB of nLockTime transactions per day; each day when miners eliminate old cruft, they just get more from me.  I get some 'friends' to do the same and now miners are wasting lots of disk space and burning lots of network bandwidth accepting these transactions.

[SgtSpike]

Automated payments = bleh.

What I'd like to see is a 3rd party payment processing service that automatically sends emails with a total amount due and remit-to address to my subscribers every X number of days before their bill is due.  If payment is not received by the due date, their account will be disabled.

[JoelKatz]

Then what's the point of broadcasting a 'subscription' transaction with an nLockTime days or months into the future, if the transaction is just going to get dropped long before the time it is 'due'?  Or am I misunderstanding the suggestion that was given for using nLockTime transactions for subscriptions?

None. But you don't have to broadcast it. Sending it to just the recipient is sufficient.

Of course, I could still keep miner's disks pretty full if I broadcast say 1000 nLockTime transactions an hour.  Basically if i want to force miners to waste 100 MB of disk space, I just have to transmit 100 MB of nLockTime transactions per day; each day when miners eliminate old cruft, they just get more from me.  I get some 'friends' to do the same and now miners are wasting lots of disk space and burning lots of network bandwidth accepting these transactions.

They'll just add rules to drop those transactions. It doesn't matter if miners hold them. So long as there exists some person with a financial interest in those transactions, they'll hold them. And one person with an interest in getting them into the chain is better than 1,000 people with no such interest.

[bji]

Of course, I could still keep miner's disks pretty full if I broadcast say 1000 nLockTime transactions an hour.  Basically if i want to force miners to waste 100 MB of disk space, I just have to transmit 100 MB of nLockTime transactions per day; each day when miners eliminate old cruft, they just get more from me.  I get some 'friends' to do the same and now miners are wasting lots of disk space and burning lots of network bandwidth accepting these transactions.

They'll just add rules to drop those transactions. It doesn't matter if miners hold them. So long as there exists some person with a financial interest in those transactions, they'll hold them. And one person with an interest in getting them into the chain is better than 1,000 people with no such interest.

I agree with what you are saying as the ideal (and eventual) behavior of the system.  But I don't know what the current state of the art is in bitcoin client and miner code.  Are these systems currently vulnerable to such shenanigans?  Or are protections already in place?

I have to say that my reading of the 'official' bitcoin client code revealed a very, very disturbing lack of defensive coding.  Not encrypting the wallet file was an obvious and glaring omission but there are innumerable other aspects to the code that make it look much more like a prototype and much less like a client written to handle money in a trustworthy fashion.

I don't know if typical miner code is any different.

[JoelKatz]

I agree with what you are saying as the ideal (and eventual) behavior of the system.  But I don't know what the current state of the art is in bitcoin client and miner code.  Are these systems currently vulnerable to such shenanigans?  Or are protections already in place?

The client is not currently coded to resist attacks that seek to temporarily disable or cripple mining and transaction committing. This is needed.

I have to say that my reading of the 'official' bitcoin client code revealed a very, very disturbing lack of defensive coding.  Not encrypting the wallet file was an obvious and glaring omission but there are innumerable other aspects to the code that make it look much more like a prototype and much less like a client written to handle money in a trustworthy fashion.

Not encrypting the wallet was a deliberate, and IMO correct, design decision. See this post for my explanation of why:
http://forum.bitcoin.org/index.php?topic=23138.msg294358#msg294358

[jashan]

And one person with an interest in getting them into the chain is better than 1,000 people with no such interest.

So, what would be needed is that the merchant "client" recognizes those timed transaction, stores them and retransmits them when the time is due, right? How can this be achieved?

You can cancel it at any time.

Is there a mechanism that assures that when I cancel the timed transaction, and the merchant has stored it and retransmits it, it's still cancelled?

[theymos]

Is there a mechanism that assures that when I cancel the timed transaction, and the merchant has stored it and retransmits it, it's still cancelled?

The way you cancel it is by sending a locked transaction using the same coins. Then your other transaction becomes invalid.

If the merchant is malicious, you would want to cancel the transaction a few days before it becomes locked. Otherwise they have a chance of getting their version in a block before your version.