Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

From: Antoine Riard <antoine.riard@gmail•com>
To: "David A. Harding" <dave@dtrt•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest
Date: Wed, 22 Apr 2020 15:03:29 -0400	[thread overview]
Message-ID: <CALZpt+HHJ6rKJK8FBdJ1gznWDsfkUo26rOy=mNLbvMwicv9muQ@mail.gmail.com> (raw)
In-Reply-To: <20200422182454.3y3foxxhiovokovp@ganymede>

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

> 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?

That's an interesting idea, but an attacker can create a local conflict in
your mempool
and then send the preimage tx to make hit recentRejects until next tip so
when the rejection code with conflict is received transaction isn't going
to be fetched.
Of course you can make an exception for this, but seems a DoS vector...

And also if you have a private full-node and connect only to 8 outbounds,
an attacker
can do a bit of tx-relay topology discovery and blind your tx-relay peers
too...

I think p2p/mempool hardening measures will only make attack harder but not
erase it, we
should avoid tie too much the security model of Lightning on a given p2p
topology. If you don't
do manual peering (whitelist,addnode), this one may change without
visibility (like stale tip).

Le mer. 22 avr. 2020 à 14:25, David A. Harding via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

> 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
>

[-- Attachment #2: Type: text/html, Size: 3772 bytes --]