3 ms·

Eh well, it is Bitcoin's problem in that it's not meant to ever happen. Mt Gox's implementation is based on what is meant to happen in the network (transaction

by nwh 13y ago

Eh well, it is Bitcoin's problem in that it's not meant to ever happen. Mt Gox's implementation is based on what is meant to happen in the network (transaction IDs can not change) rather than what does happen (signatures with weird padding are accepted). The network as of late version doesn't relay these either, I seem to remember reading, so it's a problem that's being intentionally reduced.

maaku 13y ago
This is not a recently discovered "problem." This is how bitcoin has always worked. Even before the OpenSSL signature encoding malleability discovery, it was always known that you could add a NOP instruction to a scriptSig, for example, to change the txid without affecting the signature (as the scriptSig is not covered by the signature, for obvious reasons). From the very first day that Bitcoin was released, it was known to anybody who looked at the code that transaction ID's could be changed without affecting signatures.
- nwh 13y ago
  From the references on the forum, it looks like the issue wasn't really discovered or considered until mid 2011. The developers comment on their active involvement in closing this up, so it's probably reasonable to expect that it's not intended or desirable. https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410 https://bitcointalk.org/index.php?topic=8392.msg122410#msg12...
  - pmorici 13y ago
    It's Feb. 2014 the issue has been known since at least May 2011 In other words people have known about this for about 3 years. My vote is still on Mt.Gox incompetence.
  - maaku 13y ago
    That is concerning malleability of the DER encoding only. Note that there are other ways to modify a transaction which change the hash without affecting the signature validity, such as inserting NOP instructions into any of the scriptSig's. That is what I was referring to, and something which was quite obvious from the first release of bitcoind.
hoggle 13y ago
Isn't it the case with Bitcoin that the official implementation amounts to its specification? Maybe implementing the protocol themselves was a good idea from a theoretical standpoint but in reality amounts to over-engineering? I certainly don't know enough about this stuff so I could be naive of course.

by nwh 13y ago

maaku 13y ago

This is not a recently discovered "problem." This is how bitcoin has always worked. Even before the OpenSSL signature encoding malleability discovery, it was always known that you could add a NOP instruction to a scriptSig, for example, to change the txid without affecting the signature (as the scriptSig is not covered by the signature, for obvious reasons). From the very first day that Bitcoin was released, it was known to anybody who looked at the code that transaction ID's could be changed without affecting signatures.

nwh 13y ago
From the references on the forum, it looks like the issue wasn't really discovered or considered until mid 2011. The developers comment on their active involvement in closing this up, so it's probably reasonable to expect that it's not intended or desirable. https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410 https://bitcointalk.org/index.php?topic=8392.msg122410#msg12...
- pmorici 13y ago
  It's Feb. 2014 the issue has been known since at least May 2011 In other words people have known about this for about 3 years. My vote is still on Mt.Gox incompetence.
- maaku 13y ago
  That is concerning malleability of the DER encoding only. Note that there are other ways to modify a transaction which change the hash without affecting the signature validity, such as inserting NOP instructions into any of the scriptSig's. That is what I was referring to, and something which was quite obvious from the first release of bitcoind.

hoggle 13y ago

Isn't it the case with Bitcoin that the official implementation amounts to its specification? Maybe implementing the protocol themselves was a good idea from a theoretical standpoint but in reality amounts to over-engineering? I certainly don't know enough about this stuff so I could be naive of course.