SERIOUS VULNERABILITY related to accepting zero-confirmation transactions

[Peter Todd]

Yup, that's another known attack. bitcoinj is going to support recursive analysis of transaction depth IIRC, so you'd be able to say "don't accept chains more than x long"

[1715085916]

1715085916

[1715085916]

1715085916

[1715085916]

1715085916

[1715085916]

1715085916

[Mike Hearn]

Do you know the miner who mined the double spends?

Although playing games with the consensus protocol will always be possible, the difficulty of executing such attacks can be made much harder through some simple community policing work to ensure that legitimate miners don't accidentally get co-opted into creating double spends.

[jgarzik]

well... duh?

Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?

In general...  agreed, with this sentiment and the opinions others have expressed in this thread.

However, it should be noted that certain situations may benefit from a mixed approach.  If you are a merchant shipping a physical product, the purchase process might look like

• Request payment
• User sends bitcoins
• "Payment received!"
• Hours or days pass, while product is packed and prepped for shipment
• Order validation: Check and make sure bitcoins have not been double-spent
• Ship product

So it is really product/situation dependent.  A situation like bitcoin exchange or SatoshiDICE would seem like the ideal example of when to not accept zero-conf transactions; alternately BitcoinStore.com would seem like an excellent example of what could follow the multi-step order flow above.

Multi-step Zero-conf-now-check-later gives the best user experience: fast immediately confirmation of funds receipt, with the security of multiple confirmations before final product delivery/enablement.

[pointbiz]

Can someone now disclose the issue as promised? .... retep?

It appears to me that Mike Hearn has had the correct non-panicky level headed approach to this. Can someone explain how this is an exploit as opposed to expected functional behavior? It took me a lot of reading to determine this is a non issue?!? Am I wrong?

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Satoshi's wait 10 seconds for unconfirmed transactions to listen for a double spend applies to transactions that can feasibly make it to a block. Not for ones with lock times decades in the future?!?

 It also seems like no miner made the wrong choose for greed rather they took a committed transaction and put it in a block instead of its uncommitted locked version? Again am I wrong?

[Peter Todd]

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Transaction replacement is currently disabled. Multiple parties discussed this issue extensively, and the consensus was that the minor utility of being able to broadcast non-final transactions was not important enough given the drawbacks.

True transaction replacement probably needs to be done as a separate P2P layer, and in any case always has the problem that there is nothing stopping miners from mining older versions of the transaction that they know about.

Satoshi's wait 10 seconds for unconfirmed transactions to listen for a double spend applies to transactions that can feasibly make it to a block. Not for ones with lock times decades in the future?!?

That's the main reason this was considered a serious issue: code was doing exactly that and not taking into account that transactions can be made invalid until thousands of years in the future. (Maximum nLockTime setting locks the transaction until July 18, 11515) There are lots of UI's that make no distinction between transactions that can be mined now and ones that can't. The same applied to services; I did after all steal 5BTC from blockchain.info exploiting this oversight.

It also seems like no miner made the wrong choose for greed rather they took a committed transaction and put it in a block instead of its uncommitted locked version? Again am I wrong?

A non-final transaction can not be included in a block until it finalizes and thus miners have nothing to do with the issue.

[caveden]

Gavin's pull request looks like it is disabling a feature needed by transaction replacement in favor of assisting those who are swapping tangible assets for unconfirmed transactions without waiting the lock time.

Transaction replacement is currently disabled. Multiple parties discussed this issue extensively, and the consensus was that the minor utility of being able to broadcast non-final transactions was not important enough given the drawbacks.

That's what I feared. You're seriously killing nLockTime for good?

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

Anyways. This is a powerful feature. The fact that's not yet exploited doesn't mean otherwise: multisig itself is not really exploited so far, and I don't think you'd say that feature is "not important enough".

[Luke-Jr]

nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.

[Peter Todd]

nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.

Specifically nLockTime is only considered non-standard when the transaction is not final yet. That is the locktime hasn't been reached, and the transaction is not eligible to be included in a block. Non-standard just means that nodes won't relay such transactions on the P2P network, but nothing stops you from saving the transaction yourself and broadcasting it when the locktime is reached and the transaction finalizes.

Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.

You can do that just fine even if non-final transactions are not-standard. Just create the transactions that send the money back to the client, set the nLockTime so that they will not be valid for 3 months, and then sign them. You can freely give the client copies of these transactions. As the three months approaches, move the coins to invalidate the txin's of the previous set of locked transactions and create new refund transactions. If the refund transactions are ever needed, just wait until they have finalized, and broadcast them on the P2P network as you would any other transaction.

Ultimately the thing is transaction replacement just doesn't work the way people want it to because you can always replace a transaction by finding a miner willing to ignore the non-final tx in their mempool and willing to mine another one for you. Additionally mempool contents don't last forever; I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

[phelix]

Am I correct in assuming that while this is a serious issue for some sites it does not currently affect most clients and can be fixed for those affected with relative ease?

Once again this makes me wonder if Bitcoin guts really have to be so twisted and complicated. All this just sounds like an invitation to overlook serious issues.

[caveden]

I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.

[Peter Todd]

I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.

But... doesn't that mean that people were treating a time-locked transaction as normal unconfirmed transaction? They should not be treated as the same thing, that's the actual problem.

That's exactly what people were doing, or really, what the software people were using was doing. Keep in mind that a non-time-locked transaction that depends on a time-locked transaction is effectively time-locked... fixing the issue that way isn't trivial and would have required a lot more careful testing to be absolutely sure it worked; I should know, I wrote a patch that did exactly that kind of analysis before writing a version of the nearly trivial fix that Gavin wrote. It took me a few days to be convinced, but I think he made the right choice. There are also other mostly theoretical vulnerabilities related to non-final transactions that have not been disclosed as far as I know. They are fixed by Gavin's patch and are not fixed by just handling non-final txs differently in the UI. They also can-not be used to steal funds.

[Mike Hearn]

We can bring time locked and replaceable transactions back when somebody does the work necessary to properly unit test the code, think through the potential issues/angles of attack and patches them, makes sure the DoS/abuse potential is minimized etc.

For now, Luke-Jr has it right - the feature was unused as it's meant to be deployed along side replacement. So we'll have to bring them back together.

[pointbiz]

retep, thank you for the clarifications. Could you TL;DR in the OP? And mention it is patched in 0.8?