As all hashes, txids, and weights are always computed over a reserialized version of a transaction, it is mostly harmless to permit extended encoding for non-segwit transactions, but I'd rather strictly follow the BIP.
Disallow extended encoding for non-witness transactionsbb530efa18
MarcoFalke
commented at 6:06 PM on August 24, 2018:
member
To fix the test failure you could try rebasing on fae040010deda9404b15b214cec2a099fb831253
I have no opinion on this change itself. Is there any evidence of other software using this on the p2p or rpc interface? Also note that Bitcoin Core will already normalize the transaction encoding when relaying txs.
MarcoFalke referenced this in commit 653b2b4426 on Apr 26, 2019
MarcoFalke added the label Needs backport on Apr 26, 2019
MarcoFalke removed the label Needs backport on Apr 26, 2019
MarcoFalke added the label Needs backport on Apr 26, 2019
MarcoFalke added this to the milestone 0.18.1 on Apr 26, 2019
sidhujag referenced this in commit fd6ff32bc6 on Apr 27, 2019
sidhujag referenced this in commit 4a65581154 on Apr 27, 2019
moneyball
commented at 8:24 PM on April 29, 2019:
contributor
Out of curiosity do we have any sense for whether such misformatted transactions occur and if so with what frequency?
sipa
commented at 8:37 PM on April 29, 2019:
member
@moneyball This is just about the encoding; it's not a properry of the transaction at all. Before this PR, If someone were to use the invalid encoding on a particular P2P link, it would still be propagated in the correct form on further links.
MarcoFalke
commented at 8:50 PM on April 29, 2019:
member
Though, it wouldn't be propagated on p2p after this pull. And also rejected by any RPC call.
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-05-19 06:54 UTC