Subscription Model - OP_CHECK_HEIGHT?

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

Quote from: gmaxwell on October 01, 2012, 09:08:24 PM

Quote from: BkkCoins on October 01, 2012, 06:43:49 AM

The only way would be if enough balance was on hand in each of enough separate outputs (or groups) to uniquely use them for each future date.
Does that sound right?

No. Not quite. The bitcoin protocol has no concept of balances. A new transaction redeems old transactions. Transaction can only be redeemed once. Think of coins and the network is a forge that can combine them and split them. You can write a transaction which can't be included in the blockchain until a particular time/height.. but it has to identify which coins it's spending. Not balances. Groups. Etc. The specific coins. And until its in the chain you could spend those coins out from under it.

Yes, Understood. I was using the term balance and group as a way of explaining what I meant as in a group of outputs acting as a balance that I could use as inputs. Such that if I could group outputs into sets where each set totaled "a balance" then each set could be used as inputs to create a separate future dated transaction.

I'm sure I understand how it works but didn't use technically clear language. I also understand that until the transaction is inserted someday the outputs could be used and accepted that to be similar to Paypal when someone doesn't have enough funds on hand.

The main problem with this that makes it useless is that at the time of subscribing the customer would have to have on hand enough for the whole subscription term and enough separate outputs available for each period transaction. And then they would have to not accidentally use them. Basically a special wallet dedicated to the subscription would have to be setup to keep things straight.

In other words it's all too difficult and fragile to be workable this way.

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: BkkCoins on October 01, 2012, 06:43:49 AM

The only way would be if enough balance was on hand in each of enough separate outputs (or groups) to uniquely use them for each future date.
Does that sound right?

No. Not quite. The bitcoin protocol has no concept of balances. A new transaction redeems old transactions. Transaction can only be redeemed once. Think of coins and the network is a forge that can combine them and split them. You can write a transaction which can't be included in the blockchain until a particular time/height.. but it has to identify which coins it's spending. Not balances. Groups. Etc. The specific coins. And until its in the chain you could spend those coins out from under it.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Mike Hearn on October 01, 2012, 05:59:46 AM

I think the simplest/most intuitive way to implement this is for mobile wallet apps to know how to wake up and send money for recurring subscriptions.

Ding. Supply side automation is the way to go.

One of the nice things about bitcoin is that there is no pull capability, the closest you can get is pull requests.

One possible way to do pull requests... You tell your wallet that it can automatically push transactions out if they come in signed, according to limits set by you for each key. Your cable company gives you a key, and you allow it to pull up to X bitcoins each month, and your power company's key is allowed up to Y BTC per month. Any requests that come in unsigned are discarded, and anything over the limits is queued up for manual approval.

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

So let me understand this fully. The address the customer wants to potentially spend from has one or more outputs available. You could create a transaction from those output now, and store it, send it later if. If the outputs still were unused later it would work.

But you couldn't re-use the same outputs later with copies of the transaction as they would have already been used. And you have no other outputs at this time.

The only way would be if enough balance was on hand in each of enough separate outputs (or groups) to uniquely use them for each future date.

Does that sound right?

Mike Hearn

legendary

Activity: 1526

Merit: 1134

Right, exactly. The reason why you may not want to pay up front is as the OP mentions, you can cancel your subscription by just spending the money that was allocated for the subscription service. It's a bit of an odd arrangement though.

I think the simplest/most intuitive way to implement this is for mobile wallet apps to know how to wake up and send money for recurring subscriptions. As most people keep their phones on all the time, this is a simple/robust way to have cron-job style payments.

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: BkkCoins on October 01, 2012, 05:30:06 AM

Does some script like this already exist or could one be created? Wouldn't it then just depend on a special client program to create and manage such transactions? Any issues here?

We already have LOCKTIME which does what you're asking, but doesn't do what you want.

The locktime field on a transaction lets you specify the earliest time or height that the transaction can be included at.

It doesn't do what you want because you can't spend an input you don't have— so you'd have to have and freeze the funds you will use in advance. And since they're stuck in place— why not just pay up front? ... There can be reasons, yes, but I don't think it really fits the subscription use case where you don't necessarily have the funds up front.

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

I don't know if this has been solved yet already but I was thinking about the subscription model that Paypal has and how to offer it with Bitcoin.

It seems to me that a simple script output (eg. OP_CHECK_HEIGHT) could be used that checks the block height on pre-signed transactions that would make sure a transaction would not be acepted on the network until a certain block height had been reached.

A customer could sign such a transaction (or series of them) and the merchant could store them to submit at a later block height.

This should work similar to subscribed Paypal payments as they still depend on a balance being on the input address in order to go thru. So a customer could cut the subscription off at any time by withdrawing / not depositing sufficient funds on the address. And the merchant at that time would warn / cancel services.

Does some script like this already exist or could one be created? Wouldn't it then just depend on a special client program to create and manage such transactions? Any issues here?

Topic: Subscription Model - OP_CHECK_HEIGHT? (Read 831 times)