Author

Topic: What exactly is malleable? (Read 1031 times)

legendary
Activity: 4592
Merit: 1276
February 11, 2014, 02:46:27 PM
#8
oh so the signatures themselves are malleable... but that's a feature, not a bug..  Grin

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!

sr. member
Activity: 364
Merit: 252
February 11, 2014, 02:35:59 PM
#7
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.  Grin
legendary
Activity: 4018
Merit: 1299
February 11, 2014, 02:05:21 PM
#6
Quote
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.
sr. member
Activity: 364
Merit: 252
February 11, 2014, 01:23:03 PM
#5
Quote
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


legendary
Activity: 1106
Merit: 1024
February 11, 2014, 01:22:02 PM
#4
oh so the signatures themselves are malleable... but that's a feature, not a bug..  Grin

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

Quote
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.
legendary
Activity: 1001
Merit: 1003
February 11, 2014, 12:27:17 PM
#3
oh so the signatures themselves are malleable... but that's a feature, not a bug..  Grin
legendary
Activity: 1232
Merit: 1083
February 11, 2014, 12:26:03 PM
#2
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.
legendary
Activity: 1001
Merit: 1003
February 11, 2014, 12:11:06 PM
#1
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.
Jump to: