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
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
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
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
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
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
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.
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.