Hmm, that's an interesting suggestion, it definitely raises the bar for attack
execution rather significantly. Because lightning (and other second-layer
systems) already relies heavily on uncensored access to blockchain data, its
reasonable to extend the "if you don't have enough blocks, aggressively query
various sources to find new blocks, or, really just do it always" solution to
"also send relevant transactions while we're at it".
Sadly, unlike for block data, there is no consensus mechanism for nodes to
ensure the transactions in their mempools are the same as others. Thus, if you
focus on sending the pinning transaction to miner nodes directly (which isn't
trivial, but also not nearly as hard as it sounds), you could still pull off
the attack. However, to do it now, you'd need to
wait for your counterparty to broadcast the corresponding timeout transaction
(once it is confirmable, and can thus get into mempools), turning the whole
thing into a mempool-acceptance race. Luckily there isn’t much cost to
*trying*, though it’s less likely you’ll succeed.
There are also practical design issues - if you’re claiming multiple HTLC
output in a single transaction the node would need to provide reject messages
for each input which is conflicted, something which we’d need to think hard
about the DoS implications of.
In any case, while it’s definitely better than nothing, it’s unclear if it’s
really the kind of thing I’d want to rely on for my own funds.
Matt
> On 4/22/20 2:24 PM, David A. Harding wrote:
>> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
