1

I just read the malleability page.

Can someone confirm that this

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.

means that the protocol actually doesn't assign signature data to addresses in the database?

Please tell me that's not true.

Improve this question
2
  • I don't understand "the protocol actually doesn't assign signature data to addresses in the database". What signature data? What database? Commented Feb 15, 2014 at 3:15
  • I understand Bitcoin well, but the question is still messy, because there's no clear meaning to "the protocol actually doesn't assign signature data to addresses in the database". The protocol doesn't maintain a database. 'Signature data' isn't 'assigned' to 'addresses' by the protocol or software, signatures are attached to transactions. Regarding your additional comment, there's no 'bad data' to be deleted - the mutated transactions are still valid, and if they win their way into the blockchain, they live forever as valid transactions. They just confuse some other software. Commented Feb 19, 2014 at 1:29

1 Answer 1

Reset to default
2

The signature covers everything except the signature itself. Since the signature and public key make up the input script for the most common payment type (pay-to-pubkey-hash), the input script is not part of the signed data. This means the input script can be modified and not break the signed transaction as long as the new input script is equivalent to the original input script. The recent attack did this by changing one of the script opcodes to an equivalent opcode. So the new script was valid and performed the same function. But since the opcode was changed, the transaction hash was different.

Once a transaction is part of a block, the transaction hash cannot be changed since it is now included in the Merkle tree for the block. So the attack window is only from the time the transaction is created until a miner includes it in a block. During this window, a modified transaction can be broadcast and it is a race to see which one makes it into the block. The one that loses will never be confirmed since it spends inputs that are already spent. No matter which one wins, the coins are sent to the proper destination.

The problem for Mt Gox (and others) is they track a transaction based on its transaction ID. If the modified transaction wins and gets included in a block, the original transaction will be discarded. This then led Mt Gox to think the money was not paid (since the transaction ID was not in the block chain) and they would create a new transaction to pay the money again.

Improve this answer
4
  • @Gracchus I wouldn't call it incompetence exactly. They made a pretty natural assumption that something called a 'transaction id' could be used to identify a transaction. I'm guilty of that myself and have had to change my code to use a 'normalized transaction id' instead to easily spot duplicates. Commented Feb 15, 2014 at 18:03
  • @Gracchus I wasn't insulted, sorry if I gave that impression. What I meant was, if you tell a programmer that something is an identifier, the programmer is going to assume that it is immutable. The problem is the transaction id is a hash of the entire transaction and is not part of the transaction itself. So any change in the serialized form of the transaction will cause the id to change. Since the signature cannot itself be signed (chicken and egg problem), that leaves it open to modification. Commented Feb 16, 2014 at 0:52
  • 1
    @Gracchus There wouldn't be a problem if a canonical encoding were enforced from the beginning. Then there would have been only one acceptable byte stream for a transaction and the transaction id would be unique. You can't have just keys, signatures and data without some framework for encoding the data, unless everything has a fixed length. Otherwise, you have no idea what parts of the byte stream belong to what object. Commented Feb 16, 2014 at 2:33
  • 1
    @Gracchus No, I meant that you need an encoding schema if they aren't fixed-length. An example would be ASN.1, of which DER (distinguished encoding rules) is the canonical subset. In fact, the signature is encoded using DER. A problem arises because the decoder (OpenSSL in the case of the reference client), allows non-DER encodings. So now you need to either scan the signature yourself to enforce the DER rules or you need to change OpenSSL to add a flag saying that only DER-encoded data is acceptable when decoding the signature. So the input script is not the only vulnerability. Commented Feb 16, 2014 at 4:18