<p>This is a solved problem, see <a href="https://bitcointalk.org/index.php?topic=25786.0" rel="nofollow">https://bitcointalk.org/index.php?topic=25786.0</a> and <a href="https://en.bitcoin.it/wiki/Contracts#Example_7%3a_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party" rel="nofollow">this</a>.</p>

<p>It has also been recently implemented in BitcoinJ, and called "Micropayment channels".</p>

CC BY-SA 3.0
2013-08-19T22:23:43.560Z
2013-08-19T22:23:43.560Z
Meni Rosenfeld
<blockquote>
<p>When they shake hands, A can instantly show that document to B and B can verify that the document produces the correct hash.</p>
</blockquote>
<p>But in order to verify that the document produces that hash, B would need to put it into a computer, which he could program to steal the document and make the transaction.</p>
<blockquote>
<p>Can Script allow a transaction to be cancelled if its outputs are not used a specified timeframe?</p>
</blockquote>
<p>There was a proposal a while back that would have allowed that - it gave scripts access to the block number of the block it was included into. It was <a href="https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119" rel="nofollow noreferrer">ultimately rejected</a>:</p>
<blockquote>
<p>We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.  The OP_BLOCKNUMBER transaction and all its dependants would become invalid.  This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.</p>
<p>nTimeLock does the reverse.  It's an open transaction that can be replaced with new versions until the deadline.  It can't be recorded until it locks.  The highest version when the deadline hits gets recorded.  It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline.  The feature isn't enabled or used yet, but the support is there so it could be implemented later.</p>
</blockquote>
<p>Here's the current best-practices for an escrow transaction: You send your bitcoins to a 2-of-3 escrow account controlled by me, you, and an escrow agent.</p>
<ul>
<li>If the trade completes sucessfully, then we transfer the bitcoins to your account.</li>
<li>If we decide not to go through with the trade, then we transfer the bitcoins back to my account.</li>
<li>If the escrow agent gets hacked, then we're ok because the hackers don't have the ability to steal the money without our cooperation.</li>
<li>If we can't agree for whatever reason, then the escrow agent will arbitrate somehow.</li>
</ul>
<p>This isn't a bulletproof scheme. For example, if we do the trade, and I then convince the escrow agent that you never held up your end, then I can get both the item you were selling and the bitcoins back.</p>

CC BY-SA 3.0
2013-04-16T23:44:46.650Z
*"But in order to verify that the document produces that hash, B would need to put it into a computer, which he could program to steal the document and make the transaction."*   That's the whole point!  There is no stealing here.  A has decided to give B the document because the deal has been done, which B can then use to claim the output.
Aaron McDaid
CC BY-SA 3.0
2013-04-16T23:49:54.797Z
... the purpose is to make it impossible for A to double spend.  The transaction from A->B will happen if and only if somebody (typically, B) can produce a document with the relevant hash.
Aaron McDaid
CC BY-SA 3.0
2013-04-16T23:55:43.367Z
@AaronMcDaid Ok, then suppose that after getting the item, A just walks off.
Nick ODell
CC BY-SA 3.0
2013-04-16T23:58:26.333Z
"*... A just walks off ..*". Nobody is pretending that can be solved :-)  The purpose is to avoid the embarrassing/inconvenient need for people to hang around waiting for 6 confirmations.  The instant that A gives the document to B and gets the item in return, B knows he/she has the money.
Aaron McDaid
CC BY-SA 3.0
2013-04-17T00:24:50.660Z
@AaronMcDaid Ah. I misunderstood. I thought you were trying to solve a different problem. You could do what you're suggesting by having A put the money in a 2-of-2 account. When A gets the item, he signs a transaction that puts the money in an account controlled entirely by B. B checks the destination address, then countersigns it. Since a double-spend out of the escrow account would require B's signature, he's safe.
Nick ODell
CC BY-SA 3.0
2013-04-17T00:51:00.887Z
Thanks @NickODell, that makes more sense.  But that does run the risk of both parties refusing to sign, and the money being stuck in the escrow forever.  I'd like some guarantee that the money will end up somewhere eventually.
Aaron McDaid
CC BY-SA 3.0
2013-04-17T00:55:27.967Z
I have another (incomplete) idea. What about using that nTimeLock feature such that the escrow will create a transaction that sends the money back to A again and that it will "go through unless it is revoked before the deadline" (as you quoted) and only A is able to revoke it.  When A gives the revoke code to B, then A has sacrified the money 'instantly'.
Aaron McDaid
CC BY-SA 3.0
2013-04-17T00:58:59.647Z
@AaronMcDaid I have to be honest that I don't really understand the intended security model of nLockTime, so I'm of limited help there. I do know that it's currently ignored by the bitcoin client.
Nick ODell
CC BY-SA 3.0
2013-04-16T23:35:28.003Z
2013-04-16T23:35:28.003Z
2020-06-16T11:10:03.350Z
Nick ODell
<p>This is largely an agreement with Nick ODell's answer, but it was too long to put in a comment and I don't want suggest adding a bunch of extraneous things to his answer.</p>

