What exactly is malleable?

[Amitabh S]

Lets say we have inputs A, B and outputs X, Y.

Say we have a tx = (Sign_A((A, B), (X, Y)), Sign_B((A, B), (X, Y)), (A, B), (X, Y))

What exactly is malleable here?

Please point me to the thread where this is explained.

[TierNolan]

What exactly is malleable here?

An unsigned transaction has none of the signatures included.  The unsigned transaction is hashed, signed and the signatures are added.

To check a transaction's signatures, you need to delete them from the transaction and then hash the result.  You then check the signatures against that hash.

Since the signatures themselves aren't actually signed, you can change them.

One way to do that is to add zeros to the number.  A signature of (1234, 5678) could be converted to (01234, 05678).  You haven't change the two value but you have changed how they are encoded.

This gives a different tx-id, but doesn't invalidate the signature.

You can also negate one of the values without it having any effect.

[Amitabh S]

oh so the signatures themselves are malleable... but that's a feature, not a bug.. 

[dexX7]

oh so the signatures themselves are malleable... but that's a feature, not a bug.. 

From: https://gist.github.com/sipa/8907691

Several sources of malleability are known:

• Inherent ECDSA signature malleability
  ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
• Non-DER encoded ECDSA signatures
  Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
• Superfluous scriptSig operations
  Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
• Non-push operations in scriptSig
  Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
• Push operations in scriptSig of non-standard size type
  The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_DATAPUSH, OP_DATAPUSH2, OP_DATAPUSH4). As the later ones have the same result as the former ones, they result in additional possibilities.
• Zero-padded number pushes
  In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
  Inputs ignored by scripts If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
• Sighash flags based masking
  Sighash flags can be used to ignore certain parts of a script when signing.

[thenoblebot]

While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated.

So some of the non-essential data can sometimes be changed. And that is what leads to malleability of the transaction, even though it remains perfectly valid and will go to the exact address as intended.

Relevant link : https://en.bitcoin.it/wiki/Transaction_Malleability

[cr1776]

While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated.

So some of the non-essential data can sometimes be changed. And that is what leads to malleability of the transaction, even though it remains perfectly valid and will go to the exact address as intended.

Relevant link : https://en.bitcoin.it/wiki/Transaction_Malleability

It is like the post office (or someone else) stamping the outside of the envelope - it still gets there [well, that is debatable!], but the envelope isn't identical to the way it was when you placed it in the mailbox.

[thenoblebot]

It is like the post office (or someone else) stamping the outside of the envelope - it still gets there [well, that is debatable!], but the envelope isn't identical to the way it was when you placed it in the mailbox.

Haha yea thats a nice way to put it. Simple and clean cr1776. So the debatable part - it has to do with rebroadcasting the original (or maybe modified again) transaction which might get accepted instead of the modified one.

Dam I hope I didn't confuse them again after your clean analogy. 

[tvbcof]

oh so the signatures themselves are malleable... but that's a feature, not a bug.. 

It seems to me that the end result here is that in order to use the globally distributed and persistent blockchain safely, one needs to take the tx-id off the confirmed blockchain.  This means planning one's transactions with some deliberation and rate limiting as well as analyzing the blockchain carefully (leading one to wish to have it on-hand.)

I personally would consider this a feature.  If Satoshi(s) did as well, and especially if he/they anticipated a window for significant growth and interest in the solution before the issue became abused, he's a bigger fuckin genius than I thought!