Transaction script with block height as condition

[Mike Hearn]

It buys instant confirmation for the receiver if the 2-of-2 escrow with refund was staged before it was needed, since the receiver would have to know of any double-spends simply because they would have had to sign them. This is perfect for staging Bitcoins on an exchange so that you don't have to wait 6 confirmations before you can make a trade, but without the risk of them being stolen in a hack or lost due to the site going down.

How does it make a difference? I have a payment from me to {me,mtgox} and a signed payment back from {me,mtgox} to me, then when I decide to send that money to MtGox so I can trade with it, they still have to wait the 6 confirmations to be sure I don't double-spend with the refund tx.

If I don't have a signed refund TX then if the site goes offline, I can't get my money back either.

"Once broadcast the inputs that transaction spends are used and double spends won't be accepted" ... into the memory pool. Unless I'm totally wrong, that means that all you need to do is manage to get your replacement transaction into a block before the time locked transaction can be entered into a block (which if you did it right, should be several months). For an entity like MtGox, even without transaction replacement being generally enabled on the network, this would be no problem.

You're right, you could try and do a Finney attack against your own transaction. However this is a bizarre hack that tries to recreate transaction replacement. It'd be better to just re-enable that feature, and then the whole scheme makes sense (my point was specifically about the suggestion of doing it before tx replacement is re-activated). We need replacement for other things anyway. The recovery transaction can have sequence numbers of zero. Because only somebody who can decrypt the wallet can create a replacement for it, as long as you notice the recovery transaction was broadcast by a thief it is safe to have it lying around. It's a neat idea.

I think in future it would make sense to change miners so they discourage blocks that include double spends against their memory pool. Finney attacks aren't helpful today to the network and discouraging blocks that contain them would help many people. It has to be thought about carefully to avoid opening up new attacks though.

flipperfish, your understanding is correct.

[jl2012]

It buys instant confirmation for the receiver if the 2-of-2 escrow with refund was staged before it was needed, since the receiver would have to know of any double-spends simply because they would have had to sign them. This is perfect for staging Bitcoins on an exchange so that you don't have to wait 6 confirmations before you can make a trade, but without the risk of them being stolen in a hack or lost due to the site going down.

How does it make a difference? I have a payment from me to {me,mtgox} and a signed payment back from {me,mtgox} to me, then when I decide to send that money to MtGox so I can trade with it, they still have to wait the 6 confirmations to be sure I don't double-spend with the refund tx.

If I don't have a signed refund TX then if the site goes offline, I can't get my money back either.

Use the nlocktime flag so the refund TX won't be valid before certain time in the future

[Mike Hearn]

So you're saying I should put my money into a state where if I want to send it to MtGox, that's fast, but if I want to use it for something else, I have to wait. I don't see why this is better than "if I want to use my money for something else, I can do so immediately, and if I want to trade, I have to wait". Given that in a healthy system most users will be using Bitcoin to buy goods/services rather than trying to exploit currency fluctuations ...

[Maged]

It buys instant confirmation for the receiver if the 2-of-2 escrow with refund was staged before it was needed, since the receiver would have to know of any double-spends simply because they would have had to sign them. This is perfect for staging Bitcoins on an exchange so that you don't have to wait 6 confirmations before you can make a trade, but without the risk of them being stolen in a hack or lost due to the site going down.

How does it make a difference? I have a payment from me to {me,mtgox} and a signed payment back from {me,mtgox} to me, then when I decide to send that money to MtGox so I can trade with it, they still have to wait the 6 confirmations to be sure I don't double-spend with the refund tx.

As jl2012 mentioned, that isn't the case at all. As long as the locktime is sufficiently in the future, there is little concern that the refund transaction will get into a block before the spending transaction does. This is completely different than the risks associated with accepting regular zero-confirmation transactions. And in the end, all that it comes down to is risk.

If I don't have a signed refund TX then if the site goes offline, I can't get my money back either.

Even without a refund transaction, this is still better than the current situation since the bitcoins would be provably in "cold storage" (in a sense, not literally, since both keys could be online) and unspendable by hackers. This is compared to us just having to trust that a cold storage exists.

