<ol>
<li>In order to send someone Bitcoins, you need to sign a transaction with your private key.</li>
<li>Each transaction on your set of coins refers to the previous transaction. It is possible to create a daisy chain of transactions like this, but if you'd perform any operation in between the start and the finish of such sets of payments, the remaining transactions would be invalidated.</li>
</ol>

<p>This makes it impossible under current model of transactions to perform such an operation. You could define a new OP that would allow one to redeem coins only after a certain amount of time, but then you'd be paying the full amount up front anyway.</p>

<p>You could, however, create a client that would be scheduling payments. But there is a problem - it is generally advised to keep your private keys encrypted, so nobody could steal your coins. A client can't sign a transaction with an encrypted key, so you'd have to be prompted for passwords every time. On the other hand, one could imagine a single address in a wallet to be kept unencrypted for such transactions. In the end though, it is not a matter of creating a new OP in the protocol, but new functionality in a client.</p>

CC BY-SA 3.0
2012-01-24T21:42:22.993Z
I'm thinking of something like having an address I could fund from which the subscription service could pull the subscription fee every 4320 blocks (1 month) say. I could fund it with whatever amount I wanted, e.g. 1 years worth of subscription fees, but the service could only pull the set amount each subscription period. If I wanted I could move the bitcoins out of the pre-funded address anytime I wanted without any permissions needed from anyone else and stop the subscription. Is this possible?
kirian
CC BY-SA 3.0
2012-01-25T00:45:06.527Z
@kirian You'd have to have some modified client for this. You need to sign with your private key for every transaction that is to take place. Currently something like this is not available, but maybe in a couple months I should have some eWallet going that could do something like this. For now, everyone's paranoid about having their coins stolen.
ThePiachu
CC BY-SA 3.0
2012-01-26T22:05:01.047Z
All you would need is a "not valid before block X" (or block with timestamp Y) transaction. You could then hand them transactions for each month in the next year, and you could remove the funds at any time prior to them taking the payments.
David Schwartz
CC BY-SA 3.0
2012-01-24T21:18:29.227Z
2012-01-24T21:18:29.227Z
ThePiachu
<p>Is it possible to implement a subscription/recurring payment type using Bitcoin scripts? </p>

<p>For example, you could send a payment for a service where there is a monthly subscription say, and each month if there was enough bitcoin in the paying address the required amount would be sent to the service provider. The time could be based on block number, which should correlate well with time, i.e. a monthly payment could be a payment every 4320 blocks.</p>

<protocol><script><recurring-payments>
Will any of the proposed Scripts (OP_XXX) allow subscription/recurring type payments?
kirian
# Will any of the proposed Scripts (OP_XXX) allow subscription/recurring type payments?

(Asked by: username_0 on 2012-01-24)

Is it possible to implement a subscription/recurring payment type using Bitcoin scripts?

For example, you could send a payment for a service where there is a monthly subscription say, and each month if there was enough bitcoin in the paying address the required amount would be sent to the service provider. The time could be based on block number, which should correlate well with time, i.e. a monthly payment could be a payment every 4320 blocks.

**Tags:** protocol, script, recurring-payments


---

## 1 answers

### Answer by username_1 on 2012-01-24. Score: 3 | Accepted answer

1. In order to send someone Bitcoins, you need to sign a transaction with your private key.
2. Each transaction on your set of coins refers to the previous transaction. It is possible to create a daisy chain of transactions like this, but if you'd perform any operation in between the start and the finish of such sets of payments, the remaining transactions would be invalidated.

This makes it impossible under current model of transactions to perform such an operation. You could define a new OP that would allow one to redeem coins only after a certain amount of time, but then you'd be paying the full amount up front anyway.

You could, however, create a client that would be scheduling payments. But there is a problem - it is generally advised to keep your private keys encrypted, so nobody could steal your coins. A client can't sign a transaction with an encrypted key, so you'd have to be prompted for passwords every time. On the other hand, one could imagine a single address in a wallet to be kept unencrypted for such transactions. In the end though, it is not a matter of creating a new OP in the protocol, but new functionality in a client.

> **Comments:**
> **username_0**: I'm thinking of something like having an address I could fund from which the subscription service could pull the subscription fee every 4320 blocks (1 month) say. I could fund it with whatever amount I wanted, e.g. 1 years worth of subscription fees, but the service could only pull the set amount each subscription period. If I wanted I could move the bitcoins out of the pre-funded address anytime I wanted without any permissions needed from anyone else and stop the subscription. Is this possible?  
> **username_1**: @username_0 You'd have to have some modified client for this. You need to sign with your private key for every transaction that is to take place. Currently something like this is not available, but maybe in a couple months I should have some eWallet going that could do something like this. For now, everyone's paranoid about having their coins stolen.  
> **username_2**: All you would need is a "not valid before block X" (or block with timestamp Y) transaction. You could then hand them transactions for each month in the next year, and you could remove the funds at any time prior to them taking the payments.  

---

