š
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/aa4c89f0/attachment.sig>;
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-09 12:59:39
in reply to nevent1qā¦5xl6
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 12:59:39Event JSON
{
"id": "4ed6fc3299e932c30b019cca67d3962f088bf1137a40dca55f7e11f7d9497a95",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686315579,
"kind": 1,
"tags": [
[
"e",
"f6dc2fa7f1427cf5499629a680568aff2ec65976aee4433534619390a65b0b47",
"",
"root"
],
[
"e",
"125798438d6b9ce4d29c500a9f6bb505a3a1410e01877ff266927ac87ef19af7",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "š
Original date posted:2020-04-22\nš Original message:\nOn Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:\n\u003e A lightning counterparty (C, who received the HTLC from B, who\n\u003e received it from A) today could, if B broadcasts the commitment\n\u003e transaction, spend an HTLC using the preimage with a low-fee,\n\u003e RBF-disabled transaction. After a few blocks, A could claim the HTLC\n\u003e from B via the timeout mechanism, and then after a few days, C could\n\u003e get the HTLC-claiming transaction mined via some out-of-band agreement\n\u003e with a small miner. This leaves B short the HTLC value.\n\nIIUC, the main problem is honest Bob will broadcast a transaction\nwithout realizing it conflicts with a pinned transaction that's already\nin most node's mempools. If Bob knew about the pinned transaction and\ncould get a copy of it, he'd be fine.\n\nIn that case, would it be worth re-implementing something like a BIP61\nreject message but with an extension that returns the txids of any\nconflicts? For example, when Bob connects to a bunch of Bitcoin nodes\nand sends his conflicting transaction, the nodes would reply with\nsomething like \"rejected: code 123: conflicts with txid 0123...cdef\".\nBob could then reply with a a getdata('tx', '0123...cdef') to get the\npinned transaction, parse out its preimage, and resolve the HTLC.\n\nThis approach isn't perfect (if it even makes sense at all---I could be\nmisunderstanding the problem) because one of the problems that caused\nBIP61 to be disabled in Bitcoin Core was its unreliability, but I think\nif Bob had at least one honest peer that had the pinned transaction in\nits mempool and which implemented reject-with-conflicting-txid, Bob\nmight be ok.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/aa4c89f0/attachment.sig\u003e",
"sig": "e76fc91d7090388fb25ebc42e7ae6413a3aa53f6ad98b3a263a83b7b46aa8f4f5c43d2afb25dc668b93c9f910c32dcedbb904c7eaed506b97b92055ea4e42042"
}