rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 Original date posted:2015-10-20 📝 Original message:On Tue, Oct 20, 2015 at 12:23 AM s7r via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > 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? > The normalization involves two steps: - strip the scriptSig scripts in the inputs, i.e., the only part whose integrity is not guaranteed by the signature itself, by replacing the scripts with empty strings (var length string of size 0) - replace the hashes referencing the outputs being spent with the normalized hashes of the transaction that created the outputs. This is done recursively down to the first v2 transactions. The second part is not yet explained in the draft, but I will amend it as soon as possible. > 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. > Non-coinbase transactions can still not be replayed since the normalized transaction still includes a the normalized transaction hashes of claimed outputs, hence any attempt to replay a transaction would fail since the outputs were already spent. For coinbase transactions it is indeed possible that we create multiple transactions with the same hash (only one of which would be spendable), hence we do not strip coinbase transactions and rely on BIP 34 to make the coinbase transactions unique (except for blocks 91842 and 91880 which are the reason we introduced BIP 34 in the first place). Clarifying the way the normalized transaction ID is computed should remove any ambiguities I hope. > > 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)? > Yes, if the computation of the normalized transaction ID includes replacing input hashes with their normalized counterpart makes a chain of any depth non-malleable. HTH, Christian > > > 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 at lists.linuxfoundation.org > > <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151020/2655d737/attachment.html>