Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-29 📝 Original message:I think the option of ...

📅 Original date posted:2021-06-29
📝 Original message: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.tetrud at 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 <eric at 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 <jtimon at 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 at 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 <eric at 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 at 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 at lists.linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210629/ada3537e/attachment-0001.html>;