<p>There are ways that you could give your Person B the ability to instantly have access to the funds. For example, just creating a new account, sending the money there with a normal transaction, and then providing them with the private key for that account when they deliver the product. But the problem with that approach is that there is no way that the recipient could verify that you haven't already used the private key to create a double spend just before you give them the private key. They could only be certain you haven't spent the output already by moving it to a new address and then waiting for the six confirmations. (Which fails to meet your objective. And there's no way around it. The point of the 6 transactions is to confirm no conflicting spends.)</p>

<p>You could avoid this problem by creating a transaction that you couldn't spend yourself ahead of time. For example, a 2of2 transaction that requires a private key that they already own as well as the private key you just created. But, as you point out, the problem with that approach is that if they elect not to complete the transaction there is no way to "revoke" the transaction. You can't claim it (by design) and they can't claim it either.</p>

<p>So, although I haven't done a rigorous proof here, I think the only theoretical way to solve this use case would be to have one thing they control, one thing you control, and one third thing that is "in escrow". As @NickODell points out, the block number would be an interesting way to do time based escrow. (And the <a href="https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit" rel="nofollow noreferrer">contracts page on the bitcoin.it wiki</a> leads me to think that it would be possible in a couple of ways.) But without replacement transactions or some other way to allow you to undo this if the deal doesn't work out I think the only way to do this would be manual escrow. ( See <a href="https://bitcoin.stackexchange.com/questions/861/why-isnt-transaction-replacement-supported">this answer</a> for some answers on replacement transactions. )</p>

CC BY-SA 3.0
2013-04-17T15:49:28.677Z
2013-04-17T15:49:28.677Z
2017-04-13T12:47:36.647Z
David Ogren
<p>(Clarification: This is <em>not</em> an attempt to solve the problem of a vendor taking the money and running without handing over the merchandise.  Problems like that can't be solved without some third party.  The purpose here is for A to give bitcoin to B, where B can be <em>instantly</em> certain that he has access to the bitcoin.)</p>

<p>I have an idea that depends on the <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow">Script</a> system in Bitcoin, but maybe I'm asking too much.  It would allow for instant confirmations between parties who arrange a negotiation a few hours in advance.  I don't know very much about Script though.  Is the following scheme possible?  Would extensions to the Script be required?</p>

<p>Person A and Person B are going to meet in a few hours for a business deal.  If all goes well, they hope to shake hands and A will want to instantly send some BTC to B.</p>

<p>In advance, A publishes a transaction that sends the money to B.  By the time the meeting occurs it will have received enough confirmations.  But this won't be a normal transaction.  It should include some further conditions:</p>

<p>First, the transaction should include a hash, such that the transaction won't complete unless a document is produced which has that hash.</p>

<p>When they shake hands, A can instantly show that document to B and B can verify that the document produces the correct hash.  B can then be confident that the transaction will be processed fully later when he produces the document.</p>

<p>There is no double-spending problem here.  The output of the special transaction has already been locked to send to B, it cannot be sent anywhere else.</p>

<p>We need a way to rollback this if A and B do not reach agreement.  Can Script allow a transaction to be cancelled if its outputs are not used a specified timeframe?  I guess not.  (Partially cancelled, the transaction fee should remain valid.)</p>

<p>Another approach to this rollback is for the special transaction to also include a special output which sends <em>all</em> the money back to another of A's address.  But this should have some sort of time lock on it, such that it isn't allowed to happen until a suitable delay, 24 hours, has occured.  Is it possible for the outputs to be <em>double</em> the total inputs in a case like this, where maybe we can prove that only one output can be claimed?  (I envisage having non-overlapping timelocks on both transactions in order.)</p>

CC BY-SA 3.0
2013-04-17T00:31:17.767Z
I think this would be best addressed on [bitcointalk](http://bitcointalk.org).
Colin Dean
CC BY-SA 3.0
2013-04-17T01:11:23.207Z
This is a great question. If this were possible, it would allow in-person transactions to be pre-confirmed and finalised at the time of the exchange, and rolled back if the exchange didn't proceed.
Highly Irregular
<transactions><script><confirmations>
Instant confirmations with pre-published, locked, transactions
Aaron McDaid
# Instant confirmations with pre-published, locked, transactions

(Asked by: username_0 on 2013-04-16)

(Clarification: This is *not* an attempt to solve the problem of a vendor taking the money and running without handing over the merchandise. Problems like that can't be solved without some third party. The purpose here is for A to give bitcoin to B, where B can be *instantly* certain that he has access to the bitcoin.)

I have an idea that depends on the [Script](https://en.bitcoin.it/wiki/Script) system in Bitcoin, but maybe I'm asking too much. It would allow for instant confirmations between parties who arrange a negotiation a few hours in advance. I don't know very much about Script though. Is the following scheme possible? Would extensions to the Script be required?

Person A and Person B are going to meet in a few hours for a business deal. If all goes well, they hope to shake hands and A will want to instantly send some BTC to B.

In advance, A publishes a transaction that sends the money to B. By the time the meeting occurs it will have received enough confirmations. But this won't be a normal transaction. It should include some further conditions:

First, the transaction should include a hash, such that the transaction won't complete unless a document is produced which has that hash.

When they shake hands, A can instantly show that document to B and B can verify that the document produces the correct hash. B can then be confident that the transaction will be processed fully later when he produces the document.

There is no double-spending problem here. The output of the special transaction has already been locked to send to B, it cannot be sent anywhere else.

We need a way to rollback this if A and B do not reach agreement. Can Script allow a transaction to be cancelled if its outputs are not used a specified timeframe? I guess not. (Partially cancelled, the transaction fee should remain valid.)

Another approach to this rollback is for the special transaction to also include a special output which sends *all* the money back to another of A's address. But this should have some sort of time lock on it, such that it isn't allowed to happen until a suitable delay, 24 hours, has occured. Is it possible for the outputs to be *double* the total inputs in a case like this, where maybe we can prove that only one output can be claimed? (I envisage having non-overlapping timelocks on both transactions in order.)

**Tags:** transactions, script, confirmations

> **Comments:**
> **username_1**: I think this would be best addressed on [bitcointalk](http://bitcointalk.org).  
> **username_2**: This is a great question. If this were possible, it would allow in-person transactions to be pre-confirmed and finalised at the time of the exchange, and rolled back if the exchange didn't proceed.  

---

## 3 answers

### Answer by username_3 on 2013-08-19. Score: 1

This is a solved problem, see <https://bitcointalk.org/index.php?topic=25786.0> and [this](https://en.bitcoin.it/wiki/Contracts#Example_7%3a_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party).

It has also been recently implemented in BitcoinJ, and called "Micropayment channels".


---

### Answer by username_4 on 2013-04-16. Score: 0

> When they shake hands, A can instantly show that document to B and B can verify that the document produces the correct hash.

But in order to verify that the document produces that hash, B would need to put it into a computer, which he could program to steal the document and make the transaction.

> Can Script allow a transaction to be cancelled if its outputs are not used a specified timeframe?

There was a proposal a while back that would have allowed that - it gave scripts access to the block number of the block it was included into. It was [ultimately rejected](https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119):

> We can't safely do OP\_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP\_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.
>
> nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later.

Here's the current best-practices for an escrow transaction: You send your bitcoins to a 2-of-3 escrow account controlled by me, you, and an escrow agent.

* If the trade completes sucessfully, then we transfer the bitcoins to your account.
* If we decide not to go through with the trade, then we transfer the bitcoins back to my account.
* If the escrow agent gets hacked, then we're ok because the hackers don't have the ability to steal the money without our cooperation.
* If we can't agree for whatever reason, then the escrow agent will arbitrate somehow.

This isn't a bulletproof scheme. For example, if we do the trade, and I then convince the escrow agent that you never held up your end, then I can get both the item you were selling and the bitcoins back.

> **Comments:**
> **username_0**: *"But in order to verify that the document produces that hash, B would need to put it into a computer, which he could program to steal the document and make the transaction."*   That's the whole point!  There is no stealing here.  A has decided to give B the document because the deal has been done, which B can then use to claim the output.  
> **username_0**: ... the purpose is to make it impossible for A to double spend.  The transaction from A->B will happen if and only if somebody (typically, B) can produce a document with the relevant hash.  
> **username_4**: @username_0 Ok, then suppose that after getting the item, A just walks off.  
> **username_0**: "*... A just walks off ..*". Nobody is pretending that can be solved :-)  The purpose is to avoid the embarrassing/inconvenient need for people to hang around waiting for 6 confirmations.  The instant that A gives the document to B and gets the item in return, B knows he/she has the money.  
> **username_4**: @username_0 Ah. I misunderstood. I thought you were trying to solve a different problem. You could do what you're suggesting by having A put the money in a 2-of-2 account. When A gets the item, he signs a transaction that puts the money in an account controlled entirely by B. B checks the destination address, then countersigns it. Since a double-spend out of the escrow account would require B's signature, he's safe.  
> **username_0**: Thanks @username_4, that makes more sense.  But that does run the risk of both parties refusing to sign, and the money being stuck in the escrow forever.  I'd like some guarantee that the money will end up somewhere eventually.  
> **username_0**: I have another (incomplete) idea. What about using that nTimeLock feature such that the escrow will create a transaction that sends the money back to A again and that it will "go through unless it is revoked before the deadline" (as you quoted) and only A is able to revoke it.  When A gives the revoke code to B, then A has sacrified the money 'instantly'.  
> **username_4**: @username_0 I have to be honest that I don't really understand the intended security model of nLockTime, so I'm of limited help there. I do know that it's currently ignored by the bitcoin client.  

---

### Answer by username_5 on 2013-04-17. Score: 0

This is largely an agreement with username_4 username_4's answer, but it was too long to put in a comment and I don't want suggest adding a bunch of extraneous things to his answer.

There are ways that you could give your Person B the ability to instantly have access to the funds. For example, just creating a new account, sending the money there with a normal transaction, and then providing them with the private key for that account when they deliver the product. But the problem with that approach is that there is no way that the recipient could verify that you haven't already used the private key to create a double spend just before you give them the private key. They could only be certain you haven't spent the output already by moving it to a new address and then waiting for the six confirmations. (Which fails to meet your objective. And there's no way around it. The point of the 6 transactions is to confirm no conflicting spends.)

You could avoid this problem by creating a transaction that you couldn't spend yourself ahead of time. For example, a 2of2 transaction that requires a private key that they already own as well as the private key you just created. But, as you point out, the problem with that approach is that if they elect not to complete the transaction there is no way to "revoke" the transaction. You can't claim it (by design) and they can't claim it either.

So, although I haven't done a rigorous proof here, I think the only theoretical way to solve this use case would be to have one thing they control, one thing you control, and one third thing that is "in escrow". As @username_4 points out, the block number would be an interesting way to do time based escrow. (And the [contracts page on the bitcoin.it wiki](https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit) leads me to think that it would be possible in a couple of ways.) But without replacement transactions or some other way to allow you to undo this if the deal doesn't work out I think the only way to do this would be manual escrow. ( See [this answer](https://bitcoin.stackexchange.com/questions/861/why-isnt-transaction-replacement-supported) for some answers on replacement transactions. )


---

