Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

It feels like this discussion has gotten a bit off topic. The proposal is
intended to provide a best-of-both-worlds middleground between BIP8 and
BIP9. It would be nice if we could bring it back to a discussion of my
proposal in the context of other existing deployment plans (BIP8, BIP9,
taproot's hybrid deployment, even flag days).

The main relevant actually to my proposal that have been mentioned, as far
as I can tell, is that Luke opined that explicit signaling of opposition
was unnecessary, because he thinks we shouldn't try to avoid chain splits
when there's any opposition. Jorge agreed that we shouldn't try to avoid
chain splits. But I don't really understand what either of you (Luke or
Jorge) are actually proposing is better than using my proposal. Are you
proposing LOT=true be added as an option to my proposal? Are you proposing
that we should always use a LOT=true style flag day, and not even consider
the option of permanent failure for a deployment? Or are you simply saying
that miner opposition is never relevant or useful to know during a
deployment?

Everything else has been only tenuously related:

* Who "controls" or "defines" bitcoin"?
* Who "controls" what happens during a deployment?
* Should we deploy based on miner signaling at all?

If there's so much to discuss on these philosophical points, maybe it makes
sense to branch that off into a separate thread. I'd appreciate it if we
can reconnect this discussion with the proposal this thread is about.



On Wed, Jun 30, 2021 at 12:30 PM Billy Tetrud 
wrote:

> @Jorge
> > I disagree...  I would oppose such a change no matter what other users
> or miners say.
>
> I don't know why you think we disagree on that point. I agree that I would
> oppose a change to 1GB blocks no matter what other users or miners say. You
> must have misunderstood me there.
>
> >>  Are you really saying that we should just hard fork every time
> instead of soft fork?
> > No
>
> So what are you advocating for then, exactly?
>
> >> Are you not at all worried about the costs associated with an
> increased orphan rate and reorg rate?
> > Orphan blocks are bad, yes, not sure what the point of your question is.
>
> The point is that if we just deployed with BIP8 LOT=true (as that seems to
> be the kind of thing you're advocating for) and only 60% of miners had
> upgraded to the new update by the time it activates, orphans and reorg rate
> and depths would greatly increase. The point of the question is: shouldn't
> we avoid that "when possible"?
>
> > What do you think of bip99?
>
> I haven't read it before, but after reading it, it seems like a reasonable
> discussion of possibilities and types of forks. It looks like you advocated
> that "miner voting" is appropriate for some of the types of forks. And yet,
> from the way you're talking in this thread, it sounds like you don't think
> any consensus rule change deployment should consider miner signaling. So
> I'm confused because it seems like the things you're saying here conflict
> with some of the things you wrote in BIP99.
>
> What specifically did you want me to get out of BIP99 in this context?
>
> @Eric
> > I’d also question the use of the term “majority”
>
> I just want to clarify that by "economic majority" I mean a set of users
> that presently accept more than 50% of the volume of payments in a given
> period of time. I definitely agree that no majority of any kind is needed
> for a split.
>
>
> On Wed, Jun 30, 2021 at 2:52 AM  wrote:
>
>> > From: Jorge Timón 
>>
>> >> "Soft forks aren’t compatible without miner enforcement"
>> > Compatible with what?
>>
>> There is a good summary of what is meant by this term in BIP141:
>> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
>>
>> "Backward compatibility
>> As a soft fork, older software will continue to operate without
>> modification. Non-upgraded nodes, however, will not see nor validate the
>> witness data and will consider all witness programs as anyone-can-spend
>> scripts (except a few edge cases where the witness programs are equal to 0,
>> which the script must fail). Wallets should always be wary of
>> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes
>> are strongly encouraged to upgrade in order to take advantage of the new
>> features."
>>
>> The explanation is however incomplete. If majority hash power does not
>> enforce the new rules, the above is incorrect. Granted the word "operate"
>> is vague, but clearly what is intended is that "non-upgraded" nodes will
>> not be on a different coin. But in fact they would be. The underlying
>> presumption is that BIP141 is not only signaled, but enforced by majority
>> hash power.
>>
>> >> "Soft forks without miner support cause splits".
>> > No, what causes splits are 3 things:
>> >
>> > 1) bugs
>> > 2) coordination mistakes
>> > 3) people wanting different rules.
>>
>> #3 (and possibly #4) is what we're talking about, so it's not at all
>> clear why you said "no".
>>

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

@Jorge
> I disagree...  I would oppose such a change no matter what other users or
miners say.

I don't know why you think we disagree on that point. I agree that I would
oppose a change to 1GB blocks no matter what other users or miners say. You
must have misunderstood me there.

>>  Are you really saying that we should just hard fork every time instead
of soft fork?
> No

So what are you advocating for then, exactly?

>> Are you not at all worried about the costs associated with an increased
orphan rate and reorg rate?
> Orphan blocks are bad, yes, not sure what the point of your question is.

The point is that if we just deployed with BIP8 LOT=true (as that seems to
be the kind of thing you're advocating for) and only 60% of miners had
upgraded to the new update by the time it activates, orphans and reorg rate
and depths would greatly increase. The point of the question is: shouldn't
we avoid that "when possible"?

> What do you think of bip99?

I haven't read it before, but after reading it, it seems like a reasonable
discussion of possibilities and types of forks. It looks like you advocated
that "miner voting" is appropriate for some of the types of forks. And yet,
from the way you're talking in this thread, it sounds like you don't think
any consensus rule change deployment should consider miner signaling. So
I'm confused because it seems like the things you're saying here conflict
with some of the things you wrote in BIP99.

What specifically did you want me to get out of BIP99 in this context?

@Eric
> I’d also question the use of the term “majority”

I just want to clarify that by "economic majority" I mean a set of users
that presently accept more than 50% of the volume of payments in a given
period of time. I definitely agree that no majority of any kind is needed
for a split.


On Wed, Jun 30, 2021 at 2:52 AM  wrote:

> > From: Jorge Timón 
>
> >> "Soft forks aren’t compatible without miner enforcement"
> > Compatible with what?
>
> There is a good summary of what is meant by this term in BIP141:
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
>
> "Backward compatibility
> As a soft fork, older software will continue to operate without
> modification. Non-upgraded nodes, however, will not see nor validate the
> witness data and will consider all witness programs as anyone-can-spend
> scripts (except a few edge cases where the witness programs are equal to 0,
> which the script must fail). Wallets should always be wary of
> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes
> are strongly encouraged to upgrade in order to take advantage of the new
> features."
>
> The explanation is however incomplete. If majority hash power does not
> enforce the new rules, the above is incorrect. Granted the word "operate"
> is vague, but clearly what is intended is that "non-upgraded" nodes will
> not be on a different coin. But in fact they would be. The underlying
> presumption is that BIP141 is not only signaled, but enforced by majority
> hash power.
>
> >> "Soft forks without miner support cause splits".
> > No, what causes splits are 3 things:
> >
> > 1) bugs
> > 2) coordination mistakes
> > 3) people wanting different rules.
>
> #3 (and possibly #4) is what we're talking about, so it's not at all clear
> why you said "no".
>
> People change their rules, because #3. If majority hash power does not
> enforce this (soft) change, it's a chain split.
>
> > Let me give an example. Let's say all users want change A.
> >
> > Only 60% miners want it.
> > When it activates with LOT=true, will this cause a split?
>
> No, regardless of percentage adoption. You've proposed that it' is
> majority hash power enforced.
>
> Furthermore, the term compatibility (see above) implies that not everyone
> (your impossible presumption of 100%) is aligned.
>
> This is not a debatable subject as far as I'm concerned, but it's worth
> discussion for those who aren't familiar.
>
> e
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

> From: Jorge Timón  

>> "Soft forks aren’t compatible without miner enforcement"
> Compatible with what?

