Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C6052C000B for ; Sat, 12 Mar 2022 17:53:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id ACE3040194 for ; Sat, 12 Mar 2022 17:53:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HZOYCyVOPpT2 for ; Sat, 12 Mar 2022 17:53:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by smtp2.osuosl.org (Postfix) with ESMTPS id 94F214017B for ; Sat, 12 Mar 2022 17:53:18 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id qx21so25489228ejb.13 for ; Sat, 12 Mar 2022 09:53:18 -0800 (PST) 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; bh=eddlVAy8O+Ee2AMH1BHO1hHhQbyvdDi1fn5Y+raxs24=; b=aCiMxVjc8W3OSjZy7ew2+mfQCKib3pC2c5ihn+VRKbtYGiFJViIZug0RfLeGfZ7JeX xZJ+s6CrL55SCxDdPGdPlEg5qXkwyIoNjMBARlSwgwaXwNEo6tqtkI1B8JhsmeVKjbm8 pB1Rf4r6k4gE9prtKRLQIuH0N+2p1EGEPiAtz+FlYTvb8oUV7rZNIKqY4H0DiEI/O2iU P7QFXyEpAEMhC35Qc9cJ18xPCc3L6xZqBGA1l/2dbVVkrCW4KElLeO6HRDfDcOUWOIKV 4R3BB0OL1eCY0o3HaGUHfEzi1CkvxBWed6YhaFAup6s5b+UMLKx+imYWHf2LkykntXVY XXmg== 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; bh=eddlVAy8O+Ee2AMH1BHO1hHhQbyvdDi1fn5Y+raxs24=; b=dpJsDMAT5By5Sn52NgPxnl875x63VHuj5XZ2We5Ik48Ux+W66UFen/kYb8DfIw65Lx IKrO+d9Vu3FwpL/5dAuHB6cq9Dd+XbRJUYwCTpLfkQnQ/JNUXqLPLCNjTbxJD2je7xkF +tJKUMNKZ1eX53VC0cPCWSgUDF7pkJxduFVvgcQPOCSOc+kchQBALmz0/K+4gLXGNAfo sJ8Tz9nzP9JQPYdnoovzTiX7hrcSpujB0xAjEwZFBnR6qJGaaJTCpLRrFu03imH1Odae nyJER/AXDPP3E0hHIFTtjVv2TqVfIgT3OphwiJMTTvZTRhcDdJR6UqdvUfabNKy295S7 6nYw== X-Gm-Message-State: AOAM532/3bj7cSA9UAJou9YBuRp2XhB0K/5/E4L3chtrUnLoAksogDRY rLlm/227seCQXeJldBgpfJfpDYw1UJlQPGVZX85HygO+ X-Google-Smtp-Source: ABdhPJxufsDC52Bmhp5Eo6LT75RAHNm9hKVNxFlN7vRK6ARk4UOzSw26Do828+RMeFLFbnkzOGs3xZTgFk8s9/LINpc= X-Received: by 2002:a17:907:7e90:b0:6da:49e4:c7be with SMTP id qb16-20020a1709077e9000b006da49e4c7bemr13042391ejc.493.1647107596523; Sat, 12 Mar 2022 09:53:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Sat, 12 Mar 2022 11:52:59 -0600 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000329e2505da091f67" X-Mailman-Approved-At: Sat, 12 Mar 2022 18:33:48 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2022 17:53:20 -0000 --000000000000329e2505da091f67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > If I find out I'm in the economic minority then I have little choice but 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 into 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 long to get a transaction on chain or be too expensive. Panicy people might once again think something like "let's increase the block size to 1GB, then we'll never have this problem again". This could happen in a segwit-like soft fork. 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 worth it. At that point, we in the economic minority would need a plan to hard fork away. One wouldn't necessarily need to sell all their majority fork Bitcoin, but they could. That minority fork would of course need some mining power. How much? I don'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 stall if hash power dropped to 1%? TBH I give the world a ~50% chance that something like this happens in the next 100 years. Maybe Bitcoin will ossify and we'll lose all the people that had deep knowledge on these kinds of things because almost no one's actively 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 soft fork aware Bitcoin version that rejects the new rules or rejects a specific existing post-soft-fork block. Would it be that simple? 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 wrote= : > >> >> A major contender to the Speedy Trial design at the time was to mandate >>> 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 = have >>> the firmware required to support signalling. That activation proposal >>> never got broad consensus, and rightly so, because in retrospect we see >>> that the design might have risked knocking a significant fraction of mi= ning >>> power offline if it had been deployed. Imagine if the firmware couldn'= t be >>> quickly updated or imagine if the problem had been hardware related. >>> >> >>>> Yes, I like this solution too, with a little caveat: an easy mechanism >>>> 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 o= f >>>> the network by invalidating the block that produces activation. >>>> The bad scenario here is that miners want to deploy something but user= s >>>> don't want to. >>>> "But that may lead to a fork". Yeah, I know. >>>> I hope imagining a scenario in which developers propose something that >>>> 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 ca= n >>> just not use taproot. Secondly, users can choose to not enforce taproo= t >>> either by running an older version of Bitcoin Core or otherwise forking= the >>> 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 alternatively soft-fork in a rule to make spending from (o= r >>> to) taproot addresses illegal. >>> >> >> Since it's about activation in general and not about taproot >> specifically, 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 >> (with 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 > group of users who may or may not exist for them just so that they can ha= ve > a node that remains stalled on Speedy Trial lockin? That simply isn't > reasonable, 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 >> like yourself. Imagine it gets proposed and you, as a user, want to resi= st >> it. >> > > If I believe I'm in the economic majority then I'll just refuse to upgrad= e > 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 > difference between some developers releasing a malicious soft-fork of > Bitcoin and the miners releasing a malicious version themselves. And whe= n > the miner cartel forms, they aren't necessarily going to be polite enough > to give a transparent signal of their new rules. However, without the > economic majority enforcing their set of rules, the cartel continuously > risks falling apart from the temptation of transaction fees of the censor= ed > transactions. > > On the other hand, If I find out I'm in the economic minority then I have > 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 you= r > 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 > activation in advance all by themselves. I'm sure they think they've got > just the perfect money system, with taproot early and everything. But no= w > their node is stuck at block 692261 > and hasn't made > progress since. No doubt they are hunkered down for the long term, > absolutely committed to their fork and 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 was > 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 > --000000000000329e2505da091f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0=C2=A0If I find out I'm in the economic minority then I have little = choice but to either accept the existence of the new rules or sell my Bitco= in

