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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
