path: root/52/248d6884d5251bd46b6c205a0e3e2c213d8062

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 01047C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Mar 2021 14:33:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D19A04309B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Mar 2021 14:33:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5
 tests=[UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QT_yhre1N3q2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Mar 2021 14:33:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
 by smtp2.osuosl.org (Postfix) with ESMTPS id BBC9A43084
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Mar 2021 14:33:42 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1lGjcA-0000xi-77
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 02 Mar 2021 00:33:40 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Tue, 02 Mar 2021 00:33:33 +1000
Date: Tue, 2 Mar 2021 00:33:33 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210301143333.mzpbmsi4fwwl3msl@erisian.com.au>
References: <bc69d684-3d6e-624e-a859-c2ef8ad5cb13@posteo.net>
 <202102271755.02271.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <202102271755.02271.luke@dashjr.org>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Exploring alternative activation mechanisms:
 decreasing threshold
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 14:33:44 -0000

On Sat, Feb 27, 2021 at 05:55:00PM +0000, Luke Dashjr via bitcoin-dev wrote:

[on the topic of non-signalled activation; ie "it doesn't matter what
miners do or signal, the rules are active as of height X"]

> This has the same problems BIP149 did: since there is no signalling, it is 
> ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF 
> nodes will remain on the same chain, with conflicting perceptions of the 
> rules, and resolution (if ever) will be chaotic. Absent resolution, however, 
> there is a strong incentive not to rely on the rules, and thus it may never 
> get used, and therefore also never resolved.

I think this might be a bit abstract, and less convincing than it might
otherwise be.

To give a more explicit hypothetical: imagine that instead of making it
impossible to use an optimisation when mining (as segwit did to ASICBoost,
for which a patent had been applied for), a future soft-fork made it
possible/easier to use some mining optimisation, and further that the
optimisation is already patented, and that the patent wasn't widely known,
and the owners of the patent have put everyone that they can under NDA.

Obviously mining optimisations are great for manufacturers -- it means
a new generation of hardware is more efficient, which means miners
want to upgrade to it; but patented mining optimisations are bad for
decentralisation, because the're no competition in who can sell the new
generation of mining hardware, so the patent holder is able to choose
who is able to mine, and because miners control transaction selection,
they could insist that the only people they'll sell to must censor
transactions, and attempt to render miners that don't censor
uncompetitive.

So the incentives there are:

 - the patent holder wants the soft-fork to activate ASAP, and
   does not want to reveal the patent until after it's permanently
   locked in

 - people who want decentralisation/competition and know about the
   patent want to stop the soft-fork from activation, or hard-fork it
   out after it's activated; but they can't talk about the patent because
   of NDA (or other bribes/threats intended to keep them silent)

Suppose further that the anti-patent folks either directly control 20%
of hashpower, or are otherwise able to block the easy consensus path,
and that the patent holder isn't able to get over 50% of hashpower to
commit to orphaning non-signalling blocks to ensure early activation
despite that. (Or, alternatively, that an approach like Matt suggests in
"Straight Flag Day (Height)" is used, and there is no early-activation
via hashpower supermajority option)

So under that scenario you reach the timeout, but without activation
occurring. You also don't have any "reasonable, directed objection":
everyone who could provide a reasonable objection is under NDA.

What's the scenario look like if you say "signalling doesn't matter,
the software enforces the consensus rules"?

I think it'll be obvious there'll be two sets of software out there and
supported and following a single chain; one set that enforces the new
rules, and one set that doesn't, just as we had Bitcoin Unlimited back
in the day. For at least a while, it will be safe to do spends protected
by the new rules, because one set of nodes will enforce them, and any
miners running the other software won't want see it in their mempool,
and won't want to risk manually mining non-compliant transactions in case
it turns out they're in the minority -- just as Bitcoin Unlimited miners
didn't actually attempt to mine big blocks on mainnet back in the day.

So for a while, we have two divergent sets of maintained node software
following the same chain, with advocates of both claiming that they're the
majority. Some people will beleive the people claiming the new rules are
safe, and commit funds to them, and as those funds are demonstrably not
stolen, the number of people thinking it's safe will gradually increase
-- presumably the new rules have some benefit other than to the patent
holder, after all.

Eventually the patent gets revealed, though, just as covert ASICBoost
did. Either NDA's expire, something violates them, someone rediscovers
or reverse-engineers the idea, or the patent holder decides it's time
to start either suing competitors or advertising.

What happens at that point? We have two sets of node software that both
claim to have been in the majority, and one of which is clearly better
for decentralisation.

But if we all just switch to that two things happen: we allow miners to
steal the funds that users entrusted to the new rules, and anyone who
was enforcing the new rules but is not following the day-to-day drama
has a hard-fork event and can no longer follow the main chain until the
find new software to run.

Alternatively, do we all switch to software that protects users funds
and avoids hard-fork events, even though that software is bad for
decentralisation, and do we do that precisely when the people who were
advocating against using that software have just been proven to have
been right all along?

In my opinion, while the first choice would be horrible, the second
choice is completely at odds with human nature, so I think we'd end
up making the horrible choice, and so should avoid getting into that
scenario in the first place.

There's two ways we could avoid it: one is by not making changes any
time there's the possibility of good reasons to be against something:
so in the above, in an ideal world, we might have to delay activation
until any potential NDAs will expire.

I'm not convinced that level of patience is really plausible either
though: when covert ASICBoost became widely known, that was a "reasonable,
directed objection" to segwit -- it made real mining hardware less
efficient. We could have halted segwit deployment at that point and
changed the spec so that it didn't prevent covert ASICBoost -- eg, sorting
the wtxids prior to calculating the witness commitment would have made
segwit compatible with ASICBoost without a large impact in any other way,
and started again, perhaps with a BIP-91-alike to forbid miners signalling
for segwit so that we could begin a second activation attempt sooner.

But we didn't do anything like that; instead we got segwit activated
following the existing plan, and ended up with a hard-forked chain
split in the form of BCH. I'd suggested a lighter weight compromise to
some folks in early June 2017, to which one of the response was "The
time for this soft of ASICBoost compromise would have been right after
Scaling Bitcoin HK, when the mining hardware manufacturers realized the
unintentional effects of segwit on their hardware. But that door has long
since closed and at this point this proposal smells of appeasement." and
I think that ended up being a pretty accurate take.

The other way of avoiding that horrible scenario is committing to the
activation on-chain. That is, if the chain history satisfies property X,
enforce the new rules; if it does not satisify that property, don't
enforce the rules. That avoids the ambiguity: whether the new rules
are active becomes a matter of history, not subject to ongoing debate
and political posturing.

In the above scenario, where no one is able to discover/explain the actual
problems with the soft-fork before it activates, activation by signalling
means it likely activates unambiguously (because the opposition does not
seem reasonable), and once the problems are known they have to be dealt
with directly, there's no option to just pretend it never happened (and
that it's therefore fine to steal any funds from people who thought it
was able to be relied upon). That's much the same as how we've attempted
to fix problems with p2sh in segwit or taproot.



Other failure modes are possible too. 

One is if only a small number of rabid advocates run the code enforcing
the flag day, and someone calls their bluff -- if you're excluding that
failure case because "oh, but if core does it, plenty of people will
run the enforcing code" then you're assuming the market will just do
whatever the dev's say, and that devs are willing to test that assumption.

Another is if people factor in the above scenario and decide that if
there's any ongoing controversy they won't use the new soft fork's rules
-- if there's a chance everyone will switch over to the non-enforcing
software, why take the risk? But that allows you to prevent a soft-fork
from getting any adoption simply by maintaining an alternative client,
and hiring sock puppets to create controversy.



Another thing to consider is that it probably makes sense to support
"user-prohibited soft-forks" in a similar way to "user-activated
soft-forks". Saying "it's active if and only if there's signalling"
moves this action to whether you're required/prohibited from signalling,
which is fairly straightforward, with easy to analyse results. If you
make it be "just do/don't enforce the rules", then a user-prohibited
soft-fork following the same scheme seems like it would be very uncertain.

Cheers,
aj