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.
Comments
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.