pull down to refresh
200 sats \ 1 reply \ @Scoresby OP 6h \ parent \ on: Thou mayest privatize Bitcoin Core bitcoin
I'm thinking of "matching bug for bug" consensus: say there was a bug in Core 26, which I am running. And a certain kind of transaction gets treated by 26 as invalid, even though all the other versions call it valid.
Now if a block with this tx gets mined, all the nodes running 26 will get stuck at the previous tip.
Okay, so clearly 26 nodes aren't running the same consensus rules as bitcoin, and if somebody starts mining on the 26 nodes' stuck chaintip, the rest of the network would say it isn't consensus.
But what if this happened when 26 was the most recent version. Say most miners had upgraded, but some had not, and were still running 25. Now the problem block gets mined and we have a fork. Which chain is BTC?
(I have a feeling my analogy here is fairly naive: surely miners are running multiple versions)
Another example might be if the bug exists, but no transaction gets proposed that triggers it. During the timeframe where 26 is running buggy rules and 25 is running non-buggy consensus rules, what are the consensus rules?
I appreciate your thoughtful response, though, especially for the link to the thread in your footnote. I hadn't read that before.
I'm not sure if I understand the hypotheticals fully - it doesn't all make sense from how coding, bugs and release management works from where I'm sitting, - but I'll try:
Now if a block with this tx gets mined, all the nodes running 26 will get stuck at the previous tip.
You mean a bug was introduced in 26 and fixed in 27 but no security patch was released for 26? I don't think that this ever happened on an actively maintained version of Bitcoin Core. This hypothetical would be the gravest of errors on whomever manages the release process but at the same time easily fixable: release the damn security patch.
Or if you mean that you didn't install the security update and/or refuse to install it, then this is 100% on you and you should really rethink if Bitcoin is for you, because you're a sovereign operator. Being your own bank isn't rocket science, but it's not something you can just fire and forget.
But what if this happened when 26 was the most recent version ...
If a consensus bug on a new version materializes then the new version should be pulled, read BIP-50 that I mentioned earlier, because that's a post-mortem of when this exact scenario happened.
... Which chain is BTC?
The above is iirc the one and only time this happened... per that precedent it would be 25.
Another example might be if the bug exists, but no transaction gets proposed that triggers it. During the timeframe where 26 is running buggy rules and 25 is running non-buggy consensus rules, what are the consensus rules?
If a consensus bug gets introduced (like with
0.14) and caught before it gets exploited, then it's an unmaterialized hard fork that gets patched- like was done in 0.14.1.When I say "bug". I don't mean someone screwing around with consensus code - even though that has happened and this has put everyone on high alert for issues like this, because it was found post-release only.
It's more like: if you want to validate the chain and have consensus with the network, you have to implement - among other quirky things - the vulnerable merkle tree implementation that Bitcoin Core has used since v0.1. You cannot implement a safe version of this, because you will not be able to sync up with the rest of the network.
- Where is this defined? In Bitcoin Core.
- Why? Because it is has been reference client since 2009.
- Is there any bad faith there? Not at all.
- Can it be fixed? Matt Corallo wanted to fix many of the quirky things in consensus up since 2019 1. But even that won't fix all the things, because there isn't a clean soft-forkable solution for everything.
Footnotes
-
See The Great Consensus Cleanup draft BIP for the original, which got recently proposed to be revived by Antoine Poinsot ↩
reply