I think the option of "permanent failure because miners veto" should actually be abandoned. No, I don't think we should avoid splits when possible, I don't think we should avoid splits at all costs. On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote: > @Luke > > They can still slow it down. > > Absolutely. However I think that the option of permanent failure is > important. It certainly would be ideal to ensure that enough bitcoin users > support the upgrade *before* releasing it, however realistically this can > never be more than an estimate, and estimates can sometimes be wildly > wrong. It would be unfortunate if miners had a substantially different > estimate of user support than the people putting in the work to release > bitcoin upgrades. Even if upgrades are never released before it becomes > clear that a large supermajority of users want the upgrade, if miners don't > agree with the estimate a harmful chain split could occur. And I agree with > Eric that the goal here is to prevent a chain split during an upgrade when > possible. This includes permanent failure of an upgrade when there is > unexpectedly large miner opposition. > > This of course does not prevent a UASF-style deployment to be done after > an initial failure to deploy occurs. My proposal is essentially a mechanism > to improve upon the speedy-trial idea, allowing for even speedier releases > (than speedy trial) without adding additional risk of undesired chain > splits. > > > [BIP8] already has the trinary state you seem to be describing > > It sounds like you're saying the trinary state of BIP8 is A. Follow the > longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded > chain. I agree. However the trinary state in my proposal is materially > different - it is the signaling itself that is trinary, not just which > chain is being followed. This allows others to know and make programmatic > decisions (in software) based on that signaling. I'm sure you can agree > that does not exist in BIP8. > > > No additional bit is needed, as softforks are coordinated between users, > NOT miners > > And yet there is miner involvement, as you rightly pointed out. Miners are > needed to set the nVersion in the header. So when you say "no additional > bit is needed", could you please be clearer as to what you mean? Do you > mean that signaling of opposition in a block can be done without any > "additional bit"? Or are you just saying that it is redundant to consider > what miners might be opposing an upgrade? > > @Jorge > > If different users want different incompatible things... there's no way > to avoid the split > > I agree. This happened with bcash, and that's fine. It was painful, but > there were a significant amount of users that disagreed, and they have the > chain they want now. > > But we generally all want to avoid a chain split when possible. Because > chain splits have a cost, and that cost can be high, its likely that many > users would rather choose the chain with the most support rather than > choosing the chain with their preferred rules. > > However, the question here is: how do we estimate what fraction of users > wants which rules? We don't have a divining rod to determine with certainty > what users want. We can only make polls of various levels of inaccuracy. > The methods bitcoin has been using is community discussion and social > consensus estimation as well as miner signaling during the actual > deployment period. Neither of these are perfect, but they are both > reasonable enough mechanisms. However, because both of these mechanisms are > very rough estimates of user sentiment, we need to consider the possibility > that sometimes the estimate may be substantially inaccurate when we design > deployment procedures. This inaccuracy is why we need multiple barriers in > place for an upgrade, and why we need to have higher thresholds of success > (require larger supermajorities in both consensus and miner signaling). > > Developers obviously care about bitcoin and have an incentive (personal > and probably financial) to do it right. And miners have both an incentive > to keep the system healthy, as well as an incentive to mine on the chain > that the economic majority of users is using. But measuring the consensus > of the bitcoin community can be extraordinarily difficult to do with > consistent accuracy, and so I think miner signaling as it has been used as > a second barrier to entry for an upgrade is quite appropriate. > > On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil wrote: > >> I have not objected to anyone splitting. As I said, a split is always >> possible, and of course has been done on a large scale. It is only the >> misleading statements about inherent soft fork “compatibility” and the >> implication that activation without hash power enforcement does not create >> a split that I object to. People who know better should be honest about it. >> >> Far too many people have been led to believe there is some sort of >> activation choice with “ensured” equal outcomes (maybe “slowed down”). >> There is only a choice between creating a split and hash power enforcement. >> Soft forks are rule changes, and thereby incompatible - unless enforced by >> majority hash power. >> >> The statements below are grossly misleading and need to be called out as >> such so that people can actually make this decision you speak of. This idea >> that “users” decide the rules is not the question. The question is only how >> to avoid a split. If one does not care he can split at any time, no >> discussion required. >> >> e >> >> > On Jun 27, 2021, at 01:47, Jorge Timón wrote: >> > >> > 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 >> >> 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 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 < >> 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 >> >