You're right, you could try and do a Finney attack against your own transaction. However this is a bizarre hack that tries to recreate transaction replacement. It'd be better to just re-enable that feature, and then the whole scheme makes sense (my point was specifically about the suggestion of doing it before tx replacement is re-activated). We need replacement for other things anyway. The recovery transaction can have sequence numbers of zero. Because only somebody who can decrypt the wallet can create a replacement for it, as long as you notice the recovery transaction was broadcast by a thief it is safe to have it lying around. It's a neat idea.

Oh, yes, it is totally a hack. But, it would also be totally compatible with transaction replacement if it is re-enabled.

I think in future it would make sense to change miners so they discourage blocks that include double spends against their memory pool. Finney attacks aren't helpful today to the network and discouraging blocks that contain them would help many people. It has to be thought about carefully to avoid opening up new attacks though.

Agreed. However, in addition to making sure not to open up new attacks, we also have to be careful and not prevent future legitimate reasons for doing a Finney attack.

So you're saying I should put my money into a state where if I want to send it to MtGox, that's fast, but if I want to use it for something else, I have to wait.

Not at all. At least, no more than you have to wait for a normal transaction. Remember, we're assuming that we still trust our example of MtGox in general, just not 100% of the time (which is what we must currently accept if we want to stage funds there). So, you release the funds to MtGox and immediately withdraw through their interface. If the withdrawal exceed their hot wallet, there will have to be a transaction dependent on the release transaction, true, making things slower. However, if MtGox is willing to hold some of their own funds in a hot wallet for their customer's convenience, it'd be no different than sending a transaction from MtGox now.

Using the release transaction as a dependency for withdrawal like this would certainly decrease the risks, though. In fact, a withdrawal could even be sent directly from the staged transaction, making the withdrawal transaction just a regular bitcoin transaction (with all the risks that entails) that MtGox signed off on to acknowledge that the funds are no longer staged.

I don't see why this is better than "if I want to use my money for something else, I can do so immediately, and if I want to trade, I have to wait". Given that in a healthy system most users will be using Bitcoin to buy goods/services rather than trying to exploit currency fluctuations ...

The only downside to this over storing bitcoins in your own wallet is that you have to trust that when you want to spend the bitcoins that whoever you have them staged with will let you. If they don't let you, you'll just have to wait until the refund transaction matures.

The upside, however, is that it can also be a green address that was used to sign off on the release of the bitcoins, with all the benefits that entails.

[jl2012]

So you're saying I should put my money into a state where if I want to send it to MtGox, that's fast, but if I want to use it for something else, I have to wait. I don't see why this is better than "if I want to use my money for something else, I can do so immediately, and if I want to trade, I have to wait". Given that in a healthy system most users will be using Bitcoin to buy goods/services rather than trying to exploit currency fluctuations ...

You can still use it for something else. As long as MtGox is working properly, they will send the coins in the 2-by-2 address to any address based on your instruction. The nlocktime transaction sending back to you is only an "emergency exit": if MtGox is suddenly closed, you will still get your coins back some time in the future. In 99.9% cases, you don't actually need to use this nlocktime tx.

[jl2012]

It seems that my question was not answered. At least I would like to know why it does not work.

I have modified my proposed scheme. A script could be constructed like this:

1. At any time, the coin can be spent by satisfying condition A (e.g. signatures from X and Y)
2. If block height >= n, the coin can be spent by satisfying condition A OR condition B (e.g. signature from Z)

Therefore, the condition A permanently valid. The condition B is always invalid before block height = n, and permanently true after. It is equivalent to an nLockTime tx, signed by condition A, and send to an output for condition B.

It is better than using nLockTime because the user can deposit to the script hash at any time, without the need of sending nLockTime transaction back-and-forth and storing them.

[Maged]

If you held a pre-signed transaction that sends the funds back to you with a lockTime of 1 Jan 2013 that would work.

Lets see... thinking out loud...

