Soft fork activation code should never be in Bitcoin Core. If you want a soft fork, fork Bitcoin Core and put your soft fork code in it and get people to run it. Don't rely on Bitcoin Core to merge it. People automatically update Bitcoin Core for many reasons (bug fixes, security, optimizations, wallet features, etc) so it should never be used to activate contentious policies. Bitcoin Core devs should never put their users in a position to choose between missing out on Bitcoin Core improvements and activating a fork.
related posts
47 sats \ 4 replies \ @Rock 11 Apr
We need some way where a large portion or a majority of nodes/consensus participants can organize and essentially vote on soft forks, or easily start running the forks.
Polls on different platforms seem like a decent idea, but then there's issue of actually pulling the code to your node and running it.
Maybe it would be helpful if the community could somehow agree on scheduling votes or something like that, not sure.
Not super familiar with the entire process of "speedy trial" and other such soft-fork methods, so maybe those things are already kind of being handled in some way.
I feel like the soft fork process really needs better public understanding of how to participate and what mechanisms they can actually use to vote. I definitely need to go and do my own research...
reply
1 sat \ 0 replies \ @nerd2ninja 11 Apr
I think you would be interested in this proposal: https://delvingbitcoin.org/t/economic-majority-signaling-for-op-ctv-activation/635
I myself am starting to think about putting "LNHance good" in my services field or something so when people look in their peers list they can see what their fellow node runners think.
reply
1 sat \ 2 replies \ @Scoresby OP 11 Apr
There is the feeling of "rough consensus" and the idea that it's harder to game or control a thing when there is no clear process. And both those things are good.
So I don't think there needs to be an "official soft fork process."
There does seem to be a feeling, at least among Bitcoin core contributes who make statements about it, that they don't want to be deciding which forks to pursue.
Francis's tweet got some interesting responses. It's worth poking around the thread on twitter.
reply
17 sats \ 1 reply \ @Rock 11 Apr
totally agree that there doesn't need to be a single approach to soft forks, as seen with segwit and taproot using different mechanisms.
I guess what I'm getting at is that many plebs who run their own nodes don't know how to make their opinion heard in the consensus process. All I see is a cacophony of opinions online, but no sense of how popular any proposal actually is. If there was a way to gauge people's opinions of BIPs through highly visible polls I think that would be a good thing.
reply
1 sat \ 0 replies \ @Scoresby OP 11 Apr
Good point. At the moment, it does feel like you have to wait for someone to produce a patch that you can run. If there isn't one, it doesn't seem like you can do much beyond adding to the cacophony.
reply
102 sats \ 1 reply \ @tomlaies 11 Apr
Unpopular opinion but this is another consequence of having only one major implementation. But it's not too late to change that.
Luckily we made a better decision when implementing Lightning specifications.
reply
0 sats \ 0 replies \ @Scoresby OP 11 Apr
I am very sympathetic to the multiple implementations argument.
But I also am a big fan of how many eyeballs are focused on core. The odds that core ships some horrible thing AND it gets widely adopted without someone noticing are low.
I wonder how we get another implementation up to roughly equal review. Knots and libbitcoin have been around for a long while and are still one or two person projects.
Perhaps one of them becoming the vehicle for championing a soft fork would be a shortcut to dramatically ramping up their developer base.
reply
1 sat \ 0 replies \ @Coinsreporter 11 Apr
Yes, it's correct not to have it in Bitcoin core.
Let the people do the people's thing.
reply