pull down to refresh

1577 sats \ 2 replies \ @petertodd 17 Nov 2023 freebie \ on: How I (probably) lost 5M bitcoin
Unfortunately I decided to open with too low fees and the channel opening was stuck in the mempool. Instead of just wait and drink tee, I decided to bump the fee which was a very bad idea.
FYI the reason why this is a bad idea is because a Lightning channel is two transactions from the very start:
  1. The transaction funding the channel
  2. The commitment transaction that closes the channel if one of the parties goes offline.
If you fee-bump the funding transaction, the txid changes, and the commitment transaction is no longer valid. The Lightning protocol isn't designed to deal with this situation.
Lightning node implementations could have made this easy, by letting you fee bump by opening a new channel with a higher fee, and then figuring out which channel to actually use when one of the txs finally confirms. Or at the very least, by letting you easily broadcast a cancel tx with RBF. But unfortunately LND doesn't support this even though lots of users have lost money like you.
SIGHASH_ANYPREVOUT could have fixed this too, as with it the commitment transaction wouldn't have needed to sign a specific funding tx. But sadly that was held back years ago out of silly concerns that people would lose money misusing it manually; there's so many ways to lose money misusing Bitcoin!
write
preview
10 sats \ 0 replies \ @Lumor 17 Nov 2023
The channel opening protocol should support RBF:ing and updating the txid (or not telling the other side what the txid is until one confirmation). We already have the waiting for confirmations before completing the opening process.
reply
0 sats \ 0 replies \ @megaptera OP 17 Nov 2023
Thanks for your explanation.
I could have bumped the fee with a new transaction that paid for the child (Child-Pays-For-Parent (CPFP)). That would have worked perfectly fine...
reply