summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy Rubin <jeremy.l.rubin@gmail.com>2022-04-26 09:02:42 -0700
committerbitcoindev <bitcoindev@gnusha.org>2022-04-26 16:02:58 +0000
commita35769c51832d35f2f5000b7fe18fd6d66dc65a8 (patch)
treebadbdcc61cf0dd13417752fc86978cc5a72cbcab
parentc252666d326cfe0677cfa72dc1801c61cc4bb1f9 (diff)
downloadpi-bitcoindev-a35769c51832d35f2f5000b7fe18fd6d66dc65a8.tar.gz
pi-bitcoindev-a35769c51832d35f2f5000b7fe18fd6d66dc65a8.zip
Re: [bitcoin-dev] What to expect in the next few weeks
-rw-r--r--4b/8aa675971db7146bf6aae29ec5a2e4d79f12f3384
1 files changed, 384 insertions, 0 deletions
diff --git a/4b/8aa675971db7146bf6aae29ec5a2e4d79f12f3 b/4b/8aa675971db7146bf6aae29ec5a2e4d79f12f3
new file mode 100644
index 000000000..640dc4713
--- /dev/null
+++ b/4b/8aa675971db7146bf6aae29ec5a2e4d79f12f3
@@ -0,0 +1,384 @@
+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--
+