Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9CCFAC002D for ; 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 ; 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 ; 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 ; Tue, 26 Apr 2022 16:02:56 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id 17so22605308lji.1 for ; 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: <9xz3fyWghx-hWNovENgiaU_FvTKLvGAWq9ooCoeGMsaXT1UV6k9zV9fzjVXj346GNqOPV0UQvlE4YRvOpbnkwk5xUiugraaNK4V2iALskGo=@protonmail.com> <20220426104751.GA7996@erisian.com.au> In-Reply-To: <20220426104751.GA7996@erisian.com.au> From: Jeremy Rubin Date: Tue, 26 Apr 2022 09:02:42 -0700 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="00000000000055398b05dd90d340" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 On Tue, Apr 26, 2022 at 3:47 AM Anthony Towns 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
Thanks, this is good feed= back.=C2=A0

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 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:

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


And that it's really, AFAIU, the threat=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.

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.=

Kudos to NVK for explaining the nuance to me.


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 th= ings,
> 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 releas= e
> 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<= br> 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= 9;s
why bip8 recommends clients "should either use parameters that do not<= br> 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<= br> 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<= 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 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 chai= n
split would create.=C2=A0 Maybe it's still worthwhile despite those pro= blems
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--