Author: Anthony Towns 2022-10-03 22:54:04
Published on: 2022-10-03T22:54:04+00:00
The email thread focuses on the pressure to merge unfinished and buggy soft fork proposals on the default signet, which can cause disruption to all users. The author argues that it is better for signet miners to face this pressure than mainnet miners or maintainers/devs of Bitcoin Core. They suggest that APO and CTV are not being kept out of core due to being unfinished or buggy, but because it is unclear if they are desirable to deploy on mainnet. The article proposes that getting these ideas out on signet would be helpful in finding and fixing bugs. Three potential ways of mitigating the risk of a bug interfering with testing another soft fork include finding bugs during review, quickly noticing such bugs, and using the -renounce feature of bitcoin-inquisition to temporarily disable enforcing a buggy soft fork.The ideal result from a soft fork proposal evaluation would be explicit proposals with corresponding changes to the code, performance impact on validators/miners, alternative ideas, and real, functioning examples of useful, new/improved applications that can be built with this feature. An "A+" answer to all of these criteria would cause the proposal to be deployed on the mainnet. A "B" answer, where applications using the feature exist, but don't seem very interesting or valuable, would require going back and coming up with a better proposal that enables more useful results. Having the outcome of an evaluation be an "F" for fail is also useful, as it allows R&D effort to be spent on useful things instead of spending more R&D effort on a dead-end.The article concludes by saying that there is a threshold where a proposed soft fork would be too much effort to add to inquisition, but it is not clear where that threshold lies. The length of time for a proposal should look more like: presenting an awesome idea, implementing it and deploying it on signet, showing the applications people have built using the idea, resolving issues, exploring risks, and minimizing them, and exploring alternatives. Whether something gets deployed on mainnet is more a question of whether the apps are valuable, risks have been thoroughly explored and minimized, and alternatives have been explored. If the answer to some/all of those is still "no," then having had a long time for that work to happen may be more of a negative than a positive. The author suggests that multiple devs and researchers reviewing PRs in the inquisition repo would be ideal.
Updated on: 2023-05-22T21:19:15.161329+00:00