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 > <bitcoin-dev@lists.linuxfoundation.org> 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
