Hopefully not — anyone can run their own fork or do their own fork of bitcoin core, so if the miners/maintainers start trying to arbitrarily block proposals they can be worked around without too much hassle. If you want to influence what becomes the tradition here, contributing a review, or posting patches against the upsteam branch might be a good start? Does this make the global default signet miners, or perhaps the bitcoin-inquisition maintainers the “trusted group” that we want to avoid? I think the weakest link in that loop is the first one: what if we did activate soft forks on the default signet prior to the code being merged into core? The problem with that idea is that creates a conundrum: you can’t activate a soft fork on the default signet without first merging the code into bitcoin core, you can’t merge the code into bitcoin core until it’s been fully evaluated, and the way you evaluate it is by activating it on the default signet?
The biggest challenge with soft forks and the idea of “iterating through changes” is that making improvements can create a hard fork, which then forces everyone running old software to update, which can be pretty inconvenient, especially if you don’t actually care about that change. This is partly because it can be annoying to constantly rebase consensus changes aginst bitcoin core’s master branch, but also I think it might help consensus changes be easily backported once they pass the “evaluation phase” and move into the “deployment phase”. The idea being that if you’re trying to work on “upgrading lightning to support eltoo”, you can iterate through changes needed to consensus (via bitcoin-inquisition) and client apps (cln, lnd, eclair etc), while testing them in public (on signet) and having any/all the pre-existing signet infrastructure available (faucets, explorers etc) without having to redeploy it yourself. For practical purposes, I haven’t yet merged either CTV or APO support into the bitcoin-inquisition 23.0 branch yet, and before actually mining blocks I want to make the signet miner able to automatically detect/recover if the bitcoin-inquisition node either crashes or starts producing incompatible blocks.
The problem with having a group of that nature isn’t one of effectiveness, but rather that they are then vulnerable to pressure and corruption, which isn’t desirable if we want everyone using Bitcoin to truly be peers, and often isn’t desirable for the prospective members of the group either. So that’s not something we should want people to volunteer for, nor is it a duty we should thrust on people. How do you convince enough people that a change is sufficiently beneficial to justify the risk of messing with their money? So I think that means that part of the “evaluation phase” should involve implementing real systems on top of the proposed change, so that you can demonstrate real value from the change. Without an evaluation phase that is thorough enough to convince (almost) everyone, I think deployment becomes controversial and perhaps effectively impossible (at least without some trusted leadership group). And since they’re clearly separate from any of the actions that need to be taken for actual deployment once activation is complete, they shouldn’t have any ability to unduly promote fork proposals that people aren’t fully satisfied are ready for deployment. It’s easy to say that “CTV can enable vaults” or “CTV can make opening a lightning channel non-interactive” — but it’s harder to go from saying something is possible to actually making it happen, so, at least to me, it seems reasonable to be skeptical of people claiming benefits without demonstrating they’re achievable in practice.
29. I’ve chosen to make the standard signal have 16 bits for specifying a bip number (0-65535) and 8 bits for specifying a version of that bip, which seems like it should be more than enough at least for a while. Once a soft fork is abandoned, it can either be ignored forever (and later versions of the software can not include the code to enforce it at all), or it can be replaced by a new version of the soft fork. I’m not sure what level of code quality PRs should have before being merged into bitcoin-inquisition. I’m basing bitcoin-inquisition solely off stable releases. Anyway, I wanted to post the idea publicly, both to give folks an opportunity to poke holes in the idea, or to suggest any further improvements or otherwise do any review before the CTV and APO patches get merged. I think CTV is plenty good enough, but I’m not sure about APO, particularly its test coverage.
