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.
btcd
, andlibbitcoin
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.Bitcoin Is For Enemies
, then protocol enhancements need to be hashed out together with your enemies, and that's why we needbitcoin/bitcoin
, or a replacement true open forum, if this one keeps being moderated / goes private.