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
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Return-Path: <dave@dtrt.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 89568C016E;
Sat, 20 Jun 2020 10:37:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 7F13988A16;
Sat, 20 Jun 2020 10:37:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Jzqx1xbXwZFM; Sat, 20 Jun 2020 10:37: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 hemlock.osuosl.org (Postfix) with ESMTPS id 97FE688311;
Sat, 20 Jun 2020 10:37:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1jmasO-0008CF-1B; Sat, 20 Jun 2020 06:37:32 -0400
Date: Sat, 20 Jun 2020 06:36:47 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Bastien TEINTURIER <bastien@acinq.fr>
Message-ID: <20200620103647.g62srlcxbjqpaqj6@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>
<20200619205220.fshbr7pbijaerbf2@ganymede>
<CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="y6hxb2jbwe7kza6u"
Content-Disposition: inline
In-Reply-To: <CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.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] [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: Sat, 20 Jun 2020 10:37:36 -0000
--y6hxb2jbwe7kza6u
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> We're simply missing information, so it looks like the only good
> solution is to avoid being in that situation by having a foot in
> miners' mempools.
The problem I have with that approach is that the incentive is to
connect to the highest hashrate pools and ignore the long tail of
smaller pools and solo miners. If miners realize people are doing this,
they may begin to charge for information about their mempool and the
largest miners will likely be able to charge more money per hashrate
than smaller miners, creating a centralization force by increasing
existing economies of scale.
Worse, information about a node's mempool is partly trusted. A node can
easily prove what transactions it has, but it can't prove that it
doesn't have a certain transaction. This implies incumbent pools with a
long record of trustworthy behavior may be able to charge more per
hashrate than a newer pools, creating a reputation-based centralizing
force that pushes individual miners towards well-established pools.
This is one reason I suggested using independent pay-to-preimage
transactions[1]. Anyone who knows the preimage can mine the
transaction, so it doesn't provide reputational advantage or direct
economies of scale---pay-to-preimage is incentive equivalent to paying
normal onchain transaction fees. There is an indirect economy of
scale---attackers are most likely to send the low-feerate
preimage-containing transaction to just the largest pools, so small
miners are unlikely to learn the preimage and thus unlikely to be able
to claim the payment. However, if the defense is effective, the attack
should rarely happen and so this should not have a significant effect on
mining profitability---unlike monitoring miner mempools which would have
to be done continuously and forever.
ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
hoping one of Bitcoin's several inventive cryptographers would come
along and describe how someone with an adaptor signature could use that
information to create a pubkey that could be put into a transaction with
a second output that OP_RETURN included the serialized adaptor
signature. The pubkey would be designed to be spendable by anyone with
the final signature in a way that revealed the hidden value to the
pubkey's creator, allowing them to resolve the PTLC. But if that's
fundamentally not possible, I think we could advocate for making
pay-to-revealed-adaptor-signature possible using something like
OP_CHECKSIGFROMSTACK.[3]
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
[2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html
[3] https://bitcoinops.org/en/topics/op_checksigfromstack/
> Do you think it's unreasonable to expect at least some LN nodes to
> also invest in running nodes in mining pools, ensuring that they learn
> about attackers' txs and can potentially share discovered preimages
> with the network off-chain (by gossiping preimages found in the
> mempool over LN)?
Ignoring my concerns about mining centralization and from the
perspective of just the Lightning Network, that doesn't sound
unreasonable to me. But from the perspective of a single LN node, it
might make more sense to get the information and *not* share it,
increasing your security and allowing you to charge lower routing fees
compared to your competitors. This effect would only be enhanced if
miners charged for their mempool contents (indeed, to maximize their
revenue, miners might require that their mempool subscribers don't share
the information---which they could trivially enforce by occasionally
sending subscribers a preimage specific to the subscriber and seeing if
it propagated to the public network).
> I think that these recent attacks show that we need (at least some)
> off-chain nodes to be somewhat heavily invested in on-chain operations
> (layers can't be fully decoupled with the current security assumptions
> - maybe Eltoo will help change that in the future?).
I don't see how eltoo helps. Eltoo helps ensure you reach the final
channel state, but this problem involves an abuse of that final state.
-Dave
--y6hxb2jbwe7kza6u
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl7t5r8ACgkQ2dtBqWwi
adPGDBAAw7ifc0/Q4yofIRUu8tuKxajCrwAVdQRXepZ/HG3qY1hfHoOH5Xvq165j
snPCEdxKvdRCqXaH87ZeQ3G+ALgXZEe/d8HI9c2YXy9AHH695DEcYeGRkFOBn66V
TlkKYUUsBwsosOYRtJUrN2D3xVmWICOwBJrwlNOIgT79P4GG4QdpnhuQt9xzlAST
V1n0zU8dD/v2mgK9fAwmNaq8BPD/a15Jcset+jYKPe5qGCkP2M29zL/kbs4v6LrN
xQY5av7W8nplsT2W59dBpviOzrm0OCCA09xrZkmc2esnM1bq93s4FzxcFzRF+iVJ
ejQ4lKFsZUPFAPX/aR/sN/6s/WIsBegsmwCxx+QsvPHaV4q5zoape8RE3unYJmdv
N0/gRl4ea3Tj6ACoEF/i+wA0icxjSRkWKSt9I2y/K/2iyLeRNXPFTwzyBLpBLnke
QtMH5PzAW+t7YnNSCiOk1P/nvMGnLK6pYuAQGvMJShZWZKaRX1D4blBU2T3rpHow
OmIHt5GWFVSdgFHxvtj/y6qfcIMnBWV6Z4xOOTjdkJBcsrtZBibyG1+EnlsPeKLL
tLU1N4sM3670USv3LmjEsXNAuK9A5mWR160YKJsfFQvYIfSIuuwV0OGwaGNyqS7a
tQa2eF2voI7b0dRGO4ThhAOegbPwqaymwdjszNnxwd0mYZA14X8=
=gnsX
-----END PGP SIGNATURE-----
--y6hxb2jbwe7kza6u--
|
