Topic: Is malleability worth a hard fork? (Read 958 times)
You can easily do what you want to do with a soft-fork FWIW.
Interesting that it is placed in the "Navel gazing" / Housekeeping section. It has a functional effect on the system.
As long as sufficient care was taken in rolling out the hard fork to make sure that near consensus was reached before the change is active, I'm not opposed to this idea. On the other hand, I haven't yet looked into the other solutions people are suggesting (if any) to deal with malleability, so I'm uncertain if anyone is suggesting any methods that don't require a hard fork.
The plan is try to identify all the possible sources of malleability and define "canonical" transactions for each case.
If a single one is missed, then it doesn't work.
The advantage is that it is a soft fork.
As long as sufficient care was taken in rolling out the hard fork to make sure that near consensus was reached before the change is active, I'm not opposed to this idea. On the other hand, I haven't yet looked into the other solutions people are suggesting (if any) to deal with malleability, so I'm uncertain if anyone is suggesting any methods that don't require a hard fork.
The reason that transaction malleability is a big deal is that the transaction id hash and the signature hash are not the same.
The tx-id hash is used to reference which transactions are inputs into transactions.
This means that when you sign a transaction, you have no way to be sure that the transaction will enter the blockchain with the same id.
You could sign a series of transactions which build on the previous transaction. If any of the transactions in the chain are mutated, then the chain fails.
The hash that is used for signing excludes all the signatures, since they are added afterwards.
A simple hard fork (in so far as hard forks can be simple) would be to allow transactions to be referred to by either hash(tx) or hash(tx without signatures).
This would only apply when linking up transactions, the merkle tree would use the txid.
If the input is set to the signature hash, then it will refer to the transaction and all of its mutants.
This means that the old chain is valid under the new rules, so there doesn't need to be a switch over check for a particular transaction.
Even if not included, having the code ready for the next "emergency" hard fork could be useful.
The hashtype is added before performing signature hash too. Two transactions with different hash types would be considered the same. The rest of the transaction (including the outputs) would be identical, so it doesn't really matter how the transaction made it into the blockchain.
If a hard fork was being considered, then adding a sum-tree for the merkle tree would also be nice.
The tx-id hash is used to reference which transactions are inputs into transactions.
This means that when you sign a transaction, you have no way to be sure that the transaction will enter the blockchain with the same id.
You could sign a series of transactions which build on the previous transaction. If any of the transactions in the chain are mutated, then the chain fails.
The hash that is used for signing excludes all the signatures, since they are added afterwards.
A simple hard fork (in so far as hard forks can be simple) would be to allow transactions to be referred to by either hash(tx) or hash(tx without signatures).
This would only apply when linking up transactions, the merkle tree would use the txid.
If the input is set to the signature hash, then it will refer to the transaction and all of its mutants.
This means that the old chain is valid under the new rules, so there doesn't need to be a switch over check for a particular transaction.
Even if not included, having the code ready for the next "emergency" hard fork could be useful.
The hashtype is added before performing signature hash too. Two transactions with different hash types would be considered the same. The rest of the transaction (including the outputs) would be identical, so it doesn't really matter how the transaction made it into the blockchain.
If a hard fork was being considered, then adding a sum-tree for the merkle tree would also be nice.
Jump to: