pull down to refresh

105 sats \ 3 replies \ @k00b 7 Jul \ on: On the Lack of Replay Protection bitcoin bitcoin_beginners
A split would only be reliably once the conflicting transactions have multiple confirmations on the respective chaintips.

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.

write
compose
117 sats \ 2 replies \ @k00b 7 Jul

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.

reply
209 sats \ 1 reply \ @Murch OP 7 Jul

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!

reply
127 sats \ 0 replies \ @Murch OP 7 Jul

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.

reply