At least we are now acknowledging that splitting is what it’s about. That’s progress.
e > On Jun 29, 2021, at 01:32, Jorge Timón <jti...@jtimon.cc> wrote: > > > 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 <billy.tet...@gmail.com> 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 <e...@voskuil.org> 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 <jti...@jtimon.cc> 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 >>> >> <bitcoin-dev@lists.linuxfoundation.org> 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 <e...@voskuil.org> 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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
