Great Consensus Cleanup Revival

Protocol Design
82

Ugh, thanks. I mixed up the binaries in my testing (due to a recent change in the location of binaries i had more than one bitcoind in my build directory, ran the one that did not enforce the check).

2 Likes
83

I’ve just published a BIP draft for a Consensus Cleanup soft fork. The post to the mailing list is apparently awaiting moderator approval but the PR to the BIPs repository is available here. Thanks to everyone who helped to bring it this far.

3 Likes
84

I was recently made aware that several Bitcoin side-systems in development were vulnerable to faked SPV proofs using 64-byte transactions. The impact varied from one side-system to another, but for some it was as critical as “an attacker can drain all the funds from the side-system”. This is a perfect illustration of the footgun concern: people don’t know about this obscure weakness and go about creating systems that rely on SPV proofs without the equally-obscure mitigation. It also illustrates the complexity concern: those proofs are often implemented in constrained environments such as smart contracts. The case for making 64-byte transactions invalid is stronger than i initially thought.

1 Like
85

I’m moving a conceptual discussion from the BIP PR to this thread. There, Luke Dashjr pointed out that since the nLockTime field is serialized at the very end of a transaction, it makes for a good extranonce. Luke has not provided any details so it’s difficult to address his objection precisely, but i can’t think of a realistic situation where not being able to roll the nLockTime would be a significant issue for a miner.

1 Like
86

To repeat the response I had there: why not just use a scriptPubKey? Since a coinbase doesn’t have input signatures that commit to outputs, there’d be no extra hashing either.

Also note that Stratum v2 spec suggests that ASICs roll the BIP320 version bits, and only pool software updates the coinbase extraNonce.

That’s enough for devices up to 280 TH/s. Beyond that devices could roll their timestamp a bit (though some people believe that should be discouraged) or handle multiple jobs in parallel. Both approaches avoid the need for an ASIC to deal with the block merkle tree.

1 Like
87

Extensive test vectors for BIP 54 were recently merged in the bips repository. You can find them here. An implementation for Bitcoin Inquisition is available here.

1 Like
88

If your coinbase tx (ignoring the witness) is N bytes, then appending a 0 sat output of the form OP_RETURN OP_PUSH[4+X] <X bytes padding> <4B nonce> where X=max(0,16-(N+23)%64) allows you to update the 4B nonce with only the final sha256 round, at a cost of between 15 to 31 bytes of additional coinbase data, achieving essentially the same benefit as using the coinbase nlocktime as a nonce (which requires between 0 and 12 bytes of padding for alignment anyway). If you’re already doing extranonce work via an OP_RETURN output, then there’s only 0-4 bytes of additional overhead to align the end of the final OP_RETURN data compared to aligning the nlocktime field in the first place.

32b of extra nonce in addition to 32b nNonce and 16b from BIP 320 and rolling nTime once per second gives 1200 zettahash/second (1.2 trillion TH/s), so about 1000x the total current hashrate.

89

Keep in mind that Bitcoin Core block templates reserve 8000 weight units by default for coinbase (and header). Afaik miners rarely push this to the limit (`-blockreservedweight` has a minimum of 2000, but patching can of course take it lower).

Ocean Pool uses extra large coinbases and Datum users are instructed ( GitHub - OCEAN-xyz/datum_gateway: Decentralized Alternative Templates for Universal Mining ) to set blockmaxweight=3985000 which means 15 kWu is reserved. In practice their coinbase transactions ( mempool - Bitcoin Explorer ) vary wildly in size, e.g. recently I saw one that was 3 kWu and another 9.4.

Perhaps in the future miners are going to be more concerned about squeezing every last byte out of a block, but at the moment 15 to 31 extra bytes would just eat into the existing safety margin and have no revenue effect.

90

I got forwarded the following feedback. In a CHECKMULTISIG(VERIFY), put a ceiling on the number of BIP54-sigops accounted for at 6.

