diff options
author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-04-26 09:02:42 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-26 16:02:58 +0000 |
commit | a35769c51832d35f2f5000b7fe18fd6d66dc65a8 (patch) | |
tree | badbdcc61cf0dd13417752fc86978cc5a72cbcab | |
parent | c252666d326cfe0677cfa72dc1801c61cc4bb1f9 (diff) | |
download | pi-bitcoindev-a35769c51832d35f2f5000b7fe18fd6d66dc65a8.tar.gz pi-bitcoindev-a35769c51832d35f2f5000b7fe18fd6d66dc65a8.zip |
Re: [bitcoin-dev] What to expect in the next few weeks
-rw-r--r-- | 4b/8aa675971db7146bf6aae29ec5a2e4d79f12f3 | 384 |
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's b= +at signal i wonder if he'll see this* triumvirate in this context is th= +at it'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's really, AFAIU, the <i>threat</i>=C2=A0of th= +e outcome that ensures that miners don't signal, and the followthrough = +is intentionally messy. If it's *not* messy, then it is actually less e= +ffective and people just 'go their separate ways', 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'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 <<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</= +a>> 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> +> Further, you're representing the state of affairs as if there'= +s a great<br> +> need to scramble to generate software for this, whereas there already = +are<br> +> scripts to support a URSF that work with the source code I pointed to = +from<br> +> my blog. This approach is a decent one, even though it requires two th= +ings,<br> +> because it is simple. I think it's important that people keep this= + in mind<br> +> because that is not a joke, the intention was that the correct set of = +check<br> +> and balance tools were made available. I'd be eager to learn what,= +<br> +> specifically, you think the advantages are of a separate binary releas= +e<br> +> rather than a binary + script that can handle both cases?<br> +<br> +The point of running a client with a validation requirement of "blocks= +<br> +must (not) signal" 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't running a client with the<b= +r> +opposite signalling requirement will reorg to your chain and ruleset.<br> +<br> +But forkd isn't quite enough to do that reliably -- instead, you'll= +<br> +start disconnecting nodes who forward blocks to you that were built on<br> +the block you disconnected, and you'll risk ending up isolated: that= +9;s<br> +why bip8 recommends clients "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".<br> +<br> +Also, in order to have other nodes reorg to your chain when it has<br> +more work, you don't want to exclusively connect to likeminded peers.<b= +r> +That'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: "the other chain= +<br> +appears to have maintained 3x as much hash power as the chain your are<br> +following".<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's already some code along those lines; but while= + I<br> +haven'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'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's one or maybe two invalid blocks in<b= +r> +a row from a random miner that's doing strange things, rather than if<b= +r> +there'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't want to just consider one or the other a complete<= +br> +write-off. That'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're lightning node is not following.<br> +<br> +So to your original question: I think it'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't think it comes close to addressing all the problems that a chai= +n<br> +split would create.=C2=A0 Maybe it's still worthwhile despite those pro= +blems<br> +if there's some existential threat to bitcoin, but (not) activating CTV= +<br> +doesn'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-- + |