From: Jeremy Rubin <jeremy.l.rubin@gmail•com>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] What to expect in the next few weeks
Date: Tue, 26 Apr 2022 09:02:42 -0700 [thread overview]
Message-ID: <CAD5xwhiFJZ+9POK8+xZ1eNvP0syP5Yx5pBxrUG-Jv2Y1kvWQxw@mail.gmail.com> (raw)
In-Reply-To: <20220426104751.GA7996@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 5997 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 8686 bytes --]
next prev parent reply other threads:[~2022-04-26 16:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 16:38 Michael Folkson
2022-04-23 5:10 ` Billy Tetrud
2022-04-23 10:03 ` Michael Folkson
2022-04-25 22:26 ` Michael Folkson
2022-04-26 5:48 ` Jeremy Rubin
2022-04-26 10:47 ` Anthony Towns
2022-04-26 16:02 ` Jeremy Rubin [this message]
2022-04-26 13:53 ` Michael Folkson
2022-04-26 15:20 ` Jeremy Rubin
2022-04-27 5:59 ` alicexbt
2022-04-26 11:40 ` Jorge Timón
2022-04-26 13:42 ` Erik Aronesty
2022-04-26 6:39 ` Melvin Carvalho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhiFJZ+9POK8+xZ1eNvP0syP5Yx5pBxrUG-Jv2Y1kvWQxw@mail.gmail.com \
--to=jeremy.l.rubin@gmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox