Bitcoin Forum
December 06, 2016, 04:07:31 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Subscriptions / recurring payments / standing orders  (Read 1461 times)
jashan
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 26, 2011, 01:11:30 PM
 #1

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?

If you like this posting - feel free to give a tip:
1HrTEoRXbNG3GeCodpUZazTWCsjytijmkH

Keep those Bitcoins flowing :-)

Want to buy or sell Bitcoins? Sign up with TradeHill Exchange and get a 10% discount on your commission rates for life!
http://www.tradehill.com/?r=TH-R1180
1481040451
Hero Member
*
Offline Offline

Posts: 1481040451

View Profile Personal Message (Offline)

Ignore
1481040451
Reply with quote  #2

1481040451
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481040451
Hero Member
*
Offline Offline

Posts: 1481040451

View Profile Personal Message (Offline)

Ignore
1481040451
Reply with quote  #2

1481040451
Report to moderator
1481040451
Hero Member
*
Offline Offline

Posts: 1481040451

View Profile Personal Message (Offline)

Ignore
1481040451
Reply with quote  #2

1481040451
Report to moderator
sublimnl
Member
**
Offline Offline

Activity: 97


View Profile
June 26, 2011, 01:51:10 PM
 #2

Very interesting... think I have a solution to provide Wink
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
June 26, 2011, 06:57:51 PM
 #3

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jashan
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 27, 2011, 11:36:03 AM
 #4

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?

If you like this posting - feel free to give a tip:
1HrTEoRXbNG3GeCodpUZazTWCsjytijmkH

Keep those Bitcoins flowing :-)

Want to buy or sell Bitcoins? Sign up with TradeHill Exchange and get a 10% discount on your commission rates for life!
http://www.tradehill.com/?r=TH-R1180
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
June 27, 2011, 07:57:51 PM
 #5

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
bji
Member
**
Offline Offline

Activity: 112


View Profile
June 27, 2011, 08:45:14 PM
 #6

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
June 27, 2011, 10:53:50 PM
 #7

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
bji
Member
**
Offline Offline

Activity: 112


View Profile
June 27, 2011, 11:24:14 PM
 #8

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
Legendary
*
Offline Offline

Activity: 1344



View Profile
June 27, 2011, 11:35:41 PM
 #9

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
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 12:32:02 AM
 #10

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.

Quote
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 am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
bji
Member
**
Offline Offline

Activity: 112


View Profile
June 28, 2011, 12:39:40 AM
 #11


Quote
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
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 12:43:37 AM
 #12

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.

Quote
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

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
jashan
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 28, 2011, 05:48:11 AM
 #13

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?

If you like this posting - feel free to give a tip:
1HrTEoRXbNG3GeCodpUZazTWCsjytijmkH

Keep those Bitcoins flowing :-)

Want to buy or sell Bitcoins? Sign up with TradeHill Exchange and get a 10% discount on your commission rates for life!
http://www.tradehill.com/?r=TH-R1180
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
June 28, 2011, 06:04:06 AM
 #14

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!