My understanding is this is because the scriptCode is constant throughout the signature checks within a single CHECKMULTISIG(VERIFY) operation, and the 6 possible signature hashes could be cached. This cache is actually implemented in Bitcoin Core since version 30.0 (see #32473).

This is clever, and worth considering. But i wonder how much it matters in practice, as it’s only relevant to users of large transactions involving large legacy multisigs, which aren’t used anymore. Another downside is that it would complicate the implementation, since we wouldn’t be able to just reuse BIP16’s GetSigOpCount as-is anymore. Of course the upside is that it would more accurately budget the use of CHECKMULTISIG(VERIFY) in legacy Script to match validation cost, instead of overshooting.

I’ll put together a list of historical transactions that would have been valid according to this adapted rule but not according to today’s BIP54. Any opinions on the desirability of this change?

91

Turns out that not a single historical violation would have been valid with the suggested relaxation. In fact, it would have only change the number of BIP54-sigops accounted for a single historical violation, c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3 (8 less BIP54-sigops accounted for under the suggested rule). See the following table for more details.

Expand list of historical violations with sigops counts
txid sigops (current rule) sigops (suggested modification)
659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2 2585 2585
bea1c2b87fee95a203c5b5d9f3e5d0f472385c34cb5af02d0560aab973169683 4020 4020
24b16a13c972522241b65fbb83d09d4bc02ceb33487f41d1f2f620b047307179 3480 3480
53666009e036171b1aee099bc9cd3cb551969a53315410d13ad5390b8b4f3bd0 3480 3480
ffc178be118bc2f9eaf016d1c942aec18441a6c5ec17c9d92d1da7962f0479f6 8040 8040
2f1654561297114e434c4aea5ca715e4e3f10be0be8c1c9db2b6f68ea76dae09 12060 12060
62fc8d091a7c597783981f00b889d72d24ad5e3e224dbe1c2a317aabef89217e 7960 7960
d939315b180d3d73b5e316eb57a18f8137a3f5943aef21a811660d25f1080a3f 8040 8040
8a6bfaa78828a81147e4848372d491aa4e9048631982a670ad3a61402a4ec327 8040 8040
02cc78789cc070125817189ec378daa750355c8b22bbce982ed96aa549facb1f 8040 8040
b97a16ae2e8ae2a804ed7965373b42055f811653f4628e4bef999145d4b593bc 4020 4020
c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3 19971 19963
33ccdda65abdda8025adb03841410dda5fa8948bd38b7fbaf3fed521daf5c4d3 3980 3980
bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 5569 5569
ba588134ecc93fdbfa06f795c9bf7a05b09ca9ca9095659e401325d501a90363 3116 3116
ba6c6d2389f765f7873f5a9a7c11bf806afd784d15b0b8dff011fe95d1d5e841 3418 3418
dd49dc50b54b4bc1232e4b68cfdd3d349e49d3d7fe817d1041fff6dd583a6eaf 5000 5000
3d724f03e8bcc9e2e3ea79ebe4c6cffca86d85e510742cd6d3ac29d420787a34 5000 5000
8bcf8e8d8265922956bda9b651d2a0e993072c9dca306f3a132dcdb95c7cee6e 5000 5000
ba31c8833b7417fec9a84536f32fcb52d432acb66d99b9be6f3899686a269b2b 3600 3600
9cc0a350d50fa252264636e62d586c7121d0a5656bc7e6b27354325684bec007 3390 3390
dd5e32971010ef0c9f4cda8977830d727a6828165c69005a3fab67415c755b7d 3390 3390
66be4e766df2c23e08f4cf8c3e6cfa202b20967616ace38e1cbc1f20ee78db2e 3390 3390
e229a83deafec5f49e4990dba914fd815d05809f5eefbd979d55fb64f93827a3 3390 3390
901e3695838925dd020a085e8f078c393e64179dcf0a43134a1547d21acab49a 3390 3390
49ab4d05adbc3294fbbd63d3b876fb97a87a3f5090aa6b1d87f31ab1c4564235 3390 3390
c4f4357657ba403455167b2897acfcb922c2a0973c34e58733ca352394e6c629 3390 3390
6c3ee29a9b584fbeae60169f0abce573a7b768bf21398d4dfad9011aa7132530 3390 3390
5dc2bdc5ce29c52840f10203fd93ffed82da4cf49eddf93437dd1329baa9ade5 3390 3390
f40fd92f5e8cecf956caec4b6abe0b88decafde0ae71d16a72c41cb1a3da0d60 3390 3390
92b68e4a19ef47c0dd022727a9c4b8ceb9466ce752ad8995ffbc5948bdfabf57 3390 3390
1b604a075075197c82d33555ea48ae27e3d2724bc4c3f31650eff79692971fb7 3600 3600
5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311 5569 5569
14dd70e399f1d88efdb1c1ed799da731e3250d318bfdadc18073092aa7fd02c2 5569 5569
bb75a8d10cfbe88bb6aba7b28be497ea83f41767f4ee26217e311c615ea0132f 5000 5000
a684223716324923178a55737db81383c28f055b844d8196c988c70ee7075a9a 5569 5569
fa9120afe1bb09b7154ba82a022cbdcc29fc5be2699b346ebb7ffdc46807b2f7 3411 3411
5e640a7861695fa660343abde52cfe10b5a97dd8fc6ad3c5e4b2b4bb1c8c3dd9 5000 5000
7e7e69b4de5ef05750d27a863bdcb2d9dbc4a732c2a719f435ae5a9a4690b30f 2853 2853
d85ce71f583095a76fb17b5bb2a1cbf369e2a2867ca38103aa310cbb2aaf2921 3651 3651
905df97982a2904d6d1b3dfc272435a24d705f4c7e1fc4052798b9904ad5e597 3651 3651
5b0a05f12f33d2dc1507e5c18ceea6bb368afc51f00890965efcc3cb4025997d 5160 5160
cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8 5569 5569
66b614e736c884c1a064f7b0d6a9b0abd97e7bb73ac7e4b1b92b493d558a0711 4691 4691
9fdbcf0ef9d8d00f66e47917f67cc5d78aec1ac786e2abb8d2facb4e4790aad6 7350 7350
9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec 7350 7350
2e7c454cfc348aa220f53b5ba21a55efa3d36353265f085e34053c4efa575fda 4386 4386
484c8f9d1adf16a576bce52721a5e4edd5239df346d94fd730f6d7b681ab3652 2728 2728
e3d3d1ecec5d6b57792c793c413fc9b19189f5b932db8887d46f06abc101d24e 3314 3314
b23c99c30339cb93eb04790bc5213f7732365488fe2549802bb472084b6ec508 2810 2810
92f217ec13ab309240adc0798804b3418666344a5cbfff73fb7be8192dad5261 3524 3524
22e861ee83c3d23a4823a3786460119425d8183783068f7ec519646592fac8c2 3513 3513
fa5a58f787f569f5b8fab9dadb2447161fac45b36fb6c2c0f548ed0209b60663 3792 3792
767885bc144bdc0414217547f0169352a065083750371cabe5acbd0e0dd60436 2621 2621
461308024d89ea4231911df4ef24e65e60af2a9204c8282a6b67f4214c1714e7 3844 3844
9db4e0838c55ef20c5eff271fc3bf09a404fff68f9cdad7df8eae732500b983d 4294 4294
6e278c0ca05bf8e0317f991dae8a9efa141b5a310a4c18838b4e082e356ef649 4141 4141
9c972a02db30f9ee91cc02b30733d70d4e2d759b5d3c73b240e5026a8a2640c4 3991 3991
d38417fcc27d3422fe05f76f6e658202d7fa394d0c9f5b419fef97610c3c49f1 4746 4746
e32477636e47e1da5fb49090a3a87a3b8ff637d069a70cd5b41595da225e65b4 4667 4667
a7e0a86944e9750a3fe372dd318da7b81c4f4c4ab228741ba0cf7fb6d56d6640 3250 3250
f62f2c6a16b5da61eaae36d30d43bb8dd8932cd89b40d83623fa185b671c67f9 4199 4199
856a2117b6d81acbe6add60a114307d9572dff027079151d50ee77a7b0c70404 2575 2575
763e13f873afa5f24cd33fc570a178c65e0a79c05c88c147335834fc9e8f837b 4233 4233
c3f2c2df5388b79949c01d66e83d8bc3b9ccd4f85dbd91465a16fb8e21bf8e1b 4603 4603
e245f6c3c6b02dc81ea1b6694735565cc535f603708783be027d0e6a94ac3bd5 3856 3856
02313ac62ca8f03930cdc5d2e437fabc05aea60a31ace18a39678c90b45d32bd 3895 3895
01d23d32bccc04b8ca5a934be16da08ae6a760ccaad2f62dc2f337eee7643517 4377 4377
d985c42bcd704aac88b9152aede1cca9bbb6baee55c8577f84c42d600cfec8e4 4680 4680
6bb39576292c69016d0e0c1fe7871640aab12dd95874d67c46cf3424822f8dfd 4909 4909
79e30d460594694231f163dd79a69808904819e2f39bf3e31b7ddc4baa030a04 4625 4625
26ed04bd772c7d3d621329bda8eefec9f81108d46ef0bd3b690000465f5254b3 2976 2976
bf40393fedc45a1b347957124ef9bb8ae6a44feecee10ef2cc78064fabf8125f 4663 4663
446c0a1d563c93285e93f085192340a82c9aef7a543d41a86b65e215794845ef 4507 4507
1cf52f9ef89fa43bb4f042cbd4f80e9f090061e466cbe14c6b7ba525df0e572e 3847 3847
54bf51be42ff45cdf8217b07bb233466e18d23fd66483b12449cd9b99c3a0545 4925 4925
b5ca68205e6d55e87bd6163b28467da737227c6cbcc91cb9f6dc7b400163a12b 4027 4027
9f8cc4496cff3216608c2f2177ab360bd2d4f58cae6490d5bc23312cf30e72e0 4348 4348
4eba5deb2bbf3abf067f524484763287911e8d68fb54fa09e1287cf6cd6d1276 4617 4617
e3de81a5817a3c825cf44fbf8185e15d446393615568966a6e3fc22cba609c7d 4124 4124
1e700d8ce85b17d713cad1a8cae932d26740e7c8ab09d2201ddfe9d1acb4706c 4297 4297
b8ba939da1babf863746175b59cbfb3b967354f04db41bd13cb11da58e43d2a8 4227 4227
22df2138a28c9d339813854a38181ffc5ac6f37d171d5b5bd6b0b79bf8d3c641 2758 2758
1d93bfe18bc05b13169837b6bc868a92da3c87938531d6f3b58eee4b8822ecbf 4654 4654
e0c5e2dc3a39e733cf1bdb1a55bbcb3c2469f283becf2f99a0de771ec48f6278 4423 4423
c1e00054cc3fef88c2fdec2967e96fdb4c645bcf3f08b0580b51e47ecbfab71a 2688 2688
9a567fde7c65bf85bbc2b109277933431ebc8a35de321a4b6436601d68aa4521 2580 2580
6a9263e48a076bfc37deb93d01bf354305f4ac929be6b0ca05c078381a562c0c 2537 2537
0683fb9cfcd4a211c14ef7cd2d03739160ff9ba1cb5396be227e475e932a8e9b 2541 2541
2290263dddf8f06f099fcfb130a85f8f00b6cc1e05565a4c028d2187c8592d15 2508 2508
d27ca813c97eef5c6e9ed4bd2fe08a7e34aa8ac0c2af353826c73a4e2711a797 2704 2704
b28d67131d00bda9dac0da484dd1352c55ec6a869ea04a7e85b71d2ddf2356d9 2609 2609

We can’t expect transactions that spend many large (7 keys or more) legacy multisigs to suddenly become common. Such usage would anyways impose slightly more cost to the network than available Segwit alternatives. And even when it was the only option, there was no instance of legitimate usage that would run into the limit.

For these reasons i don’t plan to adopt the suggestion and will stick with the simpler limit. Please let me know if there is something i failed to consider appropriately.

1 Like
92

BIP 54 (Consensus Cleanup) is now active on Bitcoin Inquisition, since block 291168.

4 Likes