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
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>
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.
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
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.