pull down to refresh
0 sats \ 5 replies \ @optimism 8h \ parent \ on: Thou mayest privatize Bitcoin Core bitcoin
Okay, then hardfork galore is okay and all the energy spent on pow for inferior chaintips is okay? Sounds like a great way for centralized mining to become the standard. With soft forks at least hashpower doesn't get lost.
Hey bro, nice that you accept bitcoin. Before i transfer some sats over LN, Which blockhash are you on? Ugh.
hardfork galore
...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?
reply
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