Message-ID: <21f49308-c624-8d55-a40d-6634b3cf4cb8@mattcorallo.com>
Date: Wed, 7 Apr 2021 13:13:11 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Ryan Grant <bitcoin-dev@rgrant.org>
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
 <874kgkkpji.fsf@rustcorp.com.au>
 <CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
 <87pmz6it7q.fsf@rustcorp.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <87pmz6it7q.fsf@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
Precedence: list


On 4/7/21 01:01, Rusty Russell via bitcoin-dev wrote:
> Ryan Grant <bitcoin-dev@rgrant.org> writes:
>> On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
>> What ST is saying is that a strategy of avoiding unnecessary risk is
>> stronger than a strategy of brinkmanship when brinkmanship wasn't
>> our only option.  Having deescalation in the strategy toolkit makes
>> Bitcoin stronger.
> 
> I don't believe that having a plan is brinkmanship or an escalation.

I strongly disagree with this characterization of ST, primarily because there just isn't the kind of agreement you seem 
to be assuming. ST isn't a "lets not decide because we don't want to formulate a specific grand plan" its more of a 
"lets not decide, because there are very strong, and very divergent viewpoints on what a specific grand plan can or 
should look like, and something most people are ok with is better than nothing at all". Ultimately, there are a number 
of possible directions a grand plan could go, and there appear to be at least several prominent (and likely many 
non-prominent) individuals who would strongly disagree with any such plan, you and I likely among them :).
>>
>> LOT=true does face the awkward question, but there are downsides:
>>
>>    - in the requirement to drop blocks from apathetic miners (although
>>      as Luke-Jr pointed out in a previous reply on this list they have
>>      no contract under which to raise a complaint); and
> 
> Surely, yes.  If the users of bitcoin decide blocks are invalid, they're
> invalid.  With a year's warning, and developer and user consensus
> against them, I think we've reached the limits of acceptable miner
> apathy.

You say "developer and user consensus against them" here, but then go on to argue that its perfectly acceptable for only 
a small subset of users to be required to do something below.

>>    - in the risk of a chain split, should gauging economic majority
>>      support - which there is zero intrinsic tooling for - go poorly.
> 
> Agreed that we should definitely do better here: in practice people
> would rely on third party explorers for information on the other side of
> the split.  Tracking the cumulative work on invalid chains would be a
> good idea for bitcoind in general (AJ suggested this, IIRC).

We already have a really, really great precedent for tracking economic majority, I'd argue we have great tooling here! 
During Segwit2x, we had multiple futures and chain-split-tokens available, including the BitMex futures with billions of 
dollars in daily volume! For the BCH split, ViaBTC issued similar chain split tokens.

At the end of the day, economic value is going to determine the amount of hashrate on any chain, and there is a very, 
very strong incentive (trading fees!) for an exchange to list...more stuff, chainsplit tokens included.

Why do we need to build in really janky ways to measure economic majority when there's already a great one that 
experience has shown us will prop up and provide reasonable signal, given any material demand.

>>> Personally, I think the compromise position is using LOT=false and
>>> having those such as Luke and myself continue working on a LOT=true
>>> branch for future consideration.  It's less than optimal, but I
>>> appreciate that people want Taproot activated more than they want
>>> the groundwork future upgrades.
>>
>> Another way of viewing the current situation is that should
>> brinkmanship be necessary, then better tooling to resolve a situation
>> that requires brinkmanship will be invaluable.  But:
>>
>>    - we do not need to normalize brinkmanship;
>>
>>    - designing brinkmanship tooling well before the next crisis does
>>      not require selecting conveniently completed host features to
>>      strap the tooling onto for testing; and
> 
> Again, openly creating a contingency plan is not brinkmanship, it's
> normal.  I know that considering these scenarios is uncomfortable; I
> avoid conflict myself!  But I feel obliged to face this as a real
> possibility.
> 
> I think we should be normalizing the understanding that bitcoin users
> are the ultimate decider.  By offering *all* of them the tools to do so
> we show this isn't lip-service, but something that businesses and
> everyone else in the ecosystem should consider.

While I strongly agree with your principle, I strongly disagree with the practice of how you propose going about it. 
Ultimately, no matter what we decide here, elsewhere, or what the process for consensus changes is, the decider will be 
economic activity and users voting with their Bitcoin. We should start by acknowledging that, and acknowledging that the 
markets will (and have!) let us know what they think when there is any kind of material disagreement.

Then, we should optimize for ensuring that the market never needs to "correct the situation", because if we end up there 
(or in any of these kinds of scenarios), we've basically screwed the pooch. Sure, some 10% minority group (and usually 
less as time goes on) forking themselves off has turned out to basically be irrelevant, but if we end up with multiple 
active chains as a normal course of business (which I'd strongly argue we'd be optimizing for with some kind of UASF/LOT 
option design out the gate), all we do is encourage strife, at the cost of users who just want to use a robust and 
reliable Bitcoin.

>>    - it's already the case that a UASF branch can be prepared along
>>      with ST (ie. without requiring LOT=false), although the code is a
>>      bit more complex and the appropriate stopheight a few blocks later.
> 
> I don't believe this is true, unless you UASF before ST expires?  ST is
> explicitly designed *not* to give time to conclude that miners are
> stalling (unless something has changed from the initial 3 month
> proposal?).

ST is not intended to be an end-all, be-all of the taproot activation story. I don't think anyone who is pushing for it 
thinks that ST is the only option if miners are not able to upgrade before its signaling window expires. Just because it 
isn't designed to ensure we can play brinksman ship fork games with a UASF doesn't mean there isn't a followup that 
could include such a thing.

Matt