Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-29 📝 Original message:"Confirmation" isn't ...

📅 Original date posted:2021-06-29
📝 Original message:"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.

You may say users chosing the rules is "politicial". Isn't miners deciding
them for users more political? Whatever you call it, it is still how free
software works: users decide what to run.
It is extremely disappointing to see how few developers seem to ubderstand
this, or even care about users deciding or miners not deciding the rules.
How can we expect users to understand bitcoin when most developers don't
seem to understand it?

It is really sad.

On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric at voskuil.org> wrote:

>
> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke at dashjr.org> wrote:
> >
> > The only alternative to a split in the problematic scenarios are 1)
> concede
> > centralised miner control over the network,
>
> Miners control confirmation, entirely.
>
> This is the nature of bitcoin. And merchants control validation, entirely.
> Anyone can be a miner or a merchant. Neither is inherently “better” than
> the other. The largest merchants are likely a handful of exchanges, likely
> at least as centralized as miners are pooled.
>
> Splitting does not change this.
>
> > and 2) have inconsistent
> > enforcement of rules by users who don't agree on what the correct rules
> are,
>
> There are no “correct” rules. Whatever rules one enforces determine what
> network he chooses to participate in.
>
> > again leading to centralised miner control over the network.
>
> Leading to? Miners control confirmation, always. Whether that is
> centralized, just as with merchanting, is up to individuals.
>
> > In other words, in this context, accepting a split between disagreeing
> users
> > is the ONLY way Bitcoin can possibly continue as a decentralised
> currency.
>
> No, it is not. You are proposing splitting as the method of censorship
> resistance inherent to Bitcoin. Coordinating this split requires
> coordinated action. The whole point of bitcoin is coordinate that action
> based on mining (proof of work). Replacing that with a political process is
> just a reversion to political money.
>
> > Making that split as clean and well-defined as possible not only ensures
> the
> > best opportunity for both sides of the disagreement,
>
> Trivially accomplished, just change a rule. This isn’t about that. It’s
> about how one gets others to go along with the new coin, or stay with the
> old. An entirely political process, which is clearly evident from the
> campaigns around such attempts.
>
> > but also minimises the
> > risk that the split occurs at all (since the "losing" side needs to
> concede,
> > rather than passively continue the disagreement ongoing after the
> attempted
> > protocol change).
>
> Nobody “needs to” concede once a split has occurred, which is evident in
> existing splits.
>
> e
>
> > Luke
> >
> >
> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
> >> 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 <jtimon at 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.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/blo
> >>>>>>>>>> b/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/7edacdb9/attachment-0001.html>;