📅 Original date posted:2020-04-22 📝 Original message: On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote: > A lightning counterparty (C, who received the HTLC from B, who > received it from A) today could, if B broadcasts the commitment > transaction, spend an HTLC using the preimage with a low-fee, > RBF-disabled transaction. After a few blocks, A could claim the HTLC > from B via the timeout mechanism, and then after a few days, C could > get the HTLC-claiming transaction mined via some out-of-band agreement > with a small miner. This leaves B short the HTLC value. IIUC, the main problem is honest Bob will broadcast a transaction without realizing it conflicts with a pinned transaction that's already in most node's mempools. If Bob knew about the pinned transaction and could get a copy of it, he'd be fine. In that case, would it be worth re-implementing something like a BIP61 reject message but with an extension that returns the txids of any conflicts? For example, when Bob connects to a bunch of Bitcoin nodes and sends his conflicting transaction, the nodes would reply with something like "rejected: code 123: conflicts with txid 0123...cdef". Bob could then reply with a a getdata('tx', '0123...cdef') to get the pinned transaction, parse out its preimage, and resolve the HTLC. This approach isn't perfect (if it even makes sense at all---I could be misunderstanding the problem) because one of the problems that caused BIP61 to be disabled in Bitcoin Core was its unreliability, but I think if Bob had at least one honest peer that had the pinned transaction in its mempool and which implemented reject-with-conflicting-txid, Bob might be ok. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/aa4c89f0/attachment.sig>