pull down to refresh
100 sats \ 1 reply \ @Scoresby OP 29 Jun \ parent \ on: Thou mayest privatize Bitcoin Core bitcoin
This was a very helpful explanation! Thank you. I hadn't read BIP-50, and I spent some time on it yesterday. It was indeed something like the scenario I was imagining: a new release has an unknown quality that it validates blocks that old releases can not.
I'm very interested in how Bitcoiners handle such situations, especially in the case where the fork is not caused by an obvious misconfiguration in a database, but rather by a minor difference in some library or dependency. But even in the BIP-50 situation, I wonder what would happen in such a case now -- would miners who found blocks on the new fork be willing to forgo their revenue?
In the case of a reference implementation forking with past versions of itself, having a number of alternate implementations of node software might be useful in that they could lend some objectivity to arguments about which chain is the "true" chain.
Whatever the case, I really do appreciate the time you've taken in your responses here. I've certainly learned a lot.
Of course. Thanks for reading my responses and more importantly, those examples. It makes it worth spending the time.
a new release has an unknown quality that it validates blocks that old releases can not. [..] In the case of a reference implementation forking with past versions of itself, having a number of alternate implementations of node software might be useful in that they could lend some objectivity to arguments about which chain is the "true" chain.
Maybe! Though the best test thus far has been "previous versions of core", I think that in the case of full re-implementations, mostly
btcd, and libbitcoin to some extent, there can be some added safety if these are properly audited themselves, which is why I mentioned Niklas' work somewhere along the way above: comparing apples with rotten apples is pointless.However, I think that it's problematic to confuse my initial point about having a space to hash out direction on softforks (=intentionally validating blocks differently) with developer error that happened twice post-satoshi, and one of these never even materialized. Because the point about having well orchestrated softforks is to prevent developer error and not take unnecessary risks.
Decentralized consensus (and trustlessness) doesn't mean that everyone is each other's enemy. That's imho the bad assertion that many maxis and also critics make. The point of it is that you don't have to worry (much) about counterfeit sats or reversals under standard, well defined practices, but you're not able to operate solo. You're an island (if you want) in a global network of interconnected islands. Connected through consensus and p2p networking. You don't have to like each island's person or their choices, but still everyone has to agree on the protocol. Creating chaos in the definition of what "the truth is" will destabilize this consensus and connectedness, no matter what. And that's when hardforks happen. We know this, because it happened as I outlined above.
If the bitcoin protocol were static and fully ossified, then you are right. But it isn't, and if future you wants to use LN as safely as you can use L1 today, then you need some protocol enhancements, and if there is any chance of the quantum threat materializing, you need an enhancement for that too. And the point that I really, really want to drive home is that unfortunately, if
Bitcoin Is For Enemies, then protocol enhancements need to be hashed out together with your enemies, and that's why we need bitcoin/bitcoin, or a replacement true open forum, if this one keeps being moderated / goes private.Need to find people to recruit into team de-escalation.
reply