path: root/75/8eaa6dcf7c3991b595fee3074c06bfd133fd0d

Return-Path: <mercedes.catherine.salazar@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6BA2EC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Mar 2022 22:34:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 671BB849EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Mar 2022 22:34:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GjoOxj7n3xzD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Mar 2022 22:34:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com
 [IPv6:2607:f8b0:4864:20::1129])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 27B07849ED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Mar 2022 22:34:34 +0000 (UTC)
Received: by mail-yw1-x1129.google.com with SMTP id
 00721157ae682-2e64a6b20eeso33714627b3.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Mar 2022 15:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=zAjPI+7jf3s7RXRmsDpZ66yHQttzCcGvllq1pjg6li0=;
 b=Lw82fxplAXxEyNu7cPwGeDJeLVXYLv2e6fycnKVES9nkOJr78ql8xtUY32Dg8oHtzf
 BAMHdwsiq3X273BLglq5r/3GEVw6HWQUi/HWtxjPRU+3lQMXtKWFur5QiCfNglQ22tCz
 tY96OcbdY99BSufyMkO7NPWjOeGZADUhfSq9Ry+xghhSTgnZN2+BrHYnOpLRPwsIGMy7
 1sjUlqRX2mqOSD40EhooU2jT9nH/pXtzcIfCQPi1Qhqb7TuRUFoo449iYCUgCWEUwVul
 cPZ0sbeBRHrZ1VKY9L0JDFHaOo7R8V+19WNr390swMOdL1nOSxilNrksvGnYUvp6kV7P
 Ywcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:content-transfer-encoding;
 bh=zAjPI+7jf3s7RXRmsDpZ66yHQttzCcGvllq1pjg6li0=;
 b=tmsbvVemKbi9kfqT4t+usUASH7WQHSnzj76EHZkcJ24q88rM7Q1JNNyJLTc7N7qfop
 bXoviz4WjYCWrI/3KNaiVFDcc9iqBdLXJfGvVrGriJxlIhstGH+oDfW8By0iY3TlMDvP
 R2ePRCIEHTVcAx4d3M/5exwXMDlI0nfaw9i8hy73gZ+cLHKeXNpz1lFXzGgnek+UWS6Z
 DrCuoNoi7reGOZk11MVgpqw9VLzIAcjHL1Svgq3sTD6WQQfoLK9ovWYL0tYYOlOVQCaJ
 9OG26E0OK99qv2Aje1k/v3Vyc0NFYx5e6vZs/9kn4pVK2XK8tCXk2fmeSb+NceIkqtP3
 91Vw==
X-Gm-Message-State: AOAM532VR6kteEqnGi3feH6Ff2Y8bozcazAWjjRR2kvhNk+sCXOXNyU0
 fw2AcSMWbOc/X6r0XOGx64uaR6JxqWDCGvWQrFvQOiVIMKDdK7LRsa4=
X-Google-Smtp-Source: ABdhPJz+q9cQSpM5KTijiwzlAO+M82PVNdoLx4BFSnpmWL1PIK4TrF/HauP2aV9Vv9T7/H6aboFgWRU4tomCDdtgL7g=
X-Received: by 2002:a81:a748:0:b0:2d6:1f8b:23a9 with SMTP id
 e69-20020a81a748000000b002d61f8b23a9mr2221450ywh.329.1648074872977; Wed, 23
 Mar 2022 15:34:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
 <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
 <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
 <CAMZUoKkPF6gPGpDWy1U+0GCONF-_qsTcOz0S1X+vx8_Kfqr8mw@mail.gmail.com>
 <CAGpPWDaXxANMw64ePBJgOqwc2XqKcj3Y3ceydNz8Km4q+67V8A@mail.gmail.com>
In-Reply-To: <CAGpPWDaXxANMw64ePBJgOqwc2XqKcj3Y3ceydNz8Km4q+67V8A@mail.gmail.com>
From: Kate Salazar <mercedes.catherine.salazar@gmail.com>
Date: Wed, 23 Mar 2022 23:34:21 +0100
Message-ID: <CAHiDt8BTy2O8GVzR1Zf=+j-gt3EDCVcZQNkVfOvspLzP_vZ--Q@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 24 Mar 2022 10:18:20 +0000
Subject: Re: [bitcoin-dev] Speedy Trial
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: Wed, 23 Mar 2022 22:34:35 -0000

Hey

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >  If I find out I'm in the economic minority then I have little choice b=
ut to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is =
where, say, mainstream adoption has happened, some crisis of some magnitude=
 happens that convinces a lot of people something needs to change now. Let'=
s say it's another congestion period where fees spike for months. Getting i=
nto and out of lighting is hard and maybe even the security of lightning's =
security model is called into question because it would either take too lon=
g to get a transaction on chain or be too expensive. Panicy people might on=
ce again think something like "let's increase the block size to 1GB, then w=
e'll never have this problem again". This could happen in a segwit-like sof=
t fork.

Bitcoin has never been mainstream, and yet somehow you have known
where you needed to be, all the time. The same will apply then. This
is a non-issue.

>
> In a future where Bitcoin is the dominant world currency, it might not be=
 unrealistic to imagine that an economic majority might not understand why =
such a thing would be so dangerous, or think the risk is low enough to be w=
orth it. At that point, we in the economic minority would need a plan to ha=
rd fork away. One wouldn't necessarily need to sell all their majority fork=
 Bitcoin, but they could.

Again, Bitcoin _is_ not an economic majority. Has never been. But
smart money always wins. This is a non-issue.

