pull down to refresh
100 sats \ 7 replies \ @Scoresby OP 9h \ parent \ on: Thou mayest privatize Bitcoin Core bitcoin
Do you think having a single dominant implementation is the main reason there haven't been more forks (soft or hard) of Bitcoin?
In a way, it's surprising that there hasn't been a somewhat popular spin off of Bitcoin in such a long while. I wonder how much of protocol stability is simply burn-out from the ICO era and altcoins in general. Or perhaps it is Bitcoin success? Any fork is going to be immediately compared to BTC and if it doesn't quickly garner massive adoption, it's a failure.
I suppose these are slightly different questions that what you pose. A fork claiming to continue BTC is not the same as a fork claiming to be something else.
Do you think having a single dominant implementation is the main reason there haven't been more forks (soft or hard) of Bitcoin?
I think that having a reference implementation for the consensus protocol is super important, and for the p2p protocol in lieu of formal spec too.
For the peripheral functionality, from mempool policy (
knots) to block template logic (custom pool nodes) to how all this is stored on disk (libbitcoin) it is good to have a reference client, to show other devs how it's done, but since these things aren't touching consensus, it's not something that should be literally copied. Every implementation has leeway in this.It being the reference client doesn't have to mean it is the dominant implementation in the wild, but it is, so because of this, my answer to your question would be yes, it prevents forks and creates stability.
However, if a majority of maintainers of alternative implementations of the peripheral functions would simply agree that bitcoin/bitcoin is the absolute truth (= reference client) in case of a consensus bug in another implementation, then it doesn't have to be the dominant implementation in the wild. I think the absolute truth part is the case nowadays, iirc Niklas Goegge has done important work on this for both
btcd and libbitcoin, and the solution has always been that Bitcoin Core, even when behavior is a bug, is the truth.What I think we're seeing now is that the peripheral functionality and specifically the choices made by the maintainers of the staging tree are becoming a barrier to the - imho - essential function it serves for graceful integration of consensus (and baseline p2p) functionality. I don't agree that it should be like that, but all sides in this chose escalation. And now we see an even worse, and more escalating, proposal.
I cannot comment on spin-offs, that's just nonsense anyway.
reply
Bitcoin Core, even when behavior is a bug, is the truth.
isn't this the interesting weirdness about Bitcoin? I have a feeling many things touch consensus in unexpected ways. somewhat like removing the checkpoints from Core actually could trigger a fork (it's just really unlikely).
our current situation is that the reference implementation for consensus is still kinda wrapped up with relay policy and the wallet. while i realize work is being done to separate the two, I don't agree with the match Core bug-for-bug approach.
Do I go so far as to say the chain is the reference implementation? Maybe. If you can start with the beginning and sync to the most recent tip, seems like what happens next is up for grabs a little bit. Negotiating consensus in one repo does not seem objectively better than negotiating it in the next block.
Anyway, consensus is such a tricky little bitch.
reply
I don't agree with the match Core bug-for-bug approach.
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.
Do I go so far as to say the chain is the reference implementation?
Hey bro, nice that you accept bitcoin. Before i transfer some sats over LN, Which blockhash are you on? Ugh.
reply
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.