summaryrefslogtreecommitdiff
path: root/0b/db929273ebe873e68f604c1ad83c6fc6ef2bf2
blob: 05834161ddcfd9c10d97c2a78a1d5cf3d2e1ca21 (plain)
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
106
107
108
Return-Path: <dave@dtrt.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 038A3C016E;
 Fri, 19 Jun 2020 20:53:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id DFE1888E29;
 Fri, 19 Jun 2020 20:53:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id YUuddqKVlVaj; Fri, 19 Jun 2020 20:53:32 +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 whitealder.osuosl.org (Postfix) with ESMTPS id 4A6BA88DFA;
 Fri, 19 Jun 2020 20:53:32 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
 (envelope-from <dave@dtrt.org>)
 id 1jmO0x-0004fT-Gw; Fri, 19 Jun 2020 16:53:31 -0400
Date: Fri, 19 Jun 2020 16:52:20 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200619205220.fshbr7pbijaerbf2@ganymede>
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
 <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
 <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
 <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
 <CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
 <20200619195846.fclw4ilngvbbf2kk@ganymede>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="ob7sr5hwmygd7js6"
Content-Disposition: inline
In-Reply-To: <20200619195846.fclw4ilngvbbf2kk@ganymede>
User-Agent: NeoMutt/20180716
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-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: Fri, 19 Jun 2020 20:53:34 -0000


--ob7sr5hwmygd7js6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev =
wrote:
> I think you're assuming here that the attacker broadcast a particular
> state. =20

Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer.  The attacker would be broadcasting the latest
state, so the honest counterparty would only need to send one blind
child.  However, the blind child will only be relayed by a Bitcoin peer
if the peer also has the parent transaction (the latest state) and, if
it has the parent transaction, you should be able to just getdata('tx',
$txid) that transaction from the peer without CPFPing anything.  That
will give you the preimage and so you can immediately resolve the HTLC
with the upstream channel.

Revising my conclusion from the previous post:

I think the strongman argument for the attack would be that the attacker
will be able to perform a targeted relay of the low-feerate
preimage-containing transaction to just miners---everyone else on the
network will receive the honest user's higher-feerate expired-timelock
transaction.  Unless the honest user happens to have a connection to a
miner's node, the user will neither be able to CPFP fee bump nor use
getdata to retrieve the preimage.

Sorry for the confusion.

-Dave

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

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

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl7tJYQACgkQ2dtBqWwi
adNYDxAAjEpMvcl6egrIYvc78PnClCsKl6RlmPe+/he0keX/gzkomcBYe+48QI2I
CaRpSCrUIjIzLvCjd81gZqp8XZ56qPT2YNtFPT9UdWpZGSirmy9T/BM/WHYEa1Ca
Ve0w/z3EysCF2fPiAH7k9m9uXPvTMBNhubS7/ypgfr8DbHn+zs/+ZyBMdVY/f4Jh
bj9aYGhK2XpmozNGhdx7Cf+FCMN+vLjWACzE+yk2XTLQdgyBPIusjt4rQhIqByz/
TC9OWdUVIYeDK0e45/Pe4fGt3irK5fOcNhR8RZChQS/N1W/vHJdMfQxi6GqNBQDN
ruAoTd0fGGUI0friLCAj6Wdz54ERvnegb4u5QNVahHpggh4By5jQozc869tKD7Z/
gjLVhMC5esFfXz6dxwprUXrPzmaKg3eV6a3Z0TKr8DWy9lUeKd6/Ijuiv6MNOX8l
LAPUp1kDYW/Ex052WS0B2nreOUpEJ8n++3TnhZhWfmYWE/cgIJfg6iTqYYquYp2e
ns/vIyP/gBluE0ckjsd9khqask5I6GlEUNRBvzIEqIDvKcZ+DEdEcUWmM+JMTBgd
hylm8LtQCla8bv2IZhAcq+qNkBPvEMw2B/oFFCgF8+q3frZPhxV7P76u4VDmDO6W
CqhP7b4slE9yjcBbNjaznJye1nVUODYjPA1bJWeqDL20HkLsjn0=
=iFyQ
-----END PGP SIGNATURE-----

--ob7sr5hwmygd7js6--