I hadn’t blogged in a while, but today I hammered together a few thoughts on BIP110’s lack of replay protection.
pull down to refresh
pull down to refresh
I hadn’t blogged in a while, but today I hammered together a few thoughts on BIP110’s lack of replay protection.
from their perspective, it's a feature, not a bug.
Lack of replay protection means there's potential risk of a wipeout on the Core v30+ side of the split. Should the BIP 110 side ever achieve the point it becomes the side with the "greatest work", Core v30+ nodes risk seeing a reorg and then have the same chain and chain tip as the BIP 110 side (and thus all mined coins on the Core v30+ side disappear, and any transactions using those mined coins become invalid).
Though if that were about to happen, I would presume miners and pools would use invalidateblock to blacklist the BIP 110 side (if total work on the BIP 110 side were to approach attaining greatest work), at least until Core did a release in response, with that protection hard-coded, or whatever other wipeout protection they'ld implement.
Why would BIP110 opponents wait that long? With the current hashrate distribution and RDTS having ≤ 1% of the hashrate, the Bitcoin chaintip will find scores of blocks before RDTS finds a single one. As you say, all the blocks mined on the Bitcoin chaintip would be at risk of being reorged if RDTS ever pulled ahead. It seems obvious that a reorg of 100 block depth would be unacceptable to the network. The reasonable thing would be to nip it in the bud immediately. So, people that don’t support BIP110 should run
invalidateblockon the first RDTS block once the Bitcoin chaintip has progressed 100 blocks from the mandatory signaling height. Since RDTS will be way behind at that time, people can run it safely at different times and it would work fine regardless (although I expect it to be completely unnecessary in the first place).100 blocks is a good finish line
I very much doubt invalidateblock would be used successfully as a way to reject a heavier BIP110 chain.
The coordination problem and reaction time is a huge issue there, coupled with this being a violation of nakamoto consensus narrative.
What other options are there? Bring checkpoints back? Keep head in the sand and pray?
Let it play out. whether 110 activates or not on the majority chain, it's probably gonna be fine eithe way.
It’s just unaligned perspectives. 110ers still think that their fork will be Bitcoin, everyone else is watching a forkcoin spin out.
maybe, depends on your perspective. there is a chance yours happens, also a chance it doesn't. we'll find out.
Yeah, can’t wait.
I assume youve put sats on the line? https://beta.predyx.com/market/will-bip-110-activate-and-be-enforced-on-bitcoin-by-sept-1-2026-1770282509?ref=PREDYXTZ0UUNOP
Easiest, nontechnical way of doing this?
Probably the one I described in the blog post: make a low-feerate self-send on the Bitcoin chaintip, then spend the same UTXO to a different output on the RDTS chaintip.
"Relegated" is a very nice term here. I hear Premier League relegation and it is an interesting way to think about chain splits.
Replay Protection would turn it into a hard fork.
How should we call an irreconcilable difference between two clients where one version rejects blocks made by the other, regardless of adoption? Asking because I'd call that a hard fork, but maybe I'm using the wrong word.
A soft fork is backward-compatible, a hard fork isn't.
https://en.bitcoin.it/wiki/Hardfork
https://en.bitcoin.it/wiki/Softfork
Alright, so what do we call the state of having 2 chain tips where the UASF side is a persistent minority chain? Because that scenario isn't covered in this terminology. Bitcoin Unlimited retroactively decided to do the equivalent of
lot=trueafter their MASF failed, which is the closest comparison we have here, except now it is coded in. (iirc we called the BU decision a hard fork, but whatevs)So, if the majority of all economic actors is going to enforce the UASF, to which we have no indication with just a few weeks left, fine. But what will we end up with if that too[1] fails? It's not a softfork if I need to run a second client to see the minority chaintip.
assuming that with 0.77% signal for bit 4, the MASF component will fail. ↩
I'd call it a permanent chain-split caused by a soft fork with minority hashrate support. The Bitcoin rules would be the hard fork to RDTS, but RDTS changed the rules in a compatible manner and Bitcoin didn't, so calling it a hard fork would be weird.
Hard/soft fork refers to the type of rule change. Chain split describes the outcome.
I wrote as much a long while about it, so that distinction seems to be quite old: https://bitcoin.stackexchange.com/a/30821
Thanks, that makes sense.
I think you mean "reliable".Edit: you already fixed it.
Thank you for writing this. It's hard enough to think about what happens when there's one bitcoin let alone several.
I suspect the primary risk on lightning is that a channel partner force closes on RDTS (perhaps by direct submission to RDTS miners) and its congestion/fees prevent the penalty from being mined/worth submitting to miners. I don't imagine there's a way to protect against that either.
I was thinking that RDTS nodes would not see a unilateral channel closure with a normal feerate as it would only be in the Bitcoin chaintip and not in their chaintip’s blocks and thereby fail to react to it.
If a channel partner closed a channel with enough feerate to be visible in the RDTS chaintip, it would definitely also close on the Bitcoin chaintip. You raise an interesting point there, though, that the defender would then overpay for the Bitcoin network and lose a lot of bitcoin unnecessarily.
Thanks for the typo fix!
To elaborate, if RDTS were to have about one block per day while Bitcoin continues to have ~140+, the relative time lock might expire on Bitcoin before they even see the closing txs on RDTS even in the mempool.
I had not heard of this conflicting fee method for splitting coins before, very smart. I'll do that after the chain split and merge the coins into Wasabi's coinjoin pool so other people can passively inherit replay protection.
Thanks, to my knowledge, I might have proposed it for the first time in this context of RDTS.
graci senor
Great article about replay protection. This is an important topic for Bitcoin security - understanding why replay protection matters is crucial for anyone running a node or using Bitcoin in production environments.