So what exactly is used to create the normalized txid (sha256 hash of what data)? I've read in the linked BIP draft that it will strip the 'malleable parts' but didn't understand what exactly will be used to calculate the normalized transactions ids and how will the change apply retro-active for the transactions so deep buried in the blockchain?
Pubkeys (addresses) can be reused infinitely so what guarantees us unique normalized txids all the time and protection against replay attacks? The question is not if this issue is covered or not, I know it is, I am just asking how, in simpler terms. SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document. Will it also fix > third level malleability (a tx which spends from another unconfirmed tx which spends from yet another unconfirmed tx)? On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote: > On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > As with the previous version, which was using a hard-fork, the > normalized transaction ID is computed only considering the > non-malleable parts of a transaction, i.e., stripping the signatures > before computing the hash of the transaction. > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > Is this proposal recursive? > > *Coinbase transaction > * > > * n-txid = txid > > *Non-coinbase transactions > * > * replace sigScripts with empty strings > * replace txids in TxIns with n-txid for parents > > The 2nd step is recursive starting from the coinbases. > > In effect, the rule is that txids are what they would have been if > n-txids had been used right from the start. > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
