1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
Return-Path: <dave@dtrt.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E4162C0175;
Wed, 22 Apr 2020 18:25:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id DCF67204A0;
Wed, 22 Apr 2020 18:25:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TZ3rUZv8oUsb; Wed, 22 Apr 2020 18:25:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by silver.osuosl.org (Postfix) with ESMTPS id 22E6920438;
Wed, 22 Apr 2020 18:25:35 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1jRK3v-0004gW-T7; Wed, 22 Apr 2020 14:25:31 -0400
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2020 18:25:37 -0000
--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--
|