Start by asking the exchange for a brand-new public key to use for their half of the 2-of-2 transaction. Call the send-coins-into-2-of-2 transaction "F" (for Fund).

You create and sign that transaction, but don't broadcast it yet.

Use it's transaction id to create a second, one-input-two-signature, lockTime=1/1/2013 transaction that refunds the coins to you.  Call that "R" (for Refund).

Send R to the exchange and ask them to sign it using that brand-new public key they gave you. The exchange checks the lockTime and then returns R and the signature to you. You check the signature, and if it is good, broadcast F (and keep the half-signed R someplace safe).

If 1/1/2013 rolls around and you want your coins back, you sign your half of R and broadcast it.


I'd have to think a little harder than I want to right now about whether or not signing R knowing only txid==HASH(F) opens up the exchange to attacks. I can't think of any, but the exchange providing a signature when it doesn't know the details of exactly what it is signing makes me nervous.

That should be safe if and only if a unique key is used to sign, and you can be absolutely certain that it has not nor will not be used for anything else until the exchange receives the signed transaction F. That means that the key can't be from a pre-generated list that may have been backed up, because that backup might eventually need to be used and the key could unknowingly be used for something else. It'd be a hard attack to pull off, but the potential for an attack is certainly there. So, the exchange would need to generate the key for signing transaction R on-the-fly and mark it specifically for this purpose. Thus, there's no risk that the key might be used for something else once it is backed up. If F is never sent then, the worst-case scenario is that a brand-new key will have only ever signed one transaction and never received anything. Since the key would have to be newly-generated, the worst-case scenario is that the exchange loses that key but you still have a signed transaction to get your money back later, anyway.

I think holding on to pre-signed-but-not-broadcast-yet transactions is a technique "we" don't think about enough.

That being said, I also have a more general-case solution that will allow this technique to work in all cases...

You could send the unsigned R and the signed-but-not-broadcast F to the exchange and trust that the exchange will not broadcast F unless they agree to sign R.

Generally that may be safe, but there's a chance that your money might fall into the void. So, the problem here is that F needs to be invalid when we send it to the exchange, but needs to be able to be made valid without changing anything in the transaction, meaning that we can't withhold signatures. So, let's just not withhold anything in this transaction at all. The very problem we're seeing here is actually it's own solution: the exchange doesn't want to sign something when it only knows the hash of an input transaction, but not the input transaction itself. It's the same for miners: they need the input transactions, not just the hashes, to enter a transaction into the blockchain.

So, the user just needs to not tell anyone about "Fi", an input to "F", until they get back "R". If "F" is broadcast and "R" is never signed, it's okay, because "F" was just an orphan and will never hit the blockchain unless the user broadcasts "Fi".

[mmeijeri]

I've been reading some threads on allowing checks of block height in scripts, and I still don't understand what's so dramatically bad about it. It's clear enough that a previously valid transaction can become invalid after a reorganisation, but that is solved in most cases if you wait for enough confirmations. The exception appears to be that after a lengthy segmentation you would get much more collateral damage than usual.

There was some suggestion that it might also allow people to deliberately create reorganisations, but I don't understand how that would work. Also, some developers seem to have changed their minds a bit. So, what's current thinking about a block height opcode and what exactly are the scenarios people are worried about?

[jl2012]

I've been reading some threads on allowing checks of block height in scripts, and I still don't understand what's so dramatically bad about it. It's clear enough that a previously valid transaction can become invalid after a reorganisation, but that is solved in most cases if you wait for enough confirmations. The exception appears to be that after a lengthy segmentation you would get much more collateral damage than usual.

There was some suggestion that it might also allow people to deliberately create reorganisations, but I don't understand how that would work. Also, some developers seem to have changed their minds a bit. So, what's current thinking about a block height opcode and what exactly are the scenarios people are worried about?

With the random malleability attack, the refund transaction in micro-payment channel is no longer reliable, as the txid is not fixed until confirmed. Pushing block height and block timestamp in the script will be very useful.

By the way, malleability will also make any previously valid transaction becoming invalid in case of reorg.