Published on: 2015-05-19T12:48:20+00:00
The discussion revolves around the proposal to include the height in transactions without adding an extra field. It is suggested that for non-coinbase transactions, the height used is zero, while for coinbase transactions, the height specified in the scriptSig is copied into the locktime of the transaction before computing the normalized transaction ID.However, it is argued that there's no need to replace lock times or any other part of the transaction. Instead, the height can be serialized right before serializing the transaction, and 0 can be pre-serialized for non-coinbase transactions. The normalization process for non-coinbase transactions involves replacing prevout hash with normalized hash and clearing the scriptSig. Finally, the transaction is serialized using CHashWriter.Christian Decker raises concerns about addressing BIP 34 and avoiding hashed transactions in different ways. Tier Nolan responds by suggesting that the normalized TXID should not depend on the height for non-coinbase transactions, as it would cause mutation when added to the chain. For coinbase transactions, they want the height to be included. The height is proposed to be included in the scriptSig for all transactions, with a height of zero for non-coinbase transactions. Adding an extra field to include the height is not necessary. A rule can be implemented where the height specified in the scriptSig in coinbase transactions is copied into the locktime of the transaction before computing the normalized transaction ID. Nolan suggests that the normalized txid could add the height to the txids of all inputs, while non-coinbase transactions would have heights of zero. The scriptSig in the coinbase is intended to be "random" bytes/extra nonce, so putting a restriction on it was guaranteed to be backward compatible.In an email exchange from May 19, 2015, Christian Decker proposes two proposals to address BIP 34. He suggests including the height in the scriptSig for all transactions, with non-coinbase transactions using a height of zero. The normalized txid function could incorporate the height without any specific inclusion method. The previous txid for coinbases is required to be all zeros, so the normalized txid could add the height to the txids of all inputs. Decker assumes that the scriptSig in the coinbase is intended to be random and therefore backward compatible.Christian Decker proposed a BIP to normalize transaction IDs to address transaction malleability and simplify higher-level protocols. The normalized transaction ID is calculated by removing the scriptSig before computing the hash, ensuring that only data guaranteed by the signatures influences the hash. This guarantees that any change to the normalized ID will invalidate the signature. Validating clients supporting this BIP would use both the normalized tx ID and the legacy tx ID when validating transactions. Template transactions can now be used to build sequences of transactions before signing them. The proposal requires a hardfork but suggests that hardforks should not be feared. The details of how the hardfork is to be done were left out, as it does not matter, and a good mechanism may exist to apply multiple hardforks concurrently in the future.Stephen raises concerns about how BIP34 affects normalized transaction ids in a discussion about implementing a new block height rule. He suggests that normalized txids should strip scriptSigs of all transactions except for coinbase transactions to prevent replay attacks. Another contributor agrees and proposes replacing the scriptSig for coinbases with the height expressed as a varint, which would give all coinbases a unique normalized txid while still preventing spendable duplicates.In an email exchange, s7r discusses the issue of scriptSig and txid being stripped for safety against replays. However, this method is not safe enough as it does not account for multiple scriptPubKeys per transaction. Instead, Luke proposes a scriptPubKey-only sighash type that would provide strong safety in all malleability situations. This would enable advanced wallet software to take advantage of it in the future while strictly enforcing no-reuse on its own wallet to avoid known replays.In response to s7r's question about how a certain process can be safe against malleability of the parent transaction and replays, it is explained that the signature signs everything except itself and the normalized txid doesn't include the signature, so mutations of the signature won't change the normalized txid. If the refund transaction refers to the parent using the normalized txid, then it doesn't matter if the parent has a mutated signature, as the normalized transaction ignores such changes. If there are two transactions that are mutations of each other, only one can be added to the blockchain since the other is a double spend. The normalized txid refers to all of them rather than a specific transaction. Mutation is only a problem if it occurs after signing.
Updated on: 2023-08-01T12:44:01.437339+00:00