malleability work-around vs fix (Re: 0.8.5 with libsecp256k1) [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2013-10-10T15:06:03+00:00


Summary:

In a conversation, Adam Back discusses the issue of fixing ambiguity in the asn.1 level. He suggests that it is not necessary to address this ambiguity in order to have conditional payments using not yet broadcast txid outputs as inputs. He points out that even if a new crypto level malleability is discovered in ECDSA, it remains secure.In response to this conversation, Adam Back proposes a more generic and robust solution for fixing the issue. He suggests changing the txid from H(sig,inputs,outputs,script) to H(pubkey,inputs,outputs,script), or something similar. This change would ensure that the malleability of the signature mechanism does not affect the security of conditional payments.The context also discusses the use of deterministic ECDSA signatures, where k is calculated using H(d,m) instead of random values. This method is considered cool and necessary to avoid issues with RNG such as leaked partial bits or biases, which can compromise security.The signature verification relation is provided, involving the calculation of [H(m)s^-1G+rs^-1Q].x=?r. The discussion also addresses the issue of malleability and suggests that plugging the (r,s), (r,-s) specific case as a DSA-specific workaround may not fully address all malleability issues. It is proposed that ECS (schnorr) be added since it is simpler and more efficient.In conclusion, a more generic and robust solution is proposed by Adam Back to fix the issue of malleability in conditional payments. Changing the txid to H(pubkey,inputs,outputs,script) would ensure the security of these payments, regardless of any malleability in the signature mechanism.


Updated on: 2023-08-01T05:59:19.180789+00:00