Date: Wed, 22 Apr 2020 14:24:54 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <20200422182454.3y3foxxhiovokovp@ganymede>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="hri62yla7f2etgkz"
Content-Disposition: inline
In-Reply-To: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
User-Agent: NeoMutt/20180716
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing
	Interest
Precedence: list


--hri62yla7f2etgkz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--hri62yla7f2etgkz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl6gi/YACgkQ2dtBqWwi
adOvUQ/9EgDa7RVIjNhX/NGa4FiAmV+DQbG0FQXoafFPQmPp1ZW6/FITH1yqZtot
n+LsaVaN3Xq8CWFS9M/Hh66ryqdcf+QHxxAk1o1AO7I1zIMK5k+sMen2inPynCZW
FzHduDYW2IUUpAWKYPEx6AG8J+luRp9M2ccm0AjiNNADX7ZU6z9CLc0MoCMLTD3U
2b2Xxx5PWIetMHSjBunk8LNo8nBcCecqg3svZsjOdcGxVmhyPAIlswLVFiTArydB
hqueJdSyMmbFHQGUMINbgEXKOiibU/sgYOxc1Q3xr1D9cmO7BqbkfwRxwRBtzCzD
6VfiLkwcMr0D18ci5WwY/xqPRqJX2xsbmZFRgXlLpGGnFQiHNS/FmiJyszhWvN8x
RucX0LmiKIK5m/AzjwtI+Crf9e4PGXKCsCPsuv2z8iYAZ65qidgrFWnpS/+moWbz
f7qhZsnA757wR3K1PtjMgRl6C3AJJlu1Gb82svw2/l1HL7/LBaVMMn7Hwznrk1iq
iCtk/xoMKDDWx169Eu5Va7mXg1yDeRjK/5q/UKEp2eAQP9mrHIuOK9SGxz9v4nWn
sr9Fsm+MVXcCTFE14jfVZL8F0A/A44aKFMRAIYH1p7pXOisagGj0m8CtqlAXB4nA
iuaos90C9QsyeobC4IYqtj7qFpUxEuHcTiEqY61emcCs6m+o+m8=
=tXJQ
-----END PGP SIGNATURE-----

--hri62yla7f2etgkz--