Instant confirmations with pre-published, locked, transactions

Question

(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 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.)

Answer 1

This is a solved problem, see https://bitcointalk.org/index.php?topic=25786.0 and this.

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

Answer 2

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:

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.

Answer 3

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.

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 @NickODell points out, the block number would be an interesting way to do time based escrow. (And the contracts page on the bitcoin.it wiki 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 for some answers on replacement transactions. )