public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: <eric@voskuil.org>
To: "'Jorge Timón'" <jtimon@jtimon.cc>
Cc: 'Bitcoin Protocol Discussion'
	<bitcoin-dev@lists.linuxfoundation.org>,
	'Billy Tetrud' <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
Date: Wed, 30 Jun 2021 02:52:42 -0700	[thread overview]
Message-ID: <028901d76d95$abb883f0$03298bd0$@voskuil.org> (raw)
In-Reply-To: <CABm2gDrt5AD8erDwJQxtPg4bSbbxbRJ_Sm2KcHrqD2a=QVX3fQ@mail.gmail.com>

> From: Jorge Timón <jtimon@jtimon.cc> 

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



  reply	other threads:[~2021-06-30  9:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-26 20:21 [bitcoin-dev] Trinary Version Signaling for softfork upgrades Billy Tetrud
2021-06-26 21:13 ` Luke Dashjr
2021-06-26 21:43   ` Eric Voskuil
2021-06-26 22:05     ` Eric Voskuil
2021-06-27  8:47       ` Jorge Timón
2021-06-27  9:21         ` Eric Voskuil
2021-06-27 18:11           ` Billy Tetrud
2021-06-29  8:32             ` Jorge Timón
2021-06-29  8:44               ` Eric Voskuil
2021-06-29 17:55                 ` Luke Dashjr
2021-06-29 18:17                   ` Eric Voskuil
2021-06-29 19:28                     ` Jorge Timón
2021-06-29 19:44                       ` Eric Voskuil
2021-06-30  2:02                         ` Billy Tetrud
2021-06-30  8:55                           ` eric
2021-06-30  6:39                         ` Zac Greenwood
2021-06-30  9:16                         ` Jorge Timón
2021-06-30  9:52                           ` eric [this message]
2021-06-30 19:30                             ` Billy Tetrud
2021-06-30 19:42                               ` Billy Tetrud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='028901d76d95$abb883f0$03298bd0$@voskuil.org' \
    --to=eric@voskuil.org \
    --cc=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox