Transaction malleability is actually a big problem?

[Sarchar]

Forgive me if this has been discussed to death and back, but lately I've been working on some Contracts transactions.  The realization that malleability prevents some of these contracts from working (trustlessly and securely) is starting to sink in.  

Dependent transactions just can't be built until they're included in the blockchain...

Does tx malleability basically mean that a number of advanced contracts are essentially broken?

1. Providing a deposit - Tx2 can't depend on Tx1 txid not changing. Step 2 sends the hash of Tx1 to the "website" to sign a refund tx.
2. P2P alt-chain trading - Tx2 can't refund Tx1 until it's in the blockchain, but you shouldn't fund Tx1 until Tx2 is signed.
3. Rapidly adjusted micropayments - (Does this hurt bitcoinj's security too?) Can't create refund T2 based on hash of T1.

I'm not interested in MtGox and their usage of transaction hashes, as that's just something they can fix.  These advanced contracts, on the other hand, heavily depend on a transaction hash not changing.

[1715195766]

1715195766

[1715195766]

1715195766

[1715195766]

1715195766

[jl2012]

Forgive me if this has been discussed to death and back, but lately I've been working on some Contracts transactions.  The realization that malleability prevents some of these contracts from working (trustlessly and securely) is starting to sink in.  

Dependent transactions just can't be built until they're included in the blockchain...

Does tx malleability basically mean that a number of advanced contracts are essentially broken?

1. Providing a deposit - Tx2 can't depend on Tx1 txid not changing. Step 2 sends the hash of Tx1 to the "website" to sign a refund tx.
2. P2P alt-chain trading - Tx2 can't refund Tx1 until it's in the blockchain, but you shouldn't fund Tx1 until Tx2 is signed.
3. Rapidly adjusted micropayments - (Does this hurt bitcoinj's security too?) Can't create refund T2 based on hash of T1.

I'm not interested in MtGox and their usage of transaction hashes, as that's just something they can fix.  These advanced contracts, on the other hand, heavily depend on a transaction hash not changing.

I have pointed out the same here: https://bitcointalk.org/index.php?topic=303088.msg5078809#msg5078809

I can't see any hope to save it without fixing malleability. Anything depending on zero-confirmation tx is not safe

[jl2012]

Well, I just find a way to save it.

Let's have a new SIGHASH type called SIGHASH_ANYUTXO. Signing with this tag means that the signer would allow the redemption of any UTXO of the same address. So the signer don't need to specify the hash of the UTXO. The signature is valid no matter how the txid is changed. As long as the signer is not reusing the address, that would be safe.

Any comment?

[Peter Todd]

Well, I just find a way to save it.

Let's have a new SIGHASH type called SIGHASH_ANYUTXO. Signing with this tag means that the signer would allow the redemption of any UTXO of the same address. So the signer don't need to specify the hash of the UTXO. The signature is valid no matter how the txid is changed. As long as the signer is not reusing the address, that would be safe.

Any comment?

That's what I've been saying for ages... though it'll have to be implemented as a new CHECKSIG operator due to Satoshi screwing up upgrade possibilities in CHECKSIG.

[jl2012]

Well, I just find a way to save it.

Let's have a new SIGHASH type called SIGHASH_ANYUTXO. Signing with this tag means that the signer would allow the redemption of any UTXO of the same address. So the signer don't need to specify the hash of the UTXO. The signature is valid no matter how the txid is changed. As long as the signer is not reusing the address, that would be safe.

Any comment?

That's what I've been saying for ages... though it'll have to be implemented as a new CHECKSIG operator due to Satoshi screwing up upgrade possibilities in CHECKSIG.

The original CHECKSIG is too bulky and we will need to modularize it in the future. We may also want different types of hashing and public key algorithms. This will enhance the long-term security a lot.

[Sarchar]

Well, I just find a way to save it.

Let's have a new SIGHASH type called SIGHASH_ANYUTXO. Signing with this tag means that the signer would allow the redemption of any UTXO of the same address. So the signer don't need to specify the hash of the UTXO. The signature is valid no matter how the txid is changed. As long as the signer is not reusing the address, that would be safe.

Any comment?

That's what I've been saying for ages... though it'll have to be implemented as a new CHECKSIG operator due to Satoshi screwing up upgrade possibilities in CHECKSIG.

I've had a few thoughts along this line, as well.. Perhaps instead of ANYUTXO, which is quite specific (don't hash the prevout field), why not build CHECKSIG2, which takes a flags word indicating each of the pieces of the transaction to sign (nLockTime, Outputs (Single, All, None), Inputs (With/Without prevouts, Anyonecanpay, sequence #s), etc.)?

I would actually consider writing the patch myself, if there was at all a decent chance of it being accepted into the reference client within the next several months.

[kjj]

Well, I just find a way to save it.

Let's have a new SIGHASH type called SIGHASH_ANYUTXO. Signing with this tag means that the signer would allow the redemption of any UTXO of the same address. So the signer don't need to specify the hash of the UTXO. The signature is valid no matter how the txid is changed. As long as the signer is not reusing the address, that would be safe.

Any comment?

That's what I've been saying for ages... though it'll have to be implemented as a new CHECKSIG operator due to Satoshi screwing up upgrade possibilities in CHECKSIG.

I'm not sure you can really blame Satoshi for this.  Either OP_CHECKSIG is useless, or any changes to it mean a hardfork anyway.  Consider an "upgrade" that your node is unaware of.  Your node will see it as an invalid signature.  You can either accept all invalid signatures (which makes it pointless to check), or you can be forced to upgrade your software to keep up (which is what a hard fork is).

Contracts can be fixed with a softfork, bumping the block version to 3 and requiring that all signatures in version 3 blocks be in minimized form.

[Peter Todd]

I'm not sure you can really blame Satoshi for this.  Either OP_CHECKSIG is useless, or any changes to it mean a hardfork anyway.  Consider an "upgrade" that your node is unaware of.  Your node will see it as an invalid signature.  You can either accept all invalid signatures (which makes it pointless to check), or you can be forced to upgrade your software to keep up (which is what a hard fork is).

Contracts can be fixed with a softfork, bumping the block version to 3 and requiring that all signatures in version 3 blocks be in minimized form.

Nope. If Satoshi had implemented OP_CODESEPARATOR correctly, without making it automatically get inserted into the concatenated scriptSig and scriptPubKey and with the existing OP_RETURN fails the script design you could upgrade SIGHASH with new, useful, flags by having them check a signed hash against other conditions.

FWIW this is one of the things that makes me think Satoshi released bitcoin prematurely and on a deadline. I doubt he ever actually prototyped any of the things the scripting system could have been used for prior to release.