There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

"Backward compatibility
As a soft fork, older software will continue to operate without modification. 
Non-upgraded nodes, however, will not see nor validate the witness data and 
will consider all witness programs as anyone-can-spend scripts (except a few 
edge cases where the witness programs are equal to 0, which the script must 
fail). Wallets should always be wary of anyone-can-spend scripts and treat them 
with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order 
to take advantage of the new features."

The explanation is however incomplete. If majority hash power does not enforce 
the new rules, the above is incorrect. Granted the word "operate" is vague, but 
clearly what is intended is that "non-upgraded" nodes will not be on a 
different coin. But in fact they would be. The underlying presumption is that 
BIP141 is not only signaled, but enforced by majority hash power.

>> "Soft forks without miner support cause splits".
> No, what causes splits are 3 things:
>
> 1) bugs
> 2) coordination mistakes
> 3) people wanting different rules.

#3 (and possibly #4) is what we're talking about, so it's not at all clear why 
you said "no".

People change their rules, because #3. If majority hash power does not enforce 
this (soft) change, it's a chain split.

> Let me give an example. Let's say all users want change A.
>
> Only 60% miners want it.
> When it activates with LOT=true, will this cause a split?

No, regardless of percentage adoption. You've proposed that it' is majority 
hash power enforced.

Furthermore, the term compatibility (see above) implies that not everyone (your 
impossible presumption of 100%) is aligned.

This is not a debatable subject as far as I'm concerned, but it's worth 
discussion for those who aren't familiar.

e

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

"Softforks arentcompatible without miner enforcement"
Compatible with what?
"Softforks without miner support cause splits".
No, what causes splits are 3 things:

1) bugs
2) coordination mistakes
3) people wanting different rules.

Let me give an example. Let's say all users want change A.

Only 60% miners want it.
When it activates with LOT=true, will this cause a split?

Well, not necessarily. Since all users will be on the chain with change A,
all miners will quickly abandon that useless chain and start building on
the one that actually pays them.

Do you agree that's what would happen in this example given the assumptions?


On Tue, Jun 29, 2021, 20:44 Eric Voskuil  wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón  wrote:
>
> 
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> 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.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

All good questions.

 

> Is the goal here to do what the economic majority wants, or some other group? 
> If so, do you think we have an accurate way of measuring what the economic 
> majority wants?

 

It’s important that people understand that “economic” does not refer to people 
interested in, HODLing, coding, or selling Bitcoin. It is only those who are 
*presently accepting* it. We refer to these as “economic nodes”. Those are the 
people with the economic power to reject coin that they consider invalid. Only 
their validation is of any economic consequence in the event of a split. I see 
no reason to assume that the economy is any less centralized than mining is 
pooled. Today the support of the economy would be best measured by meeting with 
exchange operators. If they did not go along, any unenforced soft fork (split) 
would isolate everyone who thought they could continue to trade their coin on 
exchanges.

 

I’d also question the use of the term “majority”. It applies to hash power, by 
design, but not to the economy. A split of any size is possible, requiring no 
majority. All it requires is other people to trade with.

 

Exchanges are highly regulated and compliant institutions. Mining operations 
are heavily pooled. Neither of these is inherently better than the other. 
Everyone can have a say by being a miner or being a merchant. Subeconomies can 
split, majority hash power can censor (which is the exact mechanism of soft 
fork enforcement). These ideas are straightforward and hardly worthy of debate. 
The interesting question is how one gets others to go along with his new coin. 
Make no mistake, any rule change (soft or hard) is a new coin. If hash power 
doesn’t enforce the new rules of a soft fork, the chain is split just as if it 
was a hard fork.

 