If one doesn't know where to be, there's the option to defer choices.
I was a big blocker myself, and yet I'm fairly OK even after being so
wrong. Even if forced to choose because of evil deadlines (which is
really unlikely), a divide strategy should be helpful enough to cut
losses in those cases.

>
> That minority fork would of course need some mining power. How much? I do=
n't know, but we should think about how small of a minority chain we could =
imagine might be worth saving. Is 5% enough? 1%? How long would the chain s=
tall if hash power dropped to 1%?
>
> TBH I give the world a ~50% chance that something like this happens in th=
e next 100 years. Maybe Bitcoin will ossify and we'll lose all the people t=
hat had deep knowledge on these kinds of things because almost no one's act=
ively working on it. Maybe the crisis will be too much for people to remain=
 rational and think long term. Who knows? But I think that at some point it=
 will become dangerous if there isn't a well discussed well vetted plan for=
 what to do in such a scenario. Maybe we can think about that 10 years from=
 now, but we probably shouldn't wait much longer than that. And maybe it's =
as simple as: tweak the difficulty recalculation and then just release a so=
ft fork aware Bitcoin version that rejects the new rules or rejects a speci=
fic existing post-soft-fork block. Would it be that simple?

Maybe this is worth thinking about, but really, there'll always be
smart enough people around. However
dumb people sometimes are not as dangerous as we think, and
smart people sometimes are not as flawless as we desire to take for granted=
.

>
> On Sat, Mar 12, 2022, 07:35 Russell O'Connor via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>>
>> On Fri, Mar 11, 2022 at 9:03 AM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>>>
>>>
>>>> A major contender to the Speedy Trial design at the time was to mandat=
e eventual forced signalling, championed by luke-jr.  It turns out that, at=
 the time of that proposal, a large amount of hash power simply did not hav=
e the firmware required to support signalling.  That activation proposal ne=
ver got broad consensus, and rightly so, because in retrospect we see that =
the design might have risked knocking a significant fraction of mining powe=
r offline if it had been deployed.  Imagine if the firmware couldn't be qui=
ckly updated or imagine if the problem had been hardware related.
>>>>>
>>>>>
>>>>> Yes, I like this solution too, with a little caveat: an easy mechanis=
m for users to actively oppose a proposal.
>>>>> Luke alao talked about this.
>>>>> If users oppose, they should use activation as a trigger to fork out =
of the network by invalidating the block that produces activation.
>>>>> The bad scenario here is that miners want to deploy something but use=
rs don't want to.
>>>>> "But that may lead to a fork". Yeah, I know.
>>>>> I hope imagining a scenario in which developers propose something tha=
t most miners accept but some users reject is not taboo.
>>>>
>>>>
>>>> This topic is not taboo.
>>>>
>>>> There are a couple of ways of opting out of taproot.  Firstly, users c=
an just not use taproot.  Secondly, users can choose to not enforce taproot=
 either by running an older version of Bitcoin Core or otherwise forking th=
e source code.  Thirdly, if some users insist on a chain where taproot is "=
not activated", they can always softk-fork in their own rule that disallows=
 the version bits that complete the Speedy Trial activation sequence, or al=
ternatively soft-fork in a rule to make spending from (or to) taproot addre=
sses illegal.
>>>
>>>
>>> Since it's about activation in general and not about taproot specifical=
ly, your third point is the one that applies.
>>> Users could have coordinated to have "activation x" never activated in =
their chains if they simply make a rule that activating a given proposal (w=
ith bip8) is forbidden in their chain.
>>> But coordination requires time.
>>
>>
>> A mechanism of soft-forking against activation exists.  What more do you=
 want? Are we supposed to write the code on behalf of this hypothetical gro=
up of users who may or may not exist for them just so that they can have a =
node that remains stalled on Speedy Trial lockin?  That simply isn't reason=
able, but if you think it is, I invite you to create such a fork.
>>
>>>
>>> Please, try to imagine an example for an activation that you wouldn't l=
ike yourself. Imagine it gets proposed and you, as a user, want to resist i=
t.
>>
>>
>> If I believe I'm in the economic majority then I'll just refuse to upgra=
de my node, which was option 2. I don't know why you dismissed it.
>>
>> Not much can prevent a miner cartel from enforcing rules that users don'=
t want other than hard forking a replacement POW.  There is no effective di=
fference between some developers releasing a malicious soft-fork of Bitcoin=
 and the miners releasing a malicious version themselves.  And when the min=
er cartel forms, they aren't necessarily going to be polite enough to give =
a transparent signal of their new rules.  However, without the economic maj=
ority enforcing their set of rules, the cartel continuously risks falling a=
part from the temptation of transaction fees of the censored transactions.
>>
>> On the other hand, If I find out I'm in the economic minority then I hav=
e little choice but to either accept the existence of the new rules or sell=
 my Bitcoin.  Look, you cannot have the perfect system of money all by your=
 lonesome self.  Money doesn't have economic value if no one else wants to =
trade you for it.  Just ask that poor user who YOLO'd his own taproot activ=
ation in advance all by themselves.  I'm sure they think they've got just t=
he perfect money system, with taproot early and everything.  But now their =
node is stuck at block 692261 and hasn't made progress since.  No doubt the=
y are hunkered down for the long term, absolutely committed to their fork a=
nd just waiting for the rest of the world to come around to how much better=
 their version of Bitcoin is than the rest of us.
>>
>> Even though you've dismissed it, one of the considerations of taproot wa=
s that it is opt-in for users to use the functionality.  Future soft-forks =
ought to have the same considerations to the extent possible.
>> _______________________________________________
>> 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