pull down to refresh
100 sats \ 5 replies \ @Scoresby OP 8h \ parent \ on: Thou mayest privatize Bitcoin Core bitcoin
...is a claim and I'm curious what evidence you have to support it? There was the btcd issue, but I'm not aware of too many other instanceswhere alt implementations have led to forks.
Running past versions of Bitcoin Core is similar to running an alt implementation (certainly there have been new versions of core that introduced potentially forking changes). Why haven't we seen more forks from miners running old versions of Core?
Fair questions! Assumed you knew, apologies.
I'm curious what evidence you have to support it?
Cases of past forks, because we've been here:
- BIP-50 which was bitcoin/bitcoin with itself, a perfect demonstration of how fragile consensus is, and why I think that "even the bugs of the ref client are leading".
- Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited, each as an alt client that ran its own softforks (and later turned into BCH)
Why haven't we seen more forks from miners running old versions of Core?
This is exactly because of very well defined, agreed upon and executed soft fork implementations allowing for full forward compatibility for old clients. (Though arguably the introduction of OP_NOP itself was a hard fork.)
Don't underestimate the engineering that this has required, especially for segwit. It is because of developer consensus, and an open repository and mailing list, and not settling for inferior solutions, that Bitcoin is as reliable as it is.
But this is also why I said " if you're willing to support that chaos", because I'm just advising against it. Mostly due to historical precedent of what happens when polarisation is driven to the point of people building forking clients out of frustration. And because I think that if you're burned out, you shouldn't make decisions.
reply
Don't underestimate the engineering that this has required, especially for segwit. It is because of developer consensus, and an open repository and mailing list, and not settling for inferior solutions, that Bitcoin is as reliable as it is.
Sending bitcoin around and zapping stackers here, it's easy to underestimate. great point! I think I often take it for granted.
I guess I'm nervous of a Bitcoin culture that says "consensus is the most important thing" -- not that I think you hold this position -- but "matching Core bug for bug" does venture down the path, I think.
Seeing how things are going with ETFs and treasury companies and custodians, it seems like a real possibility that development will continue to be funded by these large stakeholders and their priorities might not be censorship resistance. Do you worry that keeping all work on consensus in one repository makes it more vulnerable to strong nudges from such stakeholders?
Having multiple viable, well-maintained implementations, each with their own means of reaching consensus with the rest of the nodes following the BTC blockchain, seems like a stronger position to withstand such pressures.
reply
I guess I'm nervous of a Bitcoin culture that says "consensus is the most important thing"
If you mean the
consensus protocol (i.e. what constitutes a valid block) then it absolutely is the most important thing. Without it, there is no chain. That's just the technical constraint of Bitcoin.If you mean developer (pre-)consensus:
- If this is purely about
consensus protocolcode (=softforks), then that's probably not going to happen, but having rough consensus between stakeholders 1 is important when doing core protocol changes. Super-short lazy version: all issues must be addressed, but not all issues must necessarily be accommodated, and at the same time, rough consensus isn't a democracy: votes are meaningless, feedback is priceless. Also: 2 - If your point also includes what I mentioned above as
peripheral functionality. i.e. everything that influences your node and/or your peers, but not the overall consensus protocol (and preferably not the p2p messaging protocol itself) then of course there is no consensus needed other than between maintainers of the repo in question, though it would still be good to listen to and address concerns, especially if said repo serves a large part of the network.
-- not that I think you hold this position -- but "matching Core bug for bug" does venture down the path, I think.
Something has to be the truth. If two implementations do not agree on what is valid (
consensus, lol) then it has to be fixed or they will be permanently hardforked away from each other. This is only limited to consensus protocol and p2p messaging protocol, imho.Seeing how things are going with ETFs and treasury companies and custodians, it seems like a real possibility that development will continue to be funded by these large stakeholders and their priorities might not be censorship resistance.
What do you mean continue to be funded? Wasn't the complaint that Saylor isn't funding anything at all? Neither is Blackrock or Conbase, afaik?
Do you worry that keeping all work on consensus in one repository makes it more vulnerable to strong nudges from such stakeholders?
I don't think that this is true, but if it were, it would be worrying, yes. This is why I gave some pushback to Murch the other day re: banning people, and why making
bitcoin/bitcoin a private repo in all but visibility is imho the worst possible outcome, and yes, this is also worrying without bankers and scammers funding maintainers!Having multiple viable, well-maintained implementations, each with their own means of reaching consensus with the rest of the nodes following the BTC blockchain, seems like a stronger position to withstand such pressures.
That's what the 3 clients I mentioned above thought, and later with BCH where this was policy, Bitcoin ABC just hardforked off to create yet another shitcoin in which they then milked the entire market cap into developer salary. Collaboration is important. It can be decentralized, but imagine that every proposal in https://en.bitcoin.it/wiki/Covenants_support would have been a separate client that all needs to be updated while the years of non-activation pass. I count 6 implementations at least. That's 6x the maintenance work. For things that probably never even get lock-in, let alone 95% activation.
Footnotes
-
See as an example the mails in this thread because it shows you how some of the maintainers think about softforks, developer consensus and listening to the community. ↩
reply
If you mean the consensus protocol (i.e. what constitutes a valid block) then it absolutely is the most important thing.
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.
reply
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