11 ms·

And then MtGox blamed their own bug on the open source developers calling the actual protocol a bug. (Although malleable transactions were a pretty stupid idea.

And then MtGox blamed their own bug on the open source developers calling the actual protocol a bug. (Although malleable transactions were a pretty stupid idea.)

cperciva 13y ago
Although malleable transactions were a pretty stupid idea I'd say that malleable transactions are a bug in the protocol.
- pikachu_is_cool 13y ago
  I wouldn't say a bug... more like a flaw in design. AKA a bug.
  - ak39 13y ago
    Agreed. For those interested in finding out what transaction malleability is: http://www.coindesk.com/bitcoin-bug-guide-transaction-malleability/ http://www.coindesk.com/bitcoin-bug-guide-transaction-mallea... <quote> What is transaction malleability? It’s an attack that lets someone change the unique ID of a bitcoin transaction before it is confirmed on the bitcoin network. The change makes it possible for someone to pretend that a transaction didn’t happen, if all the right conditions are in place. </quote> This is a fatal design flaw in any TPS system. From any sound accounting principles point of view, no journal entry is to be manipulated after insertion - only through compensating transactions (referencing the original).
    - VMG 13y ago
      To be clear here: when broadcasting your transaction to the network, somebody can reissue your transaction with a different ID, but they cannot change the inputs and outputs. There are other ways to track transactions other than the txid, for example by tracking a unique output address. A normalized hash routine has been added recently: https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35055553 https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35...
      - ak39 13y ago
        Thanks. Just a naive suggestion (will this work?): Why not introduce some sort of a 2-phase commit with the original transaction and the newly inserted one on the block-chain? So, before the block-chain transaction is committed, check the two transaction id hashes, if they are different for the request, fail the transaction. Edit: Of course, the eavesdropper could just as well pass the expected hash back to the originator anyways. :-( Hmmm
        VMG 13y ago
        That's not necessary. A transaction with a modified id is not a problem unless you falsely rely on the id for payment verification instead of tracking the inputs and outputs by a custom hash. The biggest flaw here is probably the name "transaction id", because it suggests that a transaction can only have one valid id. The normalized id fixes this issue for most transaction types.
  - baddox 13y ago
    Not the same thing in common usage. Most people use "bug" to refer to unintended behavior. Wikipedia also includes "incorrect behavior" in its definition, but that's extremely broad, since "incorrect" could be used to describe anything from an underperforming call to action on a landing page to creating software in the wrong market (e.g. "My software had a bug: I created a food delivery app when I should have created a social network app"). In fact, it's hard to even call this a flaw in design, because your intentions and hopes for Bitcoin might be very different than those of the Bitcoin developers.
    - dllthomas 13y ago
      I've often heard "design bug".
- maaku 13y ago
  Well, there are many sources of malleability which could be eliminated. Certainly I would consider each of those a bug. However it is not yet known whether malleability can be eliminated entirely (e.g. algebraic manipulations of ECDSA signatures).
Danieru 13y ago
Even if transactions were not malleable, or if you use unchangeable signatures, you would still hit a race condition using them like Mt. Gox does. The proper way to resend a transaction is to re-use an input which was used in the original transaction. It does not need to be all the same inputs, just at least one. This way it is not possible for the two transactions to both succeed. If the original transaction succeeds then the second will be rejected as a double spend. In general Mt. Gox's software appears to not be paying attention to little details about inputs. For a while now if a miner sends the block find award to their Mt. Gox address then Mt. Gox will use the inputs resulting from that block find before the inputs are valid. This causes any transaction with said input to be ignored. The proper solution is to wait the ~100 confirms before using the new btc. Note that this is a separate problem from the duplicated transactions. The point is: Mt. Gox is not tracking their bitcoin at the correct granularity. They appear to have written the software like we might use the bitcoin rpc api, without paying close attention to the details.

And then MtGox blamed their own bug on the open source developers calling the actual protocol a bug. (Although malleable transactions were a pretty stupid idea.)

cperciva 13y ago

Although malleable transactions were a pretty stupid idea I'd say that malleable transactions are a bug in the protocol.

pikachu_is_cool 13y ago
I wouldn't say a bug... more like a flaw in design. AKA a bug.
- ak39 13y ago
  Agreed. For those interested in finding out what transaction malleability is: http://www.coindesk.com/bitcoin-bug-guide-transaction-malleability/ http://www.coindesk.com/bitcoin-bug-guide-transaction-mallea... <quote> What is transaction malleability? It’s an attack that lets someone change the unique ID of a bitcoin transaction before it is confirmed on the bitcoin network. The change makes it possible for someone to pretend that a transaction didn’t happen, if all the right conditions are in place. </quote> This is a fatal design flaw in any TPS system. From any sound accounting principles point of view, no journal entry is to be manipulated after insertion - only through compensating transactions (referencing the original).
  - VMG 13y ago
    To be clear here: when broadcasting your transaction to the network, somebody can reissue your transaction with a different ID, but they cannot change the inputs and outputs. There are other ways to track transactions other than the txid, for example by tracking a unique output address. A normalized hash routine has been added recently: https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35055553 https://github.com/bitcoin/bitcoin/pull/3656#issuecomment-35...
    - ak39 13y ago
      Thanks. Just a naive suggestion (will this work?): Why not introduce some sort of a 2-phase commit with the original transaction and the newly inserted one on the block-chain? So, before the block-chain transaction is committed, check the two transaction id hashes, if they are different for the request, fail the transaction. Edit: Of course, the eavesdropper could just as well pass the expected hash back to the originator anyways. :-( Hmmm
      - VMG 13y ago
        That's not necessary. A transaction with a modified id is not a problem unless you falsely rely on the id for payment verification instead of tracking the inputs and outputs by a custom hash. The biggest flaw here is probably the name "transaction id", because it suggests that a transaction can only have one valid id. The normalized id fixes this issue for most transaction types.
- baddox 13y ago
  Not the same thing in common usage. Most people use "bug" to refer to unintended behavior. Wikipedia also includes "incorrect behavior" in its definition, but that's extremely broad, since "incorrect" could be used to describe anything from an underperforming call to action on a landing page to creating software in the wrong market (e.g. "My software had a bug: I created a food delivery app when I should have created a social network app"). In fact, it's hard to even call this a flaw in design, because your intentions and hopes for Bitcoin might be very different than those of the Bitcoin developers.
  - dllthomas 13y ago
    I've often heard "design bug".
maaku 13y ago
Well, there are many sources of malleability which could be eliminated. Certainly I would consider each of those a bug. However it is not yet known whether malleability can be eliminated entirely (e.g. algebraic manipulations of ECDSA signatures).

Danieru 13y ago

Even if transactions were not malleable, or if you use unchangeable signatures, you would still hit a race condition using them like Mt. Gox does. The proper way to resend a transaction is to re-use an input which was used in the original transaction. It does not need to be all the same inputs, just at least one. This way it is not possible for the two transactions to both succeed. If the original transaction succeeds then the second will be rejected as a double spend. In general Mt. Gox's software appears to not be paying attention to little details about inputs. For a while now if a miner sends the block find award to their Mt. Gox address then Mt. Gox will use the inputs resulting from that block find before the inputs are valid. This causes any transaction with said input to be ignored. The proper solution is to wait the ~100 confirms before using the new btc. Note that this is a separate problem from the duplicated transactions. The point is: Mt. Gox is not tracking their bitcoin at the correct granularity. They appear to have written the software like we might use the bitcoin rpc api, without paying close attention to the details.