path: root/4b/8aa675971db7146bf6aae29ec5a2e4d79f12f3

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9CCFAC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 16:02:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 7C69F8329E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 16:02:58 +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: 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 n4CKFf7L3UQw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 16:02:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [IPv6:2a00:1450:4864:20::232])
 by smtp1.osuosl.org (Postfix) with ESMTPS id DE24E83295
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 16:02:56 +0000 (UTC)
Received: by mail-lj1-x232.google.com with SMTP id 17so22605308lji.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Apr 2022 09:02:56 -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=yUTTrXhf+YfQPhKfRCweMpLm9kPcBQPqHP4QswQAqUQ=;
 b=FB1vS/p/tR7TZWf361SbwPcFvLkDqtubSgRuyGhXz+upnjLYWpX8VXS02hwmVoW/pK
 hI0O3xaa86JVOpKiOA+1fqlBOgRyUy0sMok/K5sHSLtp10f7nxi83HjOkH+k3khcNeUZ
 42/cW900fzJz/DTHNkiZlb7OMEm9cEqTja7f64dmFsaB+cBOqM59AUnAr3MeOwlshGi2
 LaJdsXWIRysL0KqBeFUmZlImoNWdrZo1BsbypduPPgYg+yfX7YX8m0izSge+3lYckzHN
 3BeyFGq4VGmnEEz98RAplpODw9n7SHznjfixcnNkVZVfLxPSJ0eGiiCxOCREbxudaJoj
 nbCQ==
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=yUTTrXhf+YfQPhKfRCweMpLm9kPcBQPqHP4QswQAqUQ=;
 b=VdQfiROJNjGD2LB2zHxL8RDbPtCdRq4u4i3nFHi/u9E6xm6AJ1WHwd1CltqP4Um+tf
 jKIvQlg/bjjCOdzb8V8KFFq8DLq0yeNMj1KcDPUb9TizYMaYwVZcv4zxaaukJVudNnz5
 4VXyHkrCoTMc5AFwyr9I7e0QFOeQrgP4Tg/MW5GuAhfjX/iKtwhN9RuX/brhxM4axsOf
 mAvz6cn/e7qCA1dhan6TBZBln8dSxSjNW5/tY2b2WBm1/i++rrlRvYJtY/nSLjn3L2Mn
 7fmb1fbitiqSgrMonJXZgPIoIhMsTbtL4GXYxdMvPlR12T0vxtKfOV1828CbOSYRePr3
 xzrw==
X-Gm-Message-State: AOAM530dVSECQ6vA3k0GPmz8PQpnVToRSOFnKUOZR9Y6wJKt3WPayj+x
 mYWWxlWz2DV+z3ZbbuTd3cGwemG+A2G4fgurE4YshVHn
X-Google-Smtp-Source: ABdhPJxQ5MGcBES9Alqr2bhmfG1R9/u60ZvSoqD3V5fTwCFX8RYWEcjtiJjcYdTjNnwjqFoMC7bAy+f/W5cDT1ZIPdk=
X-Received: by 2002:a2e:a545:0:b0:24d:c472:9969 with SMTP id
 e5-20020a2ea545000000b0024dc4729969mr14398688ljn.376.1650988974158; Tue, 26
 Apr 2022 09:02:54 -0700 (PDT)
MIME-Version: 1.0
References: <ddEQnfld862QINpJ03wcoqC2mNNV5Q_GmRziweKYbaUey2deOVrhtgWHhcyqlwkWd060fle-22hoiiBryYIPAW9ZsSQgozdqH2QVPgZ-5og=@protonmail.com>
 <CAGpPWDaBzY-Q+TZisRQTKtH52=zCVJsPyZQppLdYPW9iWJrWtg@mail.gmail.com>
 <9xz3fyWghx-hWNovENgiaU_FvTKLvGAWq9ooCoeGMsaXT1UV6k9zV9fzjVXj346GNqOPV0UQvlE4YRvOpbnkwk5xUiugraaNK4V2iALskGo=@protonmail.com>
 <MnfcEMqsO782F3nwY9kRUybw3EDi5aw5OYfc4lqcfKT28QY6-lAUzK5eWFobw3bID44IAXhx5dw2QYoJvlCU6gyeysCn8whHmIBPy_QP5xk=@protonmail.com>
 <CAD5xwhjUzT=Fetn66LgFUdE9oPwUnbFOmrHjvXWm3+QqVgLDgg@mail.gmail.com>
 <20220426104751.GA7996@erisian.com.au>