I’m sure people will continue to try and devise ways to figure out who wants to 
come along, to try and convince people (including exchanges and miners) to do 
so, to reassure them that everyone else will “have to”, and to mislead them 
about the actual behavior and risks. We’ve seen permanent splits, and we’ve 
seen hash power enforced soft forks. We’re likely to see more of both. But as 
core devs we have a responsibility to inform people, honestly, and let them 
decide. My only beef with this whole process has been that a widespread belief 
had formed, supported by far too many core devs (and even embedded in the text 
of deployed BIPs), that soft forks are inherently “backward compatible”. This 
is unequivocally not true. The only such compatibility is majority hash power 
enforcement of a soft fork. This is not a matter of opinion, it’s the core 
innovation of Bitcoin. Proof of Work settles the question of who has authority 
to order transactions. Majority hash power has that authority. Merchants can 
split again and again, but their miners will still have that authority. If one 
wants a say, one can mine.

 

e

 

From: Billy Tetrud  
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil 
Cc: Jorge Timón ; Luke Dashjr ; Bitcoin 
Protocol Discussion 
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

 

@Jorge

 

>I don't think we should avoid splits at all costs.

 

I absolutely agree that we shouldn't avoid splits at all costs. There are some 
costs too high to pay to avoid a split. If an economic majority started wanting 
to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard 
fork away from that mess with a minority chain. 

 

>  I don't think we should avoid splits when possible, 

 

I want to see why exactly we disagree about avoiding chain splits "when 
possible". Are you really saying that we should just hard fork every time 
instead of soft fork? Should we even bother to get widespread buy in at all, or 
should we just release the software, hardfork away, and let anyone that wants 
to follow us follow us later? Are you not at all worried about the costs 
associated with an increased orphan rate and reorg rate? Are you not worried 
that an update might happen too fast and that a significant fraction of people 
that could have come along with us to the new update might be left behind 
because they didn't have time to evaluate the changed rules?

 

Do you agree that, in a conversation about rule changes, some people want it 
their way no matter what and will hardfork to get the rules they want, and some 
people want it their way, but only if enough other people agree to follow those 
rules too? Some people might want a rule change, but aren't willing to follow, 
say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% 
or 90%. Do you agree those people exist? 

 

If you do, then I don't understand why you disagree that we should avoid chain 
splits even "when possible". Maybe you could elaborate as to what you mean 
there. 

 

@Luke

 

Are you in agreement with Jorge here that we should not even attempt to a

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Zac Greenwood via bitcoin-dev]

> Majority hash power does have the ability to determine what gets
confirmed.

Miners don’t have the ability to decide whether a block is valid.

Hash power is only recognized as such if it is used for creating a valid
block, i.e., a block that strictly follows all the rules as set by the node
software that transacting users choose to run.

If suddenly 70% of all hash power decided to start mining blocks that are
invalid according to the rules set in the users’ software, then these
invalid blocks will be disregarded. From a user perspective, 70% of all
hash power will seem to have disappeared.

In short, users define what is Bitcoin, not miners. This is fundamental to
being decentralized.



On Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón  wrote:
>
> 
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> 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.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

@Jorge

>I don't think we should avoid splits at all costs.

I absolutely agree that we shouldn't avoid splits at all costs. There are
some costs too high to pay to avoid a split. If an economic majority
started wanting to increase bitcoin's blocksize to 1 GB next year, we
should absolutely hard fork away from that mess with a minority chain.

>  I don't think we should avoid splits when possible,

I want to see why exactly we disagree about avoiding chain splits "when
possible". Are you really saying that we should just hard fork every time
instead of soft fork? Should we even bother to get widespread buy in at
all, or should we just release the software, hardfork away, and let anyone
that wants to follow us follow us later? Are you not at all worried about
the costs associated with an increased orphan rate and reorg rate? Are you
not worried that an update might happen too fast and that a significant
fraction of people that could have come along with us to the new update
might be left behind because they didn't have time to evaluate the
changed rules?

Do you agree that, in a conversation about rule changes, some people want
it their way no matter what and will hardfork to get the rules they want,
and some people want it their way, but only if enough other people agree to
follow those rules too? Some people might want a rule change, but aren't
willing to follow, say, a 20% minority fork. Perhaps their personal cut-off
is 40% or 50% or 75% or 90%. Do you agree those people exist?

