reply on: The asymmetric advantage of a BIP-110 fork \ stacker news

pull down to refresh

1 sat \ 17 replies \ @Scoresby OP 16 Jan \ on: The asymmetric advantage of a BIP-110 fork bitcoin

Is this the answer I've been looking for?

Everybody is running the “URSF software” already.

Assuming that support remains similarly marginal as it is (1/552 blocks this difficulty period so far), Bitcoin will likely find many blocks before RDTS finds its first block in the mandatory signaling period.

If Bitcoin is dozens of blocks ahead when the first RDTS block is proffered, a reorg will be unacceptable to the Bitcoin ecosystem, and power users (incl. LSPs, miner that found blocks, businesses that accepted payments, etc.) may as well call invalidateblock <RDTS_block_hash>, and move on with their lives.

22 sats \ 0 replies \ @optimism 17 Jun

In the meantime, BIP-110 chain is mining at a loss?

123 sats \ 7 replies \ @oomahq 16 Jan

Yes. The pre BIP-110 chain can always be wiped out again and again even if it gets ahead momentarily, while the BIP-110 chain cannot be wiped out when it falls behind.

To neuter this effect a counter-softfork would need to be deployed. Thence the lowest friction to a miner is to go with a soft fork.

395 sats \ 1 reply \ @Scoresby OP 16 Jan

Same energy:

It seems to me that this is all predicated on having a majority of hashrate. My frustration has been with an argument that goes: "We don't need a majority of hashrate because we will eventually get a majority of hashrate."

513 sats \ 0 replies \ @Murch 16 Jan

"We don't need a majority of hashrate because we will eventually get a majority of hashrate."

That’s it: you have distilled the essence of the RDTS fallacy perfectly.

1 sat \ 4 replies \ @Murch 16 Jan

That’s unnecessary if support for RDTS remains as marginal as expected. Miners could also use invalidateblock on the first block of the RDTS chain to ignore the RDTS chain permanently; no fork necessary.

22 sats \ 3 replies \ @oomahq 17 Jan

Well, what you just described is a fork. The counter-softfork I alluded to, actually.

1 sat \ 2 replies \ @Murch 17 Jan

Fair enough! I thought you meant to express that it required a coordinated software update with a consensus rule change.

3 sats \ 1 reply \ @oomahq 17 Jan

Running invalidateblock in the manner you described is a consensus rule change (soft fork, introduction of a new rule) that targets RDTS, so.. Yes, that's what I meant.

1 sat \ 0 replies \ @Murch 17 Jan

Yeah, that’s why I said “fair enough”.

1 sat \ 5 replies \ @optimism 16 Jan

This is why using Voskuil's code, where you can set your own checkpoints, promises Super Fun Times ahead.

101 sats \ 4 replies \ @Murch 16 Jan

Bitcoin Core has invalidateblock which you could use to render your node unable to consider the RDTS chain.

1 sat \ 3 replies \ @optimism 16 Jan

As I understand it, it works differently. But to be honest I only remember sipa's narration so i have to re-review code to actually be sure.

I'll do that tomorrow.

101 sats \ 2 replies \ @Murch 16 Jan

A checkpoint is a commitment to a specific block, invalidateblock rules out a specific block. Is it that what you mean?

However, if RDTS doubles down on their minority chaintip, invalidating the first block of that branch in the chain makes your node consider all descending blocks invalid, too.

1 sat \ 1 reply \ @optimism 16 Jan

However, if RDTS doubles down on their minority chaintip

I think the if is hardcoded to a block height / flag day, so this is not a question of if or even when anymore. It's a question of "what now"?

invalidating the first block of that branch

The one that applies to forking rules, yes.

I just re-read #5316 - must have been 11 years since I read that ugh - and now I think I'm confused about the mechanism. I remember that at one point the consensus was that invalidateblock would tag a block to lose to a competing block of lower weight, but now I am uncertain of where I read that.

101 sats \ 0 replies \ @Murch 16 Jan

No, invalidateblock causes your node to treat the passed block as invalid. Naturally, any blocks succeeding it are therefore also treated as invalid. And IIRC, we ban peers that send us invalid blocks, so you also get rid of your RDTS peers all in one go.

1 sat \ 0 replies \ @nitter 16 Jan

https://twiiit.com/Ragnorosis/status/2012262905027100922