If different users want different incompatible things (enough on each side), there's no way to avoid the split. We shouldn't try to avoid such a split. Users decide the rules, not miners nor developers.
On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev <[email protected]> wrote: > > Ultimately there is only one answer to this question. Get majority hash power > support. > > Soft fork enforcement is the same act as any other censorship enforcement, > the difference is only a question of what people want. Given that there is no > collective “we”, those wants differ. Bitcoin resolves this question of > conflicting wants, but it is not a democracy, it’s a market. One votes by > trading. > > If one wants to enforce a soft fork (or otherwise censor) this is > accomplished by mining (or paying others to do so). Anyone can mine, so > everyone gets a say. Mining is trading capital now for more later. If enough > people want to do that, they can enforce a soft fork. It’s time Bitcoiners > stop thinking of miners as other people. Anyone can mine, and that’s your > vote. > > Otherwise, as mentioned below, anyone can start a new coin. But it’s > dishonest to imply that one can do this and all others will surely follow. > This cannot be known, it’s merely a gamble. And it’s one that has been shown > to not always pay off. > > e > > > On Jun 26, 2021, at 14:43, Eric Voskuil <[email protected]> wrote: > > > > For some definitions of “block”. > > > > Without majority hash power support, activation simply means you are off on > > a chain split. Anyone can of course split off from a chain by changing a > > rule (soft or otherwise) at any time, so this is a bit of an empty claim. > > > > Nobody can stop a person from splitting. The relevant question is how to > > *prevent* a split. And activation without majority hash power certainly > > does not “ensure” this. > > > > e > > > >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev > >> <[email protected]> wrote: > >> > >> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They > >> can > >> still slow it down. > >> > >> It also already has the trinary state you seem to be describing (although > >> perhaps this could be better documented in the BIP): users who oppose the > >> softfork can and should treat the successful signal (whether MASF or UASF) > >> as > >> invalid, thereby ensuring they do not follow a chain with the rules in > >> force. > >> > >> No additional bit is needed, as softforks are coordinated between users, > >> NOT > >> miners (who have no particular say in them, aside from their role as also > >> being users). The miner involvement is only out of necessity (to set the > >> bit > >> in the header, which users coordinate with) and potentially to accelerate > >> activation by protecting upgrade-lagging users. > >> > >> Luke > >> > >> > >>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote: > >>> Given the recent controversy over upgrade mechanisms for the > >>> non-controversial taproot upgrade, I have been thinking about ways to > >>> solve > >>> the problems that both sides brought up. In short, BIP8 LOT=true > >>> proponents > >>> make the point that lazy miners failing to upgrade in a timely manner slow > >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false > >>> proponents make the point that LOT=true can lead to undesirable forks that > >>> might cause a lot of chaos. I believe both points are essentially correct > >>> and have created a proposal > >>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b > >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both > >>> problems. > >>> > >>> The proposal uses trinary version signaling rather than binary signaling. > >>> For any particular prospective soft fork upgrade, this allows for three > >>> signaling states: > >>> > >>> * Actively support the change. > >>> * Actively oppose the change. > >>> * Not signaling (neither support or oppose). This is the default state. > >>> > >>> Using this additional information, we can release non-contentious upgrades > >>> much quicker (with a much lower percent of miners signaling support). For > >>> contentious upgrades, miners who oppose the change are incentivized to > >>> update their software to a version that can actively signal opposition to > >>> the change. The more opposition there is, the higher the threshold > >>> necessary to lock in the upgrade. With the parameters I currently > >>> recommended in the proposal, this chart shows how much support signaling > >>> would be necessary given a particular amount of active opposition > >>> signaling: > >>> > >>> [image: thresholdChart.png] > >>> If literally no one signals opposition, a 60% threshold should be > >>> relatively safe because it is a supermajority amount that is unlikely to > >>> change significantly very quickly (ie if 60% of miners support the change > >>> today, its unlikely that less than a majority of miners would support the > >>> change a year or two from now), and if no one is signaling opposition, > >>> chances are that the vast majority of the other 40% would also eventually > >>> signal support. > >>> > >>> This both gives an incentive for "lazy" miners to upgrade if they actually > >>> oppose the change while at the same time allowing these lazy miners to > >>> remain lazy without slowing down the soft fork activation much. > >>> > >>> I think now is the right time to discuss new soft fork upgrade mechanisms, > >>> when there are no pressing soft fork upgrades ready to deploy. Waiting > >>> until we need to deploy a soft fork to discuss this will only delay things > >>> and cause contention again like it did with taproot. > >>> > >>> I'm very curious to know what people think of this mechanism. I would > >>> appreciate any comments here, or written as github issues on the proposal > >>> repo itself. > >>> > >>> Thanks, > >>> BT > >> > >> _______________________________________________ > >> bitcoin-dev mailing list > >> [email protected] > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
