This BIP makes 64 byte bitcoin transactions serialized without the witness consensus invalid
Mailing list post: https://groups.google.com/g/bitcoindev/c/rf3QOlzg230/m/eOOC8pkOAgAJ
Delving discussion: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
Side note, wasn’t sure how to best handle the 2-Bitcoin-Merkle.pdf as it isn’t hosted anywhere easily accessible AFAICT? For now I just added it into the git repo. Lmk if you have other suggestions
I am a little surprised at this pull request, given the frequent coverage of Antoine’s ongoing research on reviving the Great Consensus Cleanup that includes a similar fix. It seems better to me to package all four fixes in one soft fork. Was it overlooked that this work is being duplicated, or are you disagreeing with the direction of Antoine’s work and want to put forward an alternative? Could you elaborate why you decided to submit this?
HI Murch!
Great Consensus Cleanup
While the GCC is a great name for a disjoint set of bitcoin protocol security fixes, that doesn’t mean they all need to be bundled into one BIP and deployed at the same time.
It seems better to me to package all four fixes in one soft fork.
This document takes no opinion on how this enhancement is deployed.
Previously we have deployed multiple consensus changes in a single soft fork that contained multiple BIPs. The 2017 Segwit soft fork had BIP141, BIP143. The Taproot soft fork had BIP341 and BIP342.
Was it overlooked that this work is being duplicated,
I was recommended that this was a piece of work that was easily to peel off from the rest of GCC and propose a fix for. Its relatively simple and straight forward, and has been known about for a long time.
Antoine’s on going research.
I think Antoine’s research is great, but just because he is researching the topic doesn’t mean he gets to monopolize the vulnerabilities. The 64 byte transaction vulnerability has been known since at least 2012 - yet no one has taken the time to write up a BIP to fix it 😬 . I’ve put forth the first BIP draft in the 13 years since this vulnerability has been known. I encourage Antoine to write up his proposal (hopefully sooner rather than later) as he doesn’t seem to be interested in working with me.
Other vulnerabilities in GCC have also been known about for a long time - such as worse case block validation time. Antoine has done a lot of novel research there and I think his work product has been excellent on delving.
There is plenty of meat left on the GCC bone, this was a small piece I decided to carve off.
15+We describe the weaknesses to the merkle tree included in bitcoin block headers, various exploits for those weaknesses.
16+
17+==Motivation==
18+
19+Bitcoin block headers include a commitment to the set of transactions in a given
20+block, which is implemented by constructing a Merkle tree of transaction id’s
0block, which is implemented by constructing a Merkle tree of transaction ids
24+transaction. However, Bitcoin’s particular construction of the Merkle tree has
25+several security weaknesses, including at least two forms of block malleability
26+that have an impact on the consensus logic of Bitcoin Core, and an attack on
27+light clients, where an invalid transaction could be ”proven” to appear in a block
28+by doing substantially less work than a SHA256 hash collision would require.
29+This has been prevented by relay policy since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows 64 byte transactions in bitcoin core relay]</ref>
Bitcoin Core is a proper noun:
0This has been prevented by relay policy since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR [#11423](/bitcoin-bips/11423/) disallows 64-byte transactions in Bitcoin Core relay]</ref>
28+by doing substantially less work than a SHA256 hash collision would require.
29+This has been prevented by relay policy since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows 64 byte transactions in bitcoin core relay]</ref>
30+
31+==Specification==
32+
33+This BIP disallows bitcoin transactions that are serialized to 64 bytes in length without it's witness.
0This BIP disallows bitcoin transactions that are serialized to 64 bytes in length without its witness.
Could you explain the exact semantics of how and where such transactions are disallowed?
Do you mean e.g., that a block including a 64-byte transaction must be rejected as invalid?
0@@ -0,0 +1,140 @@
1+<pre>
2+ BIP: ?
3+ Layer: Consensus (soft fork)
4+ Title: Disallow 64 byte transactions
Here and in the following, when used as an adjective, “64-byte” is commonly hyphenated.
0 Title: Disallow 64-byte transactions
0@@ -0,0 +1,140 @@
1+<pre>
2+ BIP: ?
3+ Layer: Consensus (soft fork)
4+ Title: Disallow 64 byte transactions
5+ Author: Chris Stewart <stewart.chris1234@gmail.com>
6+ Status: Draft
7+ Type: Specification
8+ License: BSD-3-Clause
9+ Created: ?
0 Created: ?
1 License: BSD-3-Clause
0@@ -0,0 +1,140 @@
1+<pre>
2+ BIP: ?
3+ Layer: Consensus (soft fork)
4+ Title: Disallow 64 byte transactions
5+ Author: Chris Stewart <stewart.chris1234@gmail.com>
6+ Status: Draft
7+ Type: Specification
0 Type: Standards Track
0@@ -0,0 +1,140 @@
1+<pre>
2+ BIP: ?
3+ Layer: Consensus (soft fork)
4+ Title: Disallow 64 byte transactions
5+ Author: Chris Stewart <stewart.chris1234@gmail.com>
I’m afraid that BIP 2 is still Active, and BIP 3 is not yet:
0 Author: Chris Stewart <stewart.chris1234@gmail.com>
1 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
62+This attack vector was fixed in 0.6.2<ref>[https://bitcoin.org/en/alert/2012-05-14-dos#risks CVE-2012-2459]</ref>, re-introduced in 0.13.x<ref>[https://github.com/bitcoin/bitcoin/pull/7225 #7225]</ref> and patched again in
63+0.14<ref>[https://github.com/bitcoin/bitcoin/pull/9765 #9765]</ref> of bitcoin core.
64+
65+==== Block malleability with consensus VALID transactions ====
66+
67+Producing a valid bitcoin transaction T<sub>m</sub> that adheres to network consesnsus
0Producing a valid bitcoin transaction T<sub>m</sub> that adheres to network consensus
85+with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
86+was included in a bitcoin block rather than T with 81 bits<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf An attacker who can do 81 bits of work (followed by another 40 bits of work, to
87+construct the funding transaction whose coins will be spent by this one) is able
88+to fool an SPV client in this way.]</ref> of work. This also reduces implementation complexity of SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a merkle proof for a transaction is secure.]</ref>.
89+
90+This could be mitigated by knowing the depth of the merkle tree. Requiring SPV clients to request both the coinbase transaction could mitigate this attack.
91+To produce a valid coinbase transaction at the same depth that our fake transaction F occurs at would require 224 bits of work.
92+As mentioned above, this is computionally and financially expensive, but theoretically possible.
93+
94+==Backward compatibility==
95+
96+There have been 5 64 byte transactions that have occcurred in the bitcoin blockchain as of this
30+
31+==Specification==
32+
33+This BIP disallows bitcoin transactions that are serialized to 64 bytes in length without it's witness.
34+
35+==Rationale==
This does seem like a reasonable start for a BIP. A few parts of the content could perhaps be organized a bit differently, and some sections could be expanded. Especially the Specification could be a bit more precise in what an implementation should do to be compliance with this BIP. I left you a few editorial nits that you could perhaps take a look at.
It seems likely to me that this submission may be duplicating some effort on all of our ends, assuming that the other anticipated BIP gets submitted near-term, but fair enough, we have not received another BIP on this topic. I guess I can’t fault multiple people for being interested in the same topic.
11+</pre>
12+
13+==Abstract==
14+
15+This BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
16+We describe the weaknesses to the merkle tree included in bitcoin block headers, various exploits for those weaknesses.
0We describe the weaknesses to the Merkle tree included in bitcoin block headers, and various exploits for those weaknesses.
(Suggest using consistent capitalization of “merkle” in this document, here and for the other instances)
15+This BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
16+We describe the weaknesses to the merkle tree included in bitcoin block headers, various exploits for those weaknesses.
17+
18+==Specification==
19+
20+This BIP disallows bitcoin transactions that are serialized to 64 bytes in length without its witness.
s/its/their/, or “transaction” in the singular form
0This BIP disallows bitcoin transactions that are serialized to 64 bytes in length without their witness.
29+transaction. However, Bitcoin’s particular construction of the Merkle tree has
30+several security weaknesses, including at least two forms of block malleability
31+that have an impact on the consensus logic of Bitcoin Core, and an attack on
32+light clients, where an invalid transaction could be ”proven” to appear in a block
33+by doing substantially less work than a SHA256 hash collision would require.
34+This has been prevented by relay policy and RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows 64-byte transactions in Bitcoin Core relay and RPC interface]</ref>.
0This has been prevented by relay policy and the RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR [#11423](/bitcoin-bips/11423/) disallows 64-byte transactions in Bitcoin Core relay and RPC interface]</ref>.
47+==== Block malleability with consensus INVALID transactions ====
48+
49+The peer receiving the malicious block marks the block as invalid as T<sub>m</sub>
50+is not a valid transaction according to network consensus rules.
51+Other peers on the network receive the valid block containing T<sub>0</sub> and T<sub>1</sub>
52+add the block to their blockchain. Peers that receive the invalid block before the valid block
IIUC
0and add the block to their blockchain. Peers that receive the invalid block before the valid block
49+The peer receiving the malicious block marks the block as invalid as T<sub>m</sub>
50+is not a valid transaction according to network consensus rules.
51+Other peers on the network receive the valid block containing T<sub>0</sub> and T<sub>1</sub>
52+add the block to their blockchain. Peers that receive the invalid block before the valid block
53+will never come to consensus with their peers due to the malicious user finding a collision
54+within the block's merkle root. Finding this collision approximately 22 bits worth of work<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf to produce a block that has a Merkle
116+
117+====Segwit 64-byte transactions====
118+
119+This BIP disallows single-input single output segwit transactions that pay to a 2 byte witness program.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]</ref>
120+The only known use case<ref>[https://bitcoin.stackexchange.com/a/110664 Why do we have 2 byte witness programs? The original rationale for the lower end of the range of valid witness program lengths is that 2 bytes is enough to guarantee no ambiguity of how the program would be pushed (some 1 byte values can - and according to standardness, must - be pushed with OP_n, and dealing with those would have complicated the matter).]</ref>
121+for this type of transaction is ephemeral anchor outputs<ref>[https://bitcoinops.org/en/topics/ephemeral-anchors/ What are ephemeral anchor outputs? This allows anyone on the network to use that output as the input to a child transaction. This allows anyone to create the fee-paying child, even if they don’t receive any of the other outputs from the parent transaction. This allows ephemeral anchors to function as fee sponsorship but without requiring any consensus changes.]</ref>
0for this type of transaction is ephemeral anchor outputs.<ref>[https://bitcoinops.org/en/topics/ephemeral-anchors/ What are ephemeral anchor outputs? This allows anyone on the network to use that output as the input to a child transaction. This allows anyone to create the fee-paying child, even if they don’t receive any of the other outputs from the parent transaction. This allows ephemeral anchors to function as fee sponsorship but without requiring any consensus changes.]</ref>
108+The largest scriptSig a 64-byte transaction can have is 4 bytes.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73]</ref>
109+
110+There are 6<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/nonstandard-hashlock-utxos.txt As of block `00000000000000000001194ae6be942619bf61aa70822b9643d01c1a441bf2b7` there exist 6 nonstandard hashlock utxos that could theoretically have a 0-3 byte pre-image. None of them have a 0-3 byte pre-image.]</ref>
111+non standard hashlock utxos in the bitcoin blockchain. None of them have a 0-3 byte pre-image. This means they cannot be spent by a 64-byte transaction.
112+
113+Pre-segwit 64-byte transactions that spend a nonstandard utxo that are inherently malleable<ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]</ref>.
0Pre-segwit 64-byte transactions that spend a nonstandard utxo that are inherently malleable.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]</ref>
97+
98+==Backward compatibility==
99+
100+There have been 5 64-byte transactions that have occcurred in the bitcoin blockchain as of this
101+writing <ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/64byte-tx-mainnet.txt 64-byte transactions in the bitcoin blockchain]</ref>
102+With the last transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612<ref>[https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 Last 64-byte transaction in the bitcoin blockchain]</ref>
0with the last transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612<ref>[https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 Last 64-byte transaction in the bitcoin blockchain]</ref>
124+
125+<source lang="cpp">
126+/**
127+ * We want to enforce certain rules (specifically the 64-byte transaction check)
128+ * before we call CheckBlock to check the merkle root. This allows us to enforce
129+ * malleability checks which may interact with other CheckBlock checks.
0 * malleability checks that may interact with other CheckBlock checks.
127+ * We want to enforce certain rules (specifically the 64-byte transaction check)
128+ * before we call CheckBlock to check the merkle root. This allows us to enforce
129+ * malleability checks which may interact with other CheckBlock checks.
130+ * This is currently called both in AcceptBlock prior to writing the block to
131+ * disk and in ConnectBlock.
132+ * Note that as this is called before merkle-tree checks so must never return a
0 * Note that this is called before merkle-tree checks and so must never return a
144+
145+ return true;
146+}
147+</source>
148+
149+https://github.com/bitcoin-inquisition/bitcoin/pull/24/files
0+This sample implementation is currently an open pull request here:
1+
2https://github.com/bitcoin-inquisition/bitcoin/pull/24/files
29+transaction. However, Bitcoin’s particular construction of the Merkle tree has
30+several security weaknesses, including at least two forms of block malleability
31+that have an impact on the consensus logic of Bitcoin Core, and an attack on
32+light clients, where an invalid transaction could be ”proven” to appear in a block
33+by doing substantially less work than a SHA256 hash collision would require.
34+This has been prevented by Bitcoin Core's relay policy and the RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows 64-byte transactions in Bitcoin Core relay and RPC interface]</ref>.
Now that “Bitcoin Core’s” was added.
0This has been prevented by Bitcoin Core's relay policy and RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR [#11423](/bitcoin-bips/11423/) disallows 64-byte transactions in Bitcoin Core relay and RPC interface]</ref>.
10+ License: BSD-3-Clause
11+</pre>
12+
13+==Abstract==
14+
15+This BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
nit, extra space at EOL
0This BIP describes the rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
44+Next the malicious user relays the block containing the malicious T<sub>m</sub> rather than the
45+valid bitcoin transactions that correspond with T<sub>0</sub> and T<sub>1</sub>.
46+
47+==== Block malleability with consensus INVALID transactions ====
48+
49+The peer receiving the malicious block marks the block as invalid as T<sub>m</sub>
nit, extra space at EOL
0The peer receiving the malicious block marks the block as invalid as T<sub>m</sub>
@Christewart Antoine just opened a pull request for the Consensus Cleanup which includes the 64-byte transaction fix: #1800
If you don’t feel too strongly about this being a separate BIP, I think it would be better to withdraw it, otherwise it’ll just be duplicating effort with no obvious benefit.
Hi @vostrnad,
As of this commit, PR #1800 does not provide as much detail as this document in defining the problem with 64-byte transactions, explaining the proposed solution, and demonstrating why it does not pose a confiscatory risk.
I hope the author of #1800 will consider expanding the BIP with more detail or breaking it into separate proposals for each consensus change. However, based on this email, it seems they believe the current content is sufficient and only requires minor edits.
At this time, I believe my document is of higher quality. I will not be voluntarily closing my BIP until I feel #1800 reaches parity.
Let’s call this BIP 53. Please update the table entry preamble and title correspondingly.
Done in 23e01bf
29+transaction. However, Bitcoin’s particular construction of the Merkle tree has
30+several security weaknesses, including at least two forms of block malleability
31+that have an impact on the consensus logic of Bitcoin Core, and an attack on
32+light clients, where an invalid transaction could be ”proven” to appear in a block
33+by doing substantially less work than a SHA256 hash collision would require.
34+This has been prevented by Bitcoin Core's relay policy and the RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR #11423 disallows transactions that are less than 82 bytes in size from Bitcoin Core relay and RPC interface]</ref><ref>[https://github.com/bitcoin/bitcoin/commit/8c5b3646b5afe8a61f5c66478d8e11f0d2ce5108 Reduces the minimum transaction size required for a transaction to be considered standard from 82 bytes to 65 bytes]</ref>.
Given that such transaction were still valid, just nonstandard, I’m not sure that “prevented” is the right term. How about mitigated?
0This has been mitigated by Bitcoin Core's relay policy and the RPC interface since 2018<ref>[https://github.com/bitcoin/bitcoin/pull/11423/commits/7485488e907e236133a016ba7064c89bf9ab6da3 PR [#11423](/bitcoin-bips/11423/) disallows transactions that are less than 82 bytes in size from Bitcoin Core relay and RPC interface]</ref><ref>[https://github.com/bitcoin/bitcoin/commit/8c5b3646b5afe8a61f5c66478d8e11f0d2ce5108 Reduces the minimum transaction size required for a transaction to be considered standard from 82 bytes to 65 bytes]</ref>.
74+This is computationally and financially expensive but theoretically possible. This can lead to a persistent chain split on the network.
75+
76+=== Attack on SPV clients ===
77+
78+BIP37<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP37]</ref>provides a partial merkle tree format<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#user-content-Partial_Merkle_branch_format Partial Merkle Tree Format]</ref>
79+that allows you to verify your bitcoin transaction is included in a merkle root embedded in a bitcoin block header.
0that allows you to verify that your bitcoin transaction is included in a merkle root embedded in a bitcoin block header.
82+Suppose a (valid) 64-byte transaction T is included in a block with the property that the second 32 bytes (which
83+are less constrained than the first 32 bytes) are constructed so that they collide
84+with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
85+was included in a bitcoin block rather than T with 81 bits<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf An attacker who can do 81 bits of work (followed by another 40 bits of work, to
86+construct the funding transaction whose coins will be spent by this one) is able
87+to fool an SPV client in this way.]</ref> of work. This also reduces implementation complexity of SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a merkle proof for a transaction is secure.]</ref>.
0to fool an SPV client in this way.]</ref> of work. This also reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a merkle proof for a transaction is secure.]</ref>.
102+with the last transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612<ref>[https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 Last 64-byte transaction in the bitcoin blockchain]</ref>
103+occurring at block height 419,606<ref>[https://mempool.space/block/000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84 Block 419,606]</ref>.
104+
105+====Pre segwit 64-byte transactions====
106+
107+64-byte transactions cannot spend a utxo protected by a digital signature.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki After BIP66 was activated on the bitcoin network, bitcoin transactions cannot have a digital signature smaller than 9 bytes.]</ref>
0Pre-segwit 64-byte transactions cannot spend a utxo protected by a digital signature.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki After BIP66 was activated on the bitcoin network, bitcoin transactions cannot have a digital signature smaller than 9 bytes.]</ref>
103+occurring at block height 419,606<ref>[https://mempool.space/block/000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84 Block 419,606]</ref>.
104+
105+====Pre segwit 64-byte transactions====
106+
107+64-byte transactions cannot spend a utxo protected by a digital signature.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki After BIP66 was activated on the bitcoin network, bitcoin transactions cannot have a digital signature smaller than 9 bytes.]</ref>
108+The largest scriptSig a 64-byte transaction can have is 4 bytes.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73]</ref>
0The largest scriptSig a pre-segwit 64-byte transaction can have is 4 bytes.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73]</ref>
0@@ -0,0 +1,162 @@
1+<pre>
2+ BIP: 53
3+ Layer: Consensus (soft fork)
4+ Title: Disallow 64-byte transactions
5+ Author: Chris Stewart <stewart.chris1234@gmail.com>
6+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-53
7+ Status: Draft
8+ Type: Standards Track
9+ Created: ?
0 Created: 2025-04-11
148+
149+The sample implementation is currently open here:
150+
151+https://github.com/bitcoin-inquisition/bitcoin/pull/24/files
152+
153+== Rationale ==
91+===SPV clients===
92+
93+Attacks on SPV clients could be mitigated by knowing the depth of the merkle tree. Requiring SPV clients to request both the coinbase and payment transaction could mitigate this attack.
94+To produce a valid coinbase transaction at the same depth that our fake transaction F occurs at would require 224 bits of work.
95+As mentioned above, this is computionally and financially expensive, but theoretically possible. This design would increase the size
96+of SPV proofs by 70%.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/29?u=chris_stewart_5 Base proof: 80 byte header + 448 byte partial merkle tree = 528 bytes. Proof with coinbase tx, assuming the coinbase tx is in the left half of the tree and the tx to prove is in the right half of the tree: 80 byte header + 416 bytes partial merkle tree for coinbase tx + 416 bytes partial merkle tree for tx = 912 bytes.]</ref>
0of SPV proofs by 70%.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/29?u=chris_stewart_5 Base proof: 80-byte header + 448-byte partial merkle tree = 528 bytes. Proof with coinbase tx, assuming the coinbase tx is in the left half of the tree and the tx to prove is in the right half of the tree: 80-byte header + 416 bytes partial merkle tree for coinbase tx + 416 bytes partial merkle tree for tx = 912 bytes.]</ref>
114+Policy rules such as CLEANSTACK, MINIMALDATA, PUSHONLY are not consensus rules. If a user has a way to confirm an already non-standard
115+64-byte transaction - they can malleate the transaction by violating policy rules to change the size of the transaction to a size other than 64 bytes.
116+
117+====Segwit 64-byte transactions====
118+
119+This BIP disallows single-input single output segwit transactions that pay to a 2 byte witness program.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]</ref>
0This BIP disallows single-input single-output segwit transactions that pay to a 2-byte witness program.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]</ref>
115+64-byte transaction - they can malleate the transaction by violating policy rules to change the size of the transaction to a size other than 64 bytes.
116+
117+====Segwit 64-byte transactions====
118+
119+This BIP disallows single-input single output segwit transactions that pay to a 2 byte witness program.<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]</ref>
120+The only known use case<ref>[https://bitcoin.stackexchange.com/a/110664 Why do we have 2 byte witness programs? The original rationale for the lower end of the range of valid witness program lengths is that 2 bytes is enough to guarantee no ambiguity of how the program would be pushed (some 1 byte values can - and according to standardness, must - be pushed with OP_n, and dealing with those would have complicated the matter).]</ref>
0The only known use case<ref>[https://bitcoin.stackexchange.com/a/110664 Why do we have 2-byte witness programs? The original rationale for the lower end of the range of valid witness program lengths is that 2 bytes is enough to guarantee no ambiguity of how the program would be pushed (some 1-byte values can — and according to standardness, must — be pushed with OP_n, and dealing with those would have complicated the matter).]</ref>
109+
110+There are 6<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/nonstandard-hashlock-utxos.txt As of block `00000000000000000001194ae6be942619bf61aa70822b9643d01c1a441bf2b7` there exist 6 nonstandard hashlock utxos that could theoretically have a 0-3 byte pre-image. None of them have a 0-3 byte pre-image.]</ref>
111+non standard hashlock utxos in the bitcoin blockchain. None of them have a 0-3 byte pre-image. This means they cannot be spent by a 64-byte transaction.
112+
113+Pre-segwit 64-byte transactions that spend a nonstandard utxo that are inherently malleable.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]</ref>
114+Policy rules such as CLEANSTACK, MINIMALDATA, PUSHONLY are not consensus rules. If a user has a way to confirm an already non-standard
I think “non-standard” is more common in the context of transactions. Could you use either “non-standard” or “nonstandard” throughout the document?
0There are 6<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/nonstandard-hashlock-utxos.txt As of block `00000000000000000001194ae6be942619bf61aa70822b9643d01c1a441bf2b7` there exist 6 non-standard hashlock utxos that could theoretically have a 0-3 byte pre-image. None of them have a 0-3 byte pre-image.]</ref>
1non-standard hashlock utxos in the bitcoin blockchain. None of them have a 0-3 byte pre-image. This means they cannot be spent by a 64-byte transaction.
2
3Pre-segwit 64-byte transactions that spend a non-standard utxo that are inherently malleable.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]</ref>
4Policy rules such as CLEANSTACK, MINIMALDATA, PUSHONLY are not consensus rules. If a user has a way to confirm an already non-standard
53+will never come to consensus with their peers due to the malicious user finding a collision
54+within the block's merkle root. Finding this collision is approximately 22 bits worth of work.<ref>[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/bip-XXXX/2-BitcoinMerkle.pdf to produce a block that has a Merkle
55+root which is a hash of a 64-byte quantity that deserializes validly, it’s enough
56+to just do 8 bits of work to find a workable coinbase (which will hash to the first
57+32 bytes), plus another ≈22 bits of work ((1/5) ∗224, so slightly less) to find
58+a workable second transaction which will hash to the second 32 bytes) – a very
0a workable second transaction which will hash to the second 32 bytes)—a very
73+only 16 bytes or so are constrained, so approximately 128 bits of work to find a collision). Of course, any of the rows in the Merkle tree could be used, but it nevertheless seems clear that this should be computationally infeasible.]</ref>.
74+This is computationally and financially expensive but theoretically possible. This can lead to a persistent chain split on the network.
75+
76+=== Attack on SPV clients ===
77+
78+BIP37<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP37]</ref>provides a partial merkle tree format<ref>[https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki#user-content-Partial_Merkle_branch_format Partial Merkle Tree Format]</ref>
The document seems fairly complete content-wise, but the presentation could use more attention. Capitalization is a bit random: some acronyms are capitalized (“SPV”), but others are uncapitalized (e.g. “utxos”) and proper nouns are sometimes capitalized (Merkle, Bitcoin Core), sometimes not (merkle, bitcoin). Please either retitle one of the two Rationale sections or combine them.
It would be good if the proposal got more commentary or review from other contributors, but otherwise seems close to ready for a merge.
5@@ -6,7 +6,7 @@
6 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0053
7 Status: Draft
8 Type: Standards Track
9- Created: ?
10+ Created: 2024-12-20
According to BIP2, the “Created” header records the date a proposal was assigned a number, which is why I suggested 2025-04-11.
Yes I am. Child nap time only allows for so many things to get done at 1 time 😅. I’ll try to address the rest later today
On Tue, Apr 22, 2025 at 12:12 PM murchandamus @.***> wrote:
@.**** commented on this pull request.
I assume you are still working on my other suggestions, so I’ll take another look later.
In bip-0053.mediawiki https://github.com/bitcoin/bips/pull/1760#discussion_r2054517864:
@@ -6,7 +6,7 @@ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0053 Status: Draft Type: Standards Track
- Created: ?
- Created: 2024-12-20
According to BIP2 https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-header-preamble, the “Created” header records the date a proposal was assigned a number, which is why I suggested 2025-04-11.
image.png (view on web) https://github.com/user-attachments/assets/5ac62de5-00b6-455e-940f-f22c88d228e1
— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/1760#pullrequestreview-2784772967, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA22ETNRE5UYZ32HHFCPFTD22ZZ6DAVCNFSM6AAAAABW3SF3JSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDOOBUG43TEOJWG4 . You are receiving this because you were mentioned.Message ID: @.***>
The document seems fairly complete content-wise, but the presentation could use more attention. Capitalization is a bit random: some acronyms are capitalized (“SPV”), but others are uncapitalized (e.g. “utxos”) and proper nouns are sometimes capitalized (Merkle, Bitcoin Core), sometimes not (merkle, bitcoin).
Ok think this is addressed in f797b9f, bd815e9, acda401
Please either retitle one of the two Rationale sections or combine them.
Sorry this was a bit unclear could you be more specific of what you would like to see?
Apologies, I see what you are talking about now and this is fixed in 5a89036.
Also I missed some code review due to github.com collapsing some comments, hopefully everything is addressed now with 5a89036
Also I missed some code review due to github.com collapsing some comments, hopefully everything is addressed now with 5a89036
Yeah, I think I see what happened: when you started by moving the file, it marked all of my review comments as outdated, because they had been left on the old file. ;)
Reviewed the changes, looks much better, thanks. :)
What’s your plan for this proposal? Do you see it as a standalone soft fork that can be merged as is on its own, or are you working on additional parts? What is the intended deployment strategy?
Do you see it as a standalone soft fork that can be merged as is on its own
This is possible if the community wants to do this.
or are you working on additional parts?
I am not at this time.
What is the intended deployment strategy?
I don’t have one at this time. Recent precedent with BIP148 and BIP343 details activating the last 2 soft forks that contained a variety of BIPs.
These activation BIPs were written by a different set of people than the BIP authors for taproot and segwit. I assume something like this will have to happen again as it seems like there isn’t really another realistic path to deploying soft forks IMO.
155+==Copyright==
156+This BIP is licensed under the [https://opensource.org/license/BSD-3-Clause BSD-3-Clause License].
157+
158+==Acknowledgements==
159+
160+Suhas Daftuar, AJ Towns, Sergio Demian Lerner, Greg Maxwell, Matt Corallo, Antoine Poinsont, Dave Harding and Erik Voskuil
0Suhas Daftuar, AJ Towns, Sergio Demian Lerner, Greg Maxwell, Matt Corallo, Antoine Poinsot, Dave Harding and Eric Voskuil
Okay, is there anything else that is missing from your perspective before this can be merged?
I thought about this a bit more, there are 2 things that could potentially be addressed. I would like to hear your opinion.
How BIP3 defines the Rationale section:
The rationale should record relevant objections or important concerns that were raised and addressed as this proposal was developed.
One concern that was raised on the mailing list by Jeremy Rubin and agreed by Eric Voskuil was that disallowing 64 byte transaction
“might integrate very poorly with this kind of edge condition”
Do you think this is adequately addressed by this section of the BIP? I’m on the fence.
One other concern shared on the delving thread by Antoine Poinsot was sidechains may be vulnerable to the same merkle tree weakeness that SPV clients are. I haven’t investigated this further, but it could potentially merit a section the Motivation.
This currently isn’t at the top of my bitcoin research priorities, so if you think these things should be done I’ll address them next week.
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
we can also merge this PR as a draft and you can continue to iterate on it as you move it toward “Proposed”.
Lets do that. I rebased the PR to get rid of conflicts. Would you like me to squash everything into 1 commit as well?