From: Matt Corallo <lf-lists@mattcorallo•com>
To: Rusty Russell <rusty@rustcorp•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Ryan Grant <bitcoin-dev@rgrant•org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
Date: Wed, 7 Apr 2021 13:13:11 -0400 [thread overview]
Message-ID: <21f49308-c624-8d55-a40d-6634b3cf4cb8@mattcorallo.com> (raw)
In-Reply-To: <87pmz6it7q.fsf@rustcorp.com.au>
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
next prev parent reply other threads:[~2021-04-07 17:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-24 3:46 Jeremy
2021-03-25 7:02 ` Anthony Towns
2021-03-25 14:30 ` Jeremy
2021-04-06 4:25 ` Rusty Russell
2021-04-07 1:20 ` Ryan Grant
2021-04-07 5:01 ` Rusty Russell
2021-04-07 13:42 ` Claus Ehrenberg
2021-04-07 15:25 ` eric
2021-04-07 17:13 ` Matt Corallo [this message]
2021-04-08 11:11 ` Anthony Towns
2021-03-24 11:23 Michael Folkson
2021-03-24 18:10 ` Jeremy
2021-03-24 19:14 ` Michael Folkson
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=21f49308-c624-8d55-a40d-6634b3cf4cb8@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@rgrant$(echo .)org \
--cc=rusty@rustcorp$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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