In-Reply-To: <20220426104751.GA7996@erisian.com.au>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 26 Apr 2022 09:02:42 -0700
Message-ID: <CAD5xwhiFJZ+9POK8+xZ1eNvP0syP5Yx5pBxrUG-Jv2Y1kvWQxw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="00000000000055398b05dd90d340"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] What to expect in the next few weeks
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: Tue, 26 Apr 2022 16:02:58 -0000

--00000000000055398b05dd90d340
Content-Type: text/plain; charset="UTF-8"

Thanks, this is good feedback.

I think the main thing then to add to forkd would be some sort of seed
nodes set that you can peer with of other forkd runners? And have forkd be
responsible for making sure you addnode them?

wrt the generation of other problems, my understanding of the *summons
rusty's bat signal i wonder if he'll see this* triumvirate in this context
is that it's essentially, in this case:

- Dev proposes
- Miners may signal
- Users may credibly threaten that if signal, Miners will lose consensus
with sufficient portion of economy.


And that it's really, AFAIU, the *threat* of the outcome that ensures that
miners don't signal, and the followthrough is intentionally messy. If it's
*not* messy, then it is actually less effective and people just 'go their
separate ways', but if the intent is to drive consensus, it must be messy.

This is similar to Nuclear Deterrence game theory, whereby it's clearly not
the right call to use nukes, but paired with an irrational leader, the
credible threat serves to force a system of more relative peace. So the
pairing of ST + Users able to reject, albeit messily, does form a
relatively stable configuration.

Kudos to NVK for explaining the nuance to me.
--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Tue, Apr 26, 2022 at 3:47 AM Anthony Towns <aj@erisian.com.au> wrote:

> On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev
> wrote:
> > Further, you're representing the state of affairs as if there's a great
> > need to scramble to generate software for this, whereas there already are
> > scripts to support a URSF that work with the source code I pointed to
> from
> > my blog. This approach is a decent one, even though it requires two
> things,
> > because it is simple. I think it's important that people keep this in
> mind
> > because that is not a joke, the intention was that the correct set of
> check
> > and balance tools were made available. I'd be eager to learn what,
> > specifically, you think the advantages are of a separate binary release
> > rather than a binary + script that can handle both cases?
>
> The point of running a client with a validation requirement of "blocks
> must (not) signal" is to handle the possiblity of there being a chain
> split, where your preferred ruleset ends up on the less-work side.
>
> Ideally that will be a temporary situation and other people will come to
> your side, switch their miners over etc, and your chain will go back to
> having the most work, and anyone who wasn't running a client with the
> opposite signalling requirement will reorg to your chain and ruleset.
>
> But forkd isn't quite enough to do that reliably -- instead, you'll
> start disconnecting nodes who forward blocks to you that were built on
> the block you disconnected, and you'll risk ending up isolated: that's
> why bip8 recommends clients "should either use parameters that do not
> risk there being a higher work alternative chain, or specify a mechanism
> for implementations that support the deployment to preferentially peer
> with each other".
>
> Also, in order to have other nodes reorg to your chain when it has
> more work, you don't want to exclusively connect to likeminded peers.
> That's less of a big deal though, since you only need one peer to
> forward the new chain to the compatible network to trigger all of them
> to reorg.
>
> Being able to see the other chain has more work might be valuable in
> order to add some sort of user warning signal though: "the other chain
> appears to have maintained 3x as much hash power as the chain your are
> following".
>
> In theory, using the `BLOCK_RECENT_CONSENSUS_CHANGE` flag to indicate
> unwanted signalling might make sense; then you could theoretically
> trigger on that to avoid disconnecting inbound peers that are following
> the wrong chain. There's already some code along those lines; but while I
> haven't checked recently, I think it ends up failing relatively quickly
> once an invalid chain has been extended by a few blocks, since they'll
> result in `BLOCK_INVALID_PREV` errors instead. The segwit UASF client
> took some care to try to make this work, fwiw.
>
> (As it stands, I think RECENT_CONSENSUS_CHANGE only really helps with
> avoiding disconnections if there's one or maybe two invalid blocks in
> a row from a random miner that's doing strange things, rather than if
> there's an active conflict resulting in a deliberate chain split).
>
> On the other hand, if there is a non-trivial chain split, then everyone
> has to deal with splitting their coins across the different chains,
> presuming they don't want to just consider one or the other a complete
> write-off. That's already annoying; but for lightning funds I think it
> means the automation breaks down, and every channel in the network would
> need to be immediately closed on chain, as otherwise accepting state
> updates risks losing the value of your channel balance on whichever
> chain you're lightning node is not following.
>
> So to your original question: I think it's pretty hard to do all that
> stuff in a separate script, without updating the node software itself.
>
> More generally, while I think forkd *is* pretty much state of the art;
> I don't think it comes close to addressing all the problems that a chain
> split would create.  Maybe it's still worthwhile despite those problems
> if there's some existential threat to bitcoin, but (not) activating CTV
> doesn't seem to rise to that level to me.
>
> Just my opinion, but: without some sort of existential threat, it
> seems better to take things slowly and hold off on changes until either
> pretty much everyone who cares is convinced that the change is a good
> idea and ready to go; or until someone has done the rest of the work to
> smooth over all the disruption a non-trivial chain split could cause.
> Of course, the latter option is a _lot_ of work, and probably requires
> consensus changes itself...
>
> Cheers,
> aj
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Thanks, this is good feed=
back.=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">I think the main thing then to add to forkd would be some=
 sort of seed nodes set that you can peer with of other forkd runners? And =
have forkd be responsible for making sure you addnode them?</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">wrt the g=
eneration of other problems, my understanding of the *summons rusty&#39;s b=
at signal i wonder if he&#39;ll see this* triumvirate in this context is th=
at it&#39;s essentially, in this case:</div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000">- Dev proposes</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">- Miners may signal</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">- Users may credibly threaten that if signal, Miners will lose consen=
sus with sufficient portion of economy.</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">And that it&#39;s really, AFAIU, the <i>threat</i>=C2=A0of th=
e outcome that ensures that miners don&#39;t signal, and the followthrough =
is intentionally messy. If it&#39;s *not* messy, then it is actually less e=
ffective and people just &#39;go their separate ways&#39;, but if the inten=
t is to drive consensus, it must be messy.</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">This is similar to Nuclear=
 Deterrence game theory, whereby it&#39;s clearly not the right call to use=
 nukes, but paired with an irrational leader, the credible threat serves to=
 force a system of more relative peace. So the pairing of ST=C2=A0+ Users a=
ble to reject, albeit messily, does form a relatively stable configuration.=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000">Kudos to NVK for explaining the nuance to me.</div><div><div dir=3D"=
ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank=
">@JeremyRubin</a><br></div></div></div><br></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 26, 2022 at 3:47 AM=
 Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex">On Mon, Apr 25, 2022 at 10:48:20PM =
-0700, Jeremy Rubin via bitcoin-dev wrote:<br>
&gt; Further, you&#39;re representing the state of affairs as if there&#39;=
s a great<br>
&gt; need to scramble to generate software for this, whereas there already =
are<br>
&gt; scripts to support a URSF that work with the source code I pointed to =
from<br>
&gt; my blog. This approach is a decent one, even though it requires two th=
ings,<br>
&gt; because it is simple. I think it&#39;s important that people keep this=
 in mind<br>
&gt; because that is not a joke, the intention was that the correct set of =
check<br>
&gt; and balance tools were made available. I&#39;d be eager to learn what,=
<br>
&gt; specifically, you think the advantages are of a separate binary releas=
e<br>
&gt; rather than a binary + script that can handle both cases?<br>
<br>
The point of running a client with a validation requirement of &quot;blocks=
<br>
must (not) signal&quot; is to handle the possiblity of there being a chain<=
br>
split, where your preferred ruleset ends up on the less-work side.<br>
<br>
Ideally that will be a temporary situation and other people will come to<br=
>
your side, switch their miners over etc, and your chain will go back to<br>
having the most work, and anyone who wasn&#39;t running a client with the<b=
r>
opposite signalling requirement will reorg to your chain and ruleset.<br>
<br>
But forkd isn&#39;t quite enough to do that reliably -- instead, you&#39;ll=
<br>
start disconnecting nodes who forward blocks to you that were built on<br>
the block you disconnected, and you&#39;ll risk ending up isolated: that&#3=
9;s<br>
why bip8 recommends clients &quot;should either use parameters that do not<=
br>
risk there being a higher work alternative chain, or specify a mechanism<br=
>
for implementations that support the deployment to preferentially peer<br>
with each other&quot;.<br>
<br>
Also, in order to have other nodes reorg to your chain when it has<br>
more work, you don&#39;t want to exclusively connect to likeminded peers.<b=
r>
That&#39;s less of a big deal though, since you only need one peer to<br>
forward the new chain to the compatible network to trigger all of them<br>
to reorg.<br>
<br>
Being able to see the other chain has more work might be valuable in<br>
order to add some sort of user warning signal though: &quot;the other chain=
<br>
appears to have maintained 3x as much hash power as the chain your are<br>
following&quot;.<br>
<br>
In theory, using the `BLOCK_RECENT_CONSENSUS_CHANGE` flag to indicate<br>
unwanted signalling might make sense; then you could theoretically<br>
trigger on that to avoid disconnecting inbound peers that are following<br>
the wrong chain. There&#39;s already some code along those lines; but while=
 I<br>
haven&#39;t checked recently, I think it ends up failing relatively quickly=
<br>
once an invalid chain has been extended by a few blocks, since they&#39;ll<=
br>
result in `BLOCK_INVALID_PREV` errors instead. The segwit UASF client<br>
took some care to try to make this work, fwiw.<br>
<br>
(As it stands, I think RECENT_CONSENSUS_CHANGE only really helps with<br>
avoiding disconnections if there&#39;s one or maybe two invalid blocks in<b=
r>
a row from a random miner that&#39;s doing strange things, rather than if<b=
r>
there&#39;s an active conflict resulting in a deliberate chain split).<br>
<br>
On the other hand, if there is a non-trivial chain split, then everyone<br>
has to deal with splitting their coins across the different chains,<br>
presuming they don&#39;t want to just consider one or the other a complete<=
br>
write-off. That&#39;s already annoying; but for lightning funds I think it<=
br>
means the automation breaks down, and every channel in the network would<br=
>
need to be immediately closed on chain, as otherwise accepting state<br>
updates risks losing the value of your channel balance on whichever<br>
chain you&#39;re lightning node is not following.<br>
<br>
So to your original question: I think it&#39;s pretty hard to do all that<b=
r>
stuff in a separate script, without updating the node software itself.<br>
<br>
More generally, while I think forkd *is* pretty much state of the art;<br>
I don&#39;t think it comes close to addressing all the problems that a chai=
n<br>
split would create.=C2=A0 Maybe it&#39;s still worthwhile despite those pro=
blems<br>
if there&#39;s some existential threat to bitcoin, but (not) activating CTV=
<br>
doesn&#39;t seem to rise to that level to me.<br>
<br>
Just my opinion, but: without some sort of existential threat, it<br>
seems better to take things slowly and hold off on changes until either<br>
pretty much everyone who cares is convinced that the change is a good<br>
idea and ready to go; or until someone has done the rest of the work to<br>
smooth over all the disruption a non-trivial chain split could cause.<br>
Of course, the latter option is a _lot_ of work, and probably requires<br>
consensus changes itself...<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div>

--00000000000055398b05dd90d340--