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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
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 8E140C0175;
Thu, 23 Apr 2020 10:01:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 82B41227A3;
Thu, 23 Apr 2020 10:01:34 +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 OpoMSHZ6mmEN; Thu, 23 Apr 2020 10:01:33 +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 4B5432279B;
Thu, 23 Apr 2020 10:01:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1jRYfj-0002eB-In; Thu, 23 Apr 2020 06:01:31 -0400
Date: Thu, 23 Apr 2020 05:59:57 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <20200423095957.ocetcjhevwlonwya@ganymede>
References: <52DA8104-3E4E-450F-92A4-3970D1A31281@mattcorallo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="adu532lhloearf4f"
Content-Disposition: inline
In-Reply-To: <52DA8104-3E4E-450F-92A4-3970D1A31281@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: Thu, 23 Apr 2020 10:01:34 -0000
--adu532lhloearf4f
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote:
> 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.=20
If the problem is that miners might have information not available to
the network in general, you could just bribe them for that knowledge.
E.g. as Bob's refund deadline approaches and he begins to suspect that
mempool shenanigans are preventing his refund transaction from
confirming, he takes a confirmed P2WPKH UTXO he's been saving for use in
CPFP fee bumps and spends part of its value (say 1 mBTC) to the
following scriptPubKey[1],
OP_SHA256 <hash_whose_preimage_bob_wants> OP_EQUAL
Assuming the feerate and the bribe amount are reasonable, any miner who
knows the preimage is incentivized to include Bob's transaction and a
child transation spending from it in their next block. That child
transaction will include the preimage, which Bob will see when he
processes the block.
If any non-miner knows the preimage, they can also create that child
transaction. The non-miner probably can't profit from this---miners can
just rewrite the child transaction to pay themselves since there's no
key-based security---but the non-miner can at least pat themselves on
the back for being a good Summaritan. Again Bob will learn the preimage
once the child transaction is included in a block, or earlier if his
wallet is monitoring for relays of spends from his parent transaction.
Moreover, Bob can first create a bribe via LN and, in that case, things
are even better. As Bob's deadline approaches, he uses one of his
still-working channels to send a bunch of max-length (20 hops?) probes
that reuse the earlier HTLC's <hash>. If any hop along the path knows
the preimage, they can immediately claim the probe amount (and any
routing fees that were allocated to subsequent hops). This not only
gives smaller miners with LN nodes an equal chance of claiming the
probe-bribe as larger miners, but it also allows non-miners to profit
=66rom learning the preimage from miners.
That last part is useful because even if, as in your example, the
adversary is able to send one version of the transaction just to miners
(with the preimage) and another conflicting version to all relay nodes
(without the preimage), miners will naturally attempt to relay the
preimage version of the transaction to other users; if some of those
users run modified nodes that write all 32-byte witness data blobs to a
database---even if the transaction is ultimately rejected as a
conflict---then targetted relay to miners may not be effective at
preventing Bob from learning the preimage.
Obviously all of the above requires people run additional software to
keep track of potential preimages[2] and then compare them to hash
candidates, plus it requires additional complexity in LN clients, so I
can easily understand why it might be less desirable than the protocol
changes under discussion in other parts of this thread. Still, with
lots of effort already being put into watchtowers and other
enforcement-assistance services, I wonder if this problem can be largely
addressed in the same general way.
-Dave
[1] Requires a change to standard relay and mining policy.
[2] Pretty easy, e.g.
bitcoin-cli getrawmempool \
| jq -r .[] \
| while read txid ; do
bitcoin-cli getrawtransaction $txid true | jq .vout[].scriptPubKey.asm
done \
| grep -o '\<[0-9a-f]\{64\}\>'
--adu532lhloearf4f
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl6hZx0ACgkQ2dtBqWwi
adP3hg//bZ9qTpDTEgeDX9XkkOBcBwQfNlPOqm8sHTgA/+agSbc3Vdkc5P79IzAF
cWUlgzG5IsGHLX9v8A7uIj5p4dI1603mg4O77uy8gqn51r98dDkNTLdYLSZ60dzG
/6T21GaMhhqVneoIcpNmDp4RgQw+VH6SSu4a7oFHjkv79KSUVZMk3syN+ijmUtcg
mSbPg6jpdULC3uSyEqma/H3nb0VOwB/tTwXRXRer9mRUE9gdB/kpqimoTNjElPUp
Sah7hB9MKykwJ3EYhMz0m8b2O6Q3TYW5yls/JXtSgBkRLZgZ4IwDxOufeK9k+sM0
SmKwRS+kqcUaeBvgR3hJPscfDDUbXM8l7z2I7v0yFH7sujICsbD+YiGvJrKl75bB
E4/DHZjc7TsGpMnr8d4K3GILYm82GgybenzpdMn1bAc7Ap0rsxJLG4WEJTVIp1fO
7mAoUoMKGZ07Ce9tOuVYPYJiCRO59uG/GNhu6T3LfvrYPMud0yMODfksY+5kMCiD
/JJ19ShnBnFUIijdWISU6cr0Z2OhxwpX3/dRRBLHYZOJQ6bf9NvkLrH+NXDYdQR7
mcEIf6BY0kCo00Yb7T/xIS7pS9H6NzSvJIVKRzjqyj5lwPt6DrahnCsPKecarY48
tuDJVG0/3aHN1t5Nc9hFnU+ILyJh1EIK1qsKtcP8xiLs59Iwgtk=
=xmuc
-----END PGP SIGNATURE-----
--adu532lhloearf4f--
|
