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).
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).
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.
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
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.
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.
Comments
Although malleable transactions were a pretty stupid idea
I'd say that malleable transactions are a bug in the protocol.
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).
I wouldn't say a bug... more like a flaw in design.
AKA a bug.
Agreed.
For those interested in finding out what transaction malleability is:
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).
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-35...
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
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.
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.
I've often heard "design bug".