path: root/a0/28303b38e0d680a6a88a95a3f5efb60974a149

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 44E86C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:39:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 23664403A7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:39:14 +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 9jBn6fQA4BkY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:39:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [IPv6:2a00:1450:4864:20::62c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 0B42D4012D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 15:39:12 +0000 (UTC)
Received: by mail-ej1-x62c.google.com with SMTP id r13so11570735ejd.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 17 Mar 2022 08:39:11 -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
 :cc; bh=caxKlq4jexxjsS087ayeXaLXgiw4cxXOa3VIAH8F0RA=;
 b=ljtQSAJOBBHGB8jBZDjvndzAQaSqPNffzLAv4TjrZ7I0gyjeHS7+XYrSyL1ONbNjA5
 624GWapiqf+D0UAz6LlwEE3+CwDGPtwmHNScPXUxyblw8p5Bp2rovERLpxqMjyxXPQCN
 qOZrFDR3dvOdOj8jSxJ3VV5dQNwWE6dPBkzkfHgvG3/3idrIH4Rr9xOMMfjmscuafS56
 K76R5/5ghFFx3/YGOKacGzz++FoVnG/vlijMOMncn9H6SIaX3OwNUbRKJLW0aN50l6Pz
 uaTJ1oq1WgB2NzHlr+GrNdU5lWpGttPfnApYP8M1xGc425UOVj5Psb4KwH3LO4jEeEAO
 gIxg==
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:cc;
 bh=caxKlq4jexxjsS087ayeXaLXgiw4cxXOa3VIAH8F0RA=;
 b=l2P//U/CyKyhv/1xYTEDxy5kSOLLzjuE2roKYW4JnqlUZysv4to2gfKIu5KpMm4PvH
 nK4VO18+FRIaojEC7lw1iuf2VjjZHYqK236umWzsBX0+bAxLLNHpQtBfkTNRIyZJ3nxJ
 TanhTrYZwk7Emjz+oLBhatzz2g5EFSMLEMrCi+eWrOwMXW5hPWG/gJff2omUu0vdspnM
 PtsDhCNj+e3iOEBHVB1BM1zF+GcsK51WUR5NCmlqiV4gnSuu4G6d3HBEIpbcsirNI0bV
 eJKBkvpwNHnibIpC5V6l2FqXguMR0i3X0oO8FPO96fcyUD0U3rsWdk8QutVu4a551wQL
 CXwQ==
X-Gm-Message-State: AOAM533feTgSo2Bfz5ep1Oei/32Kn8TF0jRnt2J93FLBS6matPCviqf+
 w3s7SLJrzo3eNkedAG9jZ/6jz9qguMmfxkLv2eJ60V5bTAM=
X-Google-Smtp-Source: ABdhPJyfqXYhoA3GatKNPXzwhFIEPf/Dy8IeDZESpZkV8sq8m1Mn2UuNPXJcZlcVjIbE2g8S23pt5A7wbGbULuRWXUI=
X-Received: by 2002:a17:907:728f:b0:6df:9397:fa01 with SMTP id
 dt15-20020a170907728f00b006df9397fa01mr3319069ejc.493.1647531549851; Thu, 17
 Mar 2022 08:39:09 -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>
 <CABm2gDpFCcNcJEwia-nBhpWSjQv7DPEpqTu-bRC8RDHaoDU-=g@mail.gmail.com>
In-Reply-To: <CABm2gDpFCcNcJEwia-nBhpWSjQv7DPEpqTu-bRC8RDHaoDU-=g@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 17 Mar 2022 10:38:53 -0500
Message-ID: <CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c906cc05da6bd4f0"
X-Mailman-Approved-At: Thu, 17 Mar 2022 15:42:29 +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: Thu, 17 Mar 2022 15:39:14 -0000

--000000000000c906cc05da6bd4f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.

Not the one I'll propose right here. What I propose specifically is
a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
support:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been
spent.
C. Poll results are considered only at each particular block height, where
the support and opposition responses are weighted by the UTXO amount (and
the support/oppose fraction in the message). This means you'd basically see
a rolling poll through the blockchain as new signed poll messages come in
and as their UTXOs are spent.

This is not vulnerable to sybil attacks because it requires access to UTXOs
and response-weight is directly tied to UTXO amount. If someone signs a
poll message with a key that can unlock (or is in some other designated way
associated with) a UTXO, and then spends that UTXO, their poll response
stops being counted for all block heights after the UTXO was spent.

Why put support and oppose fractions in the message? Who would want to both
support and oppose something? Any multiple participant UTXO would. Eg
lightning channels would, where each participant disagrees with the other.
They need to sign together, so they can have an agreement to sign for the
fractions that match their respective channel balances (using a force
channel close as a last resort against an uncooperative partner as usual).

This does have the potential issue of public key exposure prior to spending
for current addresses. But that could be fixed with a new address type that
has two public keys / spend paths: one for spending and one for signing.

> In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction fees.

Agreed, but it takes time for an economic shock to reach its new
equilibrium. That period of time, which might be rather precarious, should
be considered in a plan to preserve a minority fork.

> Would you rather that proposal be deployed with speedy trial activation
or with BIP8+LOT=3Dtrue activation?

For a proposal I don't want to succeed, I absolutely would prefer speedy
trial over BIP8+LOT=3Dtrue. Speedy trial at 90% signaling threshold can
quickly determine that the proposal (hopefully) does not have enough
consensus among miners. By contrast, BIP8+LOT=3Dtrue could polarize the
debate, worsening the community's ability to communicate and talk through
issues. It would also basically guarantee that a fork happens, which in the
best case (in my hypothetical point of view where I don't like the
proposal) would mean some small minority forks off the network, which
reduces the main chain's value somewhat (at least temporarily). Worst case
a small majority forces the issue at near 50% which would cause all sorts
of blockchain issues and would have a high probability of leading to a
hardfork by the minority.

All this sounds rather more tenable with speedy trial. Any proposal has
less chance of causing an actual fork (soft or otherwise) with speedy trial
vs LOT=3Dtrue. LOT=3Dtrue guarantees a fork if even a single person is runn=
ing
it. LOT=3Dtrue could certainly come in handy to initiate a UASF, but IMO
that's better left as a plan B or C.

> segwit... all the consequences of the change are not opt in.

I definitely agree there. The consequences of a soft fork are not always
opt in. That's basically what my example of a "dumb majority soft fork" is,
and sounds like what your "evil fork" basically is.

On Thu, Mar 17, 2022 at 7:19 AM Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Mar 12, 2022 at 2:35 PM 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> wro=
te:
> > A mechanism of soft-forking against activation exists.  What more do yo=
u
> 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.
>
> I want BIP+LOT=3Dtrue to be used. I want speedy trial not to be used.
> Luke wrote the code to resist BIP8+LOT=3Dtrue, and if he didn't, I could
> write it myself, yes.
> If you think that's not reasonable code to ever run, I don't think
> you're really getting the "softfork THAT YOU OPPOSE" part of the
> hypothetical right. Let me try to help with an example, although I
> hope we don't get derailed in the implementation details of the
> hypothetical evil proposal.
>
> Suppose someone proposes a weight size limit increase by a extension
> block softfork.
> Or instead of that, just imagine the final version of the covenants
> proposal has a backdoor in it or something.
>
>
> Would you rather that proposal be deployed with speedy trial
> activation or with BIP8+LOT=3Dtrue activation?
>
> >>
> >> 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 resis=
t
> it.
> >
> >
> > If I believe I'm in the economic majority then I'll just refuse to
> upgrade my node, which was option 2. I don't know why you dismissed it.
>
> Not upgrading your node doesn't prevent the softfork from being
> activated in your chain.
> A softfork may affect you indirectly even if you don't use the new
> features yourself directly.
> You may chose to stay in the old chain even if you don't consider
> you're "in the economic majority" at that moment.
>
> > 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 when the miner cartel forms, they aren't necessarily goi=
ng
> 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 transactio=
n
> fees of the censored transactions.
>
> It is true that a mining cartel doesn't need to use speedy trial or
> BIP8+LOT=3Dtrue to apply rule changes they want just because we do.
> But they would do if they wanted to maintain the appearance of benevolenc=
e.
>
> > 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 b=
y
> your lonesome self.  Money doesn't have economic value if no one else wan=
ts
> 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 h=
ow
> much better their version of Bitcoin is than the rest of us.
>
> Well, you could also have the option to stay in the old chain with the
> economic minority, it doesn't have to be you alone.
> We agree that one person alone can't use a currency.
>
> > 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.
>
> Well, the same could be said about segwit. And yet all the
> consequences of the change are not opt in.
> For example, segwit contained a block size limit increase.
> Sure, you can just not validate the witnesses, but then you're no
> longer a full node.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000c906cc05da6bd4f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>@Jorge<br></div><div>&gt; Any user polling system is =
going to be vulnerable to sybil attacks.</div><div><br></div>Not the one I&=
#39;ll propose right here. What I propose specifically is a=C2=A0coin-weigh=
ted signature-based poll with the following components:<div><div>A. Every p=
ollee signs messages like &lt;utxo_id, {soft_fork: 9 oppose:90% support:10%=
}&gt; for each UTXO they want to respond to the poll with.</div><div>B. A s=
igned message like that is valid only while that UTXO has not been spent.</=
div><div>C. Poll results are considered only at each particular block heigh=
t, where the support and opposition responses are weighted by the UTXO amou=
nt (and the support/oppose fraction in the message). This means you&#39;d b=
asically see a rolling poll through the blockchain as new signed poll messa=
ges come in and as their UTXOs are spent.=C2=A0</div><div><br></div><div>Th=
is is not vulnerable to sybil attacks because it requires access to UTXOs a=
nd response-weight is directly tied to UTXO amount. If someone signs a poll=
 message with a key that can unlock (or is in some other designated way ass=
ociated with) a UTXO, and then spends that UTXO, their poll response stops =
being counted for all block heights after the UTXO was spent.=C2=A0</div><d=
iv><br></div><div>Why put support and oppose fractions in the message? Who =
would want to both support and oppose something? Any multiple participant U=
TXO would. Eg lightning channels would, where each participant disagrees wi=
th the other. They need to sign together, so they can have an agreement to =
sign for the fractions that match their respective channel balances (using =
a force channel close as a last resort against an uncooperative partner as =
usual).=C2=A0</div><div><br></div><div>This does have the potential issue o=
f public key exposure prior to spending for current addresses. But that cou=
ld be fixed with a new address type that has two public keys / spend paths:=
 one for spending and one for signing.=C2=A0<br><div><div><br></div><div>&g=
t; In perfect competition the mining power costs per chain tends to equal t=
he rewards offered by that chain, both in subsidy and transaction fees.</di=
v><div><br><div>Agreed, but it takes time for an economic shock to reach it=
s new equilibrium. That period of time, which might be rather precarious, s=
hould be considered in a plan to preserve a minority fork.=C2=A0</div></div=
><div><br></div><div>&gt; Would you rather that proposal be deployed with s=
peedy trial activation or with BIP8+LOT=3Dtrue activation?</div><div><br></=
div><div>For a proposal I don&#39;t want to succeed, I absolutely would pre=
fer speedy trial over BIP8+LOT=3Dtrue. Speedy trial at 90% signaling thresh=
old can quickly determine that the proposal (hopefully) does not have enoug=
h consensus among miners. By contrast, BIP8+LOT=3Dtrue could polarize the d=
ebate, worsening the community&#39;s ability to communicate and talk throug=
h issues. It would also basically guarantee that a fork happens, which in t=
he best case (in my hypothetical point of view where I don&#39;t like the p=
roposal) would mean some small minority forks off the network, which reduce=
s the main chain&#39;s value somewhat (at least temporarily). Worst case a =
small majority forces the issue at near 50% which would cause all sorts of =
blockchain issues and would have a high probability of leading to a hardfor=
k=C2=A0by the minority.=C2=A0</div><div><br></div><div>All this sounds rath=
er more tenable with speedy trial. Any proposal has less chance of causing =
an actual fork (soft or otherwise) with speedy trial vs LOT=3Dtrue. LOT=3Dt=
rue guarantees a fork if even a single person is running it. LOT=3Dtrue cou=
ld certainly come in handy to initiate a UASF, but IMO that&#39;s better le=
ft as a plan B or C.=C2=A0</div><div><br></div><div>&gt; segwit... all the =
consequences of the change are not opt in.</div><div><br></div><div>I defin=
itely agree there. The consequences of a soft fork are not always opt in. T=
hat&#39;s basically what my example of a &quot;dumb majority soft fork&quot=
; is, and sounds like what your &quot;evil fork&quot; basically is.=C2=A0</=
div></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Thu, Mar 17, 2022 at 7:19 AM Jorge Tim=C3=B3n via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Mar 12, 2022 a=
t 2:35 PM Russell O&#39;Connor via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Mar 11, 2022 at 9:03 AM Jorge Tim=C3=B3n &lt;<a href=3D"mailto=
:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt; wrote:<br>
&gt; 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 hypotheti=
cal 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 That simply =
isn&#39;t reasonable, but if you think it is, I invite you to create such a=
 fork.<br>
<br>
I want BIP+LOT=3Dtrue to be used. I want speedy trial not to be used.<br>
Luke wrote the code to resist BIP8+LOT=3Dtrue, and if he didn&#39;t, I coul=
d<br>
write it myself, yes.<br>
If you think that&#39;s not reasonable code to ever run, I don&#39;t think<=
br>
you&#39;re really getting the &quot;softfork THAT YOU OPPOSE&quot; part of =
the<br>
hypothetical right. Let me try to help with an example, although I<br>
hope we don&#39;t get derailed in the implementation details of the<br>
hypothetical evil proposal.<br>
<br>
Suppose someone proposes a weight size limit increase by a extension<br>
block softfork.<br>
Or instead of that, just imagine the final version of the covenants<br>
proposal has a backdoor in it or something.<br>
<br>
<br>
Would you rather that proposal be deployed with speedy trial<br>
activation or with BIP8+LOT=3Dtrue activation?<br>
<br>
&gt;&gt;<br>
&gt;&gt; Please, try to imagine an example for an activation that you would=
n&#39;t like yourself. Imagine it gets proposed and you, as a user, want to=
 resist it.<br>
&gt;<br>
&gt;<br>
&gt; If I believe I&#39;m in the economic majority then I&#39;ll just refus=
e to upgrade my node, which was option 2. I don&#39;t know why you dismisse=
d it.<br>
<br>
Not upgrading your node doesn&#39;t prevent the softfork from being<br>
activated in your chain.<br>
A softfork may affect you indirectly even if you don&#39;t use the new<br>
features yourself directly.<br>
You may chose to stay in the old chain even if you don&#39;t consider<br>
you&#39;re &quot;in the economic majority&quot; at that moment.<br>
<br>
&gt; Not much can prevent a miner cartel from enforcing rules that users do=
n&#39;t want other than hard forking a replacement POW.=C2=A0 There is no e=
ffective difference between some developers releasing a malicious soft-fork=
 of Bitcoin and the miners releasing a malicious version themselves.=C2=A0 =
And when the miner cartel forms, they aren&#39;t necessarily going to be po=
lite enough to give a transparent signal of their new rules.=C2=A0 However,=
 without the economic majority enforcing their set of rules, the cartel con=
tinuously risks falling apart from the temptation of transaction fees of th=
e censored transactions.<br>
<br>
It is true that a mining cartel doesn&#39;t need to use speedy trial or<br>
BIP8+LOT=3Dtrue to apply rule changes they want just because we do.<br>
But they would do if they wanted to maintain the appearance of benevolence.=
<br>
<br>
&gt; On the other hand, If I find out I&#39;m in the economic minority then=
 I have little choice but to either accept the existence of the new rules o=
r sell my Bitcoin.=C2=A0 Look, you cannot have the perfect system of money =
all by your lonesome self.=C2=A0 Money doesn&#39;t have economic value if n=
o one else wants to trade you for it.=C2=A0 Just ask that poor user who YOL=
O&#39;d his own taproot activation in advance all by themselves.=C2=A0 I&#3=
9;m sure they think they&#39;ve got just the perfect money system, with tap=
root early and everything.=C2=A0 But now their node is stuck at block 69226=
1 and hasn&#39;t made progress since.=C2=A0 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 B=
itcoin is than the rest of us.<br>
<br>
Well, you could also have the option to stay in the old chain with the<br>
economic minority, it doesn&#39;t have to be you alone.<br>
We agree that one person alone can&#39;t use a currency.<br>
<br>
&gt; Even though you&#39;ve dismissed it, one of the considerations of tapr=
oot 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 possible.<br=
>
<br>
Well, the same could be said about segwit. And yet all the<br>
consequences of the change are not opt in.<br>
For example, segwit contained a block size limit increase.<br>
Sure, you can just not validate the witnesses, but then you&#39;re no<br>
longer a full node.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c906cc05da6bd4f0--