I do worry about what = I have called a "dumb majority soft fork". This is where, say, ma= instream adoption has happened, some crisis of some magnitude happens that = convinces a lot of people something needs to change now. Let's say it&#= 39;s another congestion period where fees spike for months. Getting into an= d out of lighting is hard and maybe even the security of lightning's se= curity model is called into question because it would either take too long = to get a transaction on chain or be too expensive. Panicy people might once= again think something like "let's increase the block size to 1GB,= then we'll never have this problem again". This could happen in a= segwit-like soft fork.

In a future where Bitcoin is the dominant world currency, it might not= be unrealistic to imagine that an economic majority might not understand w= hy such a thing would be so dangerous,=C2=A0or think the risk is low enough= to be worth it. At that point, we in the economic minority would need a pl= an to hard fork away. One wouldn't necessarily need to sell all their m= ajority fork Bitcoin, but they could.=C2=A0
<= span style=3D"font-size:12.8px">
That minority fork would of course need some minin= g power. How much? I don'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 stall if hash power dropped to 1%?=C2=A0

TBH I give the world a ~50%= chance that something like this happens in the next 100 years. Maybe Bitco= in will ossify and we'll lose all the people that had deep knowledge on= these kinds of things because almost no one's actively working on it. = Maybe the crisis will be too much for people to remain rational and think l= ong term. Who knows? But I think that at some point it will become dangerou= s if there isn't a well discussed well vetted plan for what to do in su= ch a scenario. Maybe we can think about that 10 years from now, but we prob= ably shouldn't wait much longer than that. And maybe it's as simple= as: tweak the difficulty recalculation and then just release a soft fork a= ware Bitcoin version that rejects the new rules or rejects a specific exist= ing post-soft-fork block. Would it be that simple?
=
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> wrote:

A major contender to the Speedy Trial design at the time was t= o mandate eventual forced signalling, championed by luke-jr.=C2=A0 It turns= out that, at the time of that proposal, a large amount of hash power simpl= y did not have the firmware required to support signalling.=C2=A0 That acti= vation proposal never got broad consensus, and rightly so, because in retro= spect we see that the design might have risked knocking a significant fract= ion of mining power offline if it had been deployed.=C2=A0 Imagine if the f= irmware couldn't be quickly updated or imagine if the problem had been = hardware related.

Yes,= I like this solution too, with a little caveat: an easy mechanism for user= s to actively oppose a proposal.
Luke alao talked ab= out this.
If users oppose, they should use activatio= n as a trigger to fork out of the network by invalidating the block that pr= oduces activation.
The bad scenario here is that min= ers want to deploy something but users don't want to.
"But that may lead to a fork". Yeah, I know.
I hope imagining a scenario in which developers propose something= that 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.=C2=A0 Fi= rstly, users can just=20 not use taproot.=C2=A0 Secondly, users can choose to not enforce taproot ei= ther by running an older version of Bitcoin Core or otherwise forking the s= ource code.=C2=A0 Thirdly, if some users insist on a chain where taproot is= "not activated", they can always softk-fork in their own rule th= at 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.
<= br>
Since it's about activation in general and n= ot about taproot specifically, 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 act= ivating a given proposal (with bip8) is forbidden in their chain.
But coordination requires time.
=
A mechanism of soft-forking against activation exists.=C2=A0= What more do you want? Are we supposed to write the code on behalf of this= hypothetical group 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?=C2=A0 Th= at simply isn't reasonable, but if you think it is, I invite you to cre= ate such a fork.
=C2=A0
Please, try to imagin= e an example for an activation that you wouldn't like yourself. Imagine= it gets proposed and you, as a user, want to resist it.

If I believe I'm in the economic majority then I&#= 39;ll just refuse to upgrade my node, which was option 2. I don't know = why you dismissed it.

Not much can prevent a miner cartel from enforcing rules t= hat users don't want other than hard forking a replacement POW.=C2=A0 T= here is no effective difference between some developers releasing a malicio= us soft-fork of Bitcoin and the miners releasing a malicious version themse= lves.=C2=A0 And when the miner cartel forms, they aren't necessarily g= oing to be polite enough to give a transparent signal of their new rules.= =C2=A0 However, without the economic majority enforcing their set of rules,= the cartel continuously risks falling apart from the temptation of transac= tion fees of the censored transactions.

On the = other hand, If I find out I'm in the economic minority then I have litt= le choice but to either accept the existence of the new rules or sell my Bi= tcoin.=C2=A0 Look, you cannot have the perfect system of money all by your = lonesome self.=C2=A0 Money doesn't have economic value if no one else w= ants to trade you for it.=C2=A0 Just ask that poor user who YOLO'd his = own taproot activation in advance all by themselves.=C2=A0 I'm sure the= y think they've got just the perfect money system, with taproot early a= nd everything.=C2=A0 But now their node is stuck at block 692261 and hasn't made progress since.=C2=A0 No doubt t= hey are hunkered down for the long term, absolutely committed to their fork= and just waiting for the rest of the world to come around to how much bett= er their version of Bitcoin is than the rest of us.

Even though you've dismissed it, one of the considerations = of taproot was that it is opt-in for users to use the functionality.=C2=A0 = Future soft-forks ought to have the same considerations to the extent possi= ble.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000329e2505da091f67--