If you do, then I don't understand why you disagree that we should avoid
chain splits even "when possible". Maybe you could elaborate as to what you
mean there.

@Luke

Are you in agreement with Jorge here that we should not even attempt to
avoid chain splits?

> The only alternative to a split in the problematic scenarios are 1)
concede centralised miner control over the network, and 2) have
inconsistent enforcement of rules by users who don't agree on what the
correct rules are, again leading to centralised miner control over the
network.

There is not simply a binary "do or do not". There is also timing.
Non-contentious changes can happen fast. Contentious changes need more time
for discussion, preparation, or coordination, even if the eventual outcome
is the same. Do you disagree that timing issues can be
important, that delays can be useful and help to avoid chain splits? Do you
agree that miners have a (large) incentive to follow the economic majority?
Is the goal here to do what the economic majority wants, or some other
group? If so, do you think we have an accurate way of measuring what the
economic majority wants? Will that mechanism continue to be accurate into
the future?

I'm asking these questions to try and figure out why we disagree here.

On Tue, Jun 29, 2021 at 12:44 PM Eric Voskuil  wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón  wrote:
>
> 
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> 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.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1)
>> concede
>> > 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

> On Jun 29, 2021, at 12:28, Jorge Timón  wrote:
> 
> 
> "Confirmation" isn't needed for softforks.

All transactions require confirmation. Splitting does not change this.

Softforks are not compatible without miner enforcement. So soft forking without 
it has essentially the same effect as hard forking, the chain splits.

> Miners controlling confirmation doesn't mean miners control the rules, they 
> never did.

Please define “control” because these statements hinge on that word. Nobody 
“controls” the rules of others, nor did anyone claim that to be the case. 
Majority hash power does have the ability to determine what gets confirmed. 
That is the central design principle of proof of work. It takes that decision 
out of the hands of politicians and places it at the feet of the market.

> Read section 11 of the bitcoin paper "even with a majority of hashrate one 
> cannot arbitrarily change rules or forge signatures.

Never claimed that was the case. One can run any rules that one desires.

> You may say users chosing the rules is "politicial". Isn't miners deciding 
> them for users more political?

No, it’s economic. The largest investment in mining (including highest fees 
paid to incentivize it) determines censorship resistance.

> Whatever you call it, it is still how free software works: users decide what 
> to run.

A *person* can run whatever software they want. Money requires that others 
agree (same rules), and to be money bitcoin requires confirmation.

> 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.

It’s poorly understood because there are so many who should know better making 
very misleading statements.

> How can we expect users to understand bitcoin when most developers don't seem 
> to understand it?

Clearly we cannot.

> It is really sad.
> 
>> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>> 
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  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  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  wrote:
>>  @Luke
>>  
>> > They can still slow it down.
>>  
>>  Absolutely. However I think that the option of permanent failure is
>>  important. It 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

"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  wrote:

>
> > On Jun 29, 2021, at 10:55, Luke Dashjr  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  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 
> 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
> 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

> On Jun 29, 2021, at 10:55, Luke Dashjr  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  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  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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Luke Dashjr via bitcoin-dev]

The only alternative to a split in the problematic scenarios are 1) concede 
centralised miner control over the network, and 2) have inconsistent 
enforcement of rules by users who don't agree on what the correct rules are, 
again leading to centralised miner control over the network.

In other words, in this context, accepting a split between disagreeing users 
is the ONLY way Bitcoin can possibly continue as a decentralised currency. 
Making that split as clean and well-defined as possible not only ensures the 
best opportunity for both sides of the disagreement, 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).

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  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  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. 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

@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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

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 
  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
>  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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

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 
> >>  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
> >>>  >>> 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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

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 
>>  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
>>> >> 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 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

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 
>  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
>> > 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

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Luke Dashjr via bitcoin-dev]

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
> 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] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

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

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