The main issue is that I would never run anything with a < 95% activation threshold or with LOT, because I think that that's oppressive. Yes, even at a true 55% signal, or even 80% economic nodes: democratic oppression is not only possible, but common, to varying degrees.
I've been thinking of forking both the current activation clients and re-releasing them clean [1] and integrated [2], but this is way too much work when measured in bread not put on my table when done full-time and too slow when not done full-time. Also made painful due to the lack of deep docs, tests and fuzzing harnesses, so this needs 3-4 people.
An additional upside of that, besides reducing fragmentation, would be that if both our expectations are wrong and there is massive support for either, there's a clean, tested, fuzzed patch-set for Core. Something that's very hard right now for at least BIP-110.
Traditionally, this was the "staging tree" role of Core, but when faced with controversy it is impossible to do it there, and I observe that the "reference client" role has gained much more importance, especially in the past 5 years. The Bitcoin protocol doesn't have to ossify, but Core must be extremely conservative and thus be (perceived as) a beacon of stability, at least on the consensus code. I think that I'm not the only one seeing it this way anymore.
"Standardized", i.e. without LOT, without UASF, and with 95% threshold, and (re)based on latest Core. ↩
because with all the fragmented activation clients, the biggest benefit of versionbits, concurrent activation, is gone. If I were wanting to signal lnhance but in the meantime BIP-110 activates, I have to at one point either stop signaling, or hope that without mistakes, the lnhance activation client updates to support BIP-110... this is a crap situation. ↩
I don’t think 95% activation threshold would be attempted again after it drew out the Segwit activation like that. The activation threshold for Taproot was 90%.
The main issue is that I would never run anything with a < 95% activation threshold or with LOT, because I think that that's oppressive. Yes, even at a true 55% signal, or even 80% economic nodes: democratic oppression is not only possible, but common, to varying degrees.
I've been thinking of forking both the current activation clients and re-releasing them clean [1] and integrated [2], but this is way too much work when measured in bread not put on my table when done full-time and too slow when not done full-time. Also made painful due to the lack of deep docs, tests and fuzzing harnesses, so this needs 3-4 people.
An additional upside of that, besides reducing fragmentation, would be that if both our expectations are wrong and there is massive support for either, there's a clean, tested, fuzzed patch-set for Core. Something that's very hard right now for at least BIP-110.
Traditionally, this was the "staging tree" role of Core, but when faced with controversy it is impossible to do it there, and I observe that the "reference client" role has gained much more importance, especially in the past 5 years. The Bitcoin protocol doesn't have to ossify, but Core must be extremely conservative and thus be (perceived as) a beacon of stability, at least on the consensus code. I think that I'm not the only one seeing it this way anymore.
"Standardized", i.e. without LOT, without UASF, and with 95% threshold, and (re)based on latest Core. ↩
because with all the fragmented activation clients, the biggest benefit of
versionbits, concurrent activation, is gone. If I were wanting to signallnhancebut in the meantimeBIP-110activates, I have to at one point either stop signaling, or hope that without mistakes, thelnhanceactivation client updates to supportBIP-110... this is a crap situation. ↩