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
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
|
Delivery-date: Mon, 22 Jul 2024 08:15:18 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDRYHVHZTUGRB7XO7G2AMGQEZARND7I@googlegroups.com>)
id 1sVukw-0003VC-99
for bitcoindev@gnusha.org; Mon, 22 Jul 2024 08:15:18 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e02b7adfb95sf9601626276.2
for <bitcoindev@gnusha.org>; Mon, 22 Jul 2024 08:15:18 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1721661312; cv=pass;
d=google.com; s=arc-20160816;
b=xPHrnO61NNAOBEh6tBxoUK7inljoXyWAYc42mYLu+Ol0OqUSmgeELNfYt5qfk+adiI
zOaijh+hshSKswYwzX+ijDXAP8yXWka2vTJIhb7PVfetw1TVGmI0rVj1vzYtgW2ICZiu
+oijEC95BUsJxbk7hFFlU5rBvs7pSQ5jvLWfK3p7G6zwZwTVECo/dm5Nto/uBQZ8kfl4
tBSHvwz7kT2ZAZQd9I+gb28e7dZ3F+UOzUgHuYLqh+3zXHb9NdnNLa+P3V/O30OMydtE
IDZcoQyDkfT3aq1043w64jJRH2kdtvGO/997Q6D5bevr3/JTmn6NeMZEmwfYkYLsCkYb
CRhA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:in-reply-to:content-disposition
:mime-version:references:message-id:subject:cc:to:from:date
:feedback-id:sender:dkim-signature;
bh=clHsuw1B9nqyiSxvfBCcokbuMTi3WzWs7AdUu9JcxGw=;
fh=mbMYo5Cnh4ohLb95LymW8U4HLJ4ctZO+2eaLLshizYA=;
b=lQu6hYmjAdmM+rNz33eZlMAtphNzNPF3LpSjOUOSkCiwJ9jbl3/0pKLFP2ZRcBY9KD
m8bB0c7pzCdXdezgxD9L7zzWkpTqi/0BOU6EUPMvzZiWbPUzxMBecPe/s78ZVDU2dkya
RBzksC8BC9ovk69IZ+KFy7yKOgiiGuCswgvV1FzT8JKKJX3tqecWCzgDamSAgMHD+lOb
N4+96+mYYZcTPE04YcDlpKmP/NYhs4FrBa29bjTLVYg04HVs9uDi98gQWjRp4R64eKBh
4paajqoErOnN+mVObE4SkuOqY6PeVFgndBa2qEcWYMoKgxUnDVT0OL1Ad5hAR2xBFmcq
kHEw==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@messagingengine.com header.s=fm3 header.b="T/gPJrY1";
spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1721661312; x=1722266112; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:feedback-id:sender
:from:to:cc:subject:date:message-id:reply-to;
bh=clHsuw1B9nqyiSxvfBCcokbuMTi3WzWs7AdUu9JcxGw=;
b=XGc/WV3mE2EROjOFSryH0O/MGiQS4ucvz0grSy7ZrlIZVkoq/bQy/FQ1v1ISQWEvdE
gchuiPt6wk4hulbpJoIwSJK3Vc9kzmaXyczKgZeKQeDdtmdPz/IxLf/z43RUd1e7s1Aq
G8JvfKqUuBlL6NN5Wa4h0WvAmkrfVAmLewte0eY0wg/eJovS5/HBAxGITUhp+mTdNZgZ
cZztO/8e9hqjOj/IHQl0lKhrSXYOL1Nnrsl0zyHJpM1boJslIOck3ho0tcDUPWoE5XoS
VnJS8of1M82OVfcJiFEY+qABC13szwK19dp6T3I1tuVnlru5OkZ9wBK3HX/mdRz4r0kd
OCBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1721661312; x=1722266112;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:feedback-id
:x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=clHsuw1B9nqyiSxvfBCcokbuMTi3WzWs7AdUu9JcxGw=;
b=DP88nE+n3iBJV3xebWckObkDR87xzzA5qMtkoLBOR1LAFHxmLT/NMTByFQRuP/EON2
QrjH5Jv/9eY+bJwE+kjBLWHMMYbaLeODyNvmFv7ph4KBVxDeRw94vyaSsgRXQOKj5Q/t
WWL/x26IekZqgFcqmMpre99fJVHeU7yVF5yNeoleU3r2Rg0rZXyso9Zqw0HZiaYHaZk/
ml1lQHRHwzNGX7Wkqj7y6ADizQpibMjEZFZ71ouUz5e64hkmxNtvUfNFEgOw4WkcW9W3
WP9TQauTnBAUwr0xjEYg5D/JR4H8VdK5ntm2jMiDUBpaax33QiYC1h483meZVK56RPmJ
MpNQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVF2CbSKKguF/XiMbxUA6RTal4ryfUBGQxwcZhVWf2wDfPkml4I8RBas0CINEl1sNTJBIGKGvqU3dvCx3mFQB8+uY0yZ1E=
X-Gm-Message-State: AOJu0YzQYVyTiCPldfFHl3VwgSPLDOSE1sVIk7Xv8vT3kQwMYdvm+1B1
Jh1nFhxNcvLUne7Go3DCHn1gRl7AC8jpds/sUVzEuBZ28qiAMFpt
X-Google-Smtp-Source: AGHT+IEs5R94j7HBvrbZYJfbelo7jaPqCY6bRRuDCZIVYLfyr6XnwIHQPHe4CzNCJHnV39Dn5CukZg==
X-Received: by 2002:a05:6902:e01:b0:e08:6105:aca4 with SMTP id 3f1490d57ef6-e086fe55edemr9532690276.12.1721661311978;
Mon, 22 Jul 2024 08:15:11 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:2e52:0:b0:e05:a1df:563f with SMTP id 3f1490d57ef6-e05fd8e155cls7611708276.0.-pod-prod-05-us;
Mon, 22 Jul 2024 08:15:10 -0700 (PDT)
X-Received: by 2002:a05:690c:6603:b0:66b:fb2f:1b7 with SMTP id 00721157ae682-66bfb2f0af5mr5279767b3.6.1721661310020;
Mon, 22 Jul 2024 08:15:10 -0700 (PDT)
Received: by 2002:a05:690c:26c7:b0:627:7f59:2eee with SMTP id 00721157ae682-6691747e85ems7b3;
Mon, 22 Jul 2024 08:10:25 -0700 (PDT)
X-Received: by 2002:a05:690c:397:b0:665:54fa:5abf with SMTP id 00721157ae682-66a66643fb8mr94262467b3.2.1721661024517;
Mon, 22 Jul 2024 08:10:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1721661024; cv=none;
d=google.com; s=arc-20160816;
b=qgSzkCc0KfyVQl568CBi0a60O27fPmVPqOHuglGjrCVmxidHYhY/d7jzOaulk7mxIG
t46zgQFZeZdVwFl60nvXBhbJwpb2haNkSUFBQXe7S1wWN/YGND7bWdsvCXVkRD/zDYgq
jYHuYmETRCJHpArFm9/W4xAkQLN+RFy2YvVdUJb4Se8h0AFCJZyak1pH/fi/InHQZtFQ
DVg4TLLDiLJwrM9UhMnx9Wx0htek1UPkV82Ina9n5fnz0fGhtBYKshl3VvkjfZb8eWft
FDI30b5SBvDy5Q5KBiarLFkS7OiwbjgI7QPVqh417xfvo0SP9SB2v+wCNyy5E6nHZt5Q
MF1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:feedback-id:dkim-signature;
bh=/HCbs9Q7S9SnX9/ra1mFuFE6RhlOcasbJwMUL34Tq/M=;
fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=;
b=NGf2nHhfuOyzkgb//QwL79Rr26EdSG6jAlMoEUG+7pT99s86CofW5eymvcOlfUVOcF
tAFmenaBqf8JKE4F72kJkR9Pv1/rihUXX+G81Knx0R2eK77GhollLmwj/P78IB64RS6m
KODa8xWGK9R2n01D0sQI5YlhZvp5GvRaM0DG494pFBIK1G10N0p7VniP+g+PpaH6Bkaw
4thIRnUTGggo07S15lr+sQ+0uOyW9DUVyJ/QUsB6pldt8dxZTvXgK09ZGG3b6EG9XqwJ
WotBlq9BCB8zXddjhpcS8+WMRGHAl2w1+cf1/xVo9fvswih/XE1Nk4Ysl0V0OBBUPsOf
ZT0w==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@messagingengine.com header.s=fm3 header.b="T/gPJrY1";
spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fhigh7-smtp.messagingengine.com (fhigh7-smtp.messagingengine.com. [103.168.172.158])
by gmr-mx.google.com with ESMTPS id 00721157ae682-6694efc9f4fsi2267207b3.0.2024.07.22.08.10.24
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 22 Jul 2024 08:10:24 -0700 (PDT)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) client-ip=103.168.172.158;
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailfhigh.nyi.internal (Postfix) with ESMTP id E8A7E1140176;
Mon, 22 Jul 2024 11:10:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute4.internal (MEProxy); Mon, 22 Jul 2024 11:10:23 -0400
X-ME-Sender: <xms:X3aeZvGiUYuDcF4b0nRYoT2sqaEGE9baDnY3Zk9aGFVFOBRcMXdClg>
<xme:X3aeZsUCSSaV-zXNYjmNctrfUJ9nzT6WIOLGp0ePm6k35HKzYOOlMn8kL9xiKj8Rn
PHhYkTjDe8-6I7mneA>
X-ME-Received: <xmr:X3aeZhKEj0ABqT70dYEVXFaQEWZZpcy59MPy1HrtvlmNBD_a-7zRGbfFRG1EwSeDmFDGG5R_z4M8qT7ayQuJpkUhceI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrheejgdekiecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr
ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
hrnheptddtgedtffetueekfffhffekkeeihfetuddvteejueejffegveeghfduteejhfev
necuffhomhgrihhnpehgihhthhhusgdrtghomhdpphgvthgvrhhtohguugdrohhrghenuc
evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvges
phgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:X3aeZtHTPg9IPDGBh6JbrjVROqexmH7ga8qrxK6rrwfuo9xBBiejJA>
<xmx:X3aeZlW6_a6MD-RbLEmTz8Id4cYsSGk-58ATc9-XhC8s2d6UCTQFjw>
<xmx:X3aeZoNQs3TGl_8F0RwMs7NDEe4I9Hbkuo0SLzQysw1KZHrSnFAH6w>
<xmx:X3aeZk2LEBA-vd4vjr_Lojj9ItP1W2Bwra0atanyn9V8BEjsjwXxPA>
<xmx:X3aeZjfMb_4dDTKDJuN2KNJ5hNMhd3cIPxabNZg7lUWwSkHsNsJbBarO>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
22 Jul 2024 11:10:22 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
id 510395F83F; Mon, 22 Jul 2024 15:10:16 +0000 (UTC)
Date: Mon, 22 Jul 2024 15:10:16 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
of Full-RBF In Core
Message-ID: <Zp52WDL4hV16CbKV@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
<c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
<99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="wJF0WFIB45ivDp/7"
Content-Disposition: inline
In-Reply-To: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@messagingengine.com header.s=fm3 header.b="T/gPJrY1";
spf=pass (google.com: domain of pete@petertodd.org designates
103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
--wJF0WFIB45ivDp/7
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
>
> Hi Dave,
>
> Thanks for your thoughtful answer (even if its wasn't addressed to me
> primarly).
>
> > I cannot imagine what would make you think that protocol developers are
> > not concerned about attacks that could drive large numbers of relay
> > nodes off the network for a cost easily affordable to any well-funded
> > adversary.
>
> From my experience code reviewing the wallet / mempool re-broadcast of few
> years ago, free tx-relay / bandwidth waste attacks were far to be
> understood
> or plainly weighted by some contributors of a newer generations, including
> by
> the own champion of the proposal. The proposal was finally abandonned when a
> more senior dev came up with quantitative analysis of code changes [0].
>
> [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105
An irony here is that rebroadcasting makes most "free" relay attacks *more*
expensive, not less. sdaftuar had some correct points, like avoiding bandwidth
spikes. But for any "free" relay attack based on broadcasting conflicting
transactions at different fee-rates, where the higher fee-rate transaction is
not mined, you get a better attack if the higher fee-rate transaction falls out
of node mempools, allowing the lower fee-rate conflict to be broadcast again.
If rebroadcasters ensure that nodes have the higher fee-rate tx, all you can do
to "reset" the attack is either get your UTXO(s) mined. Or use an even higher
fee-rate. Without rebroadcasting, you can wait for the expiry period to be
reached.
> > In this case, you've found a specific instance (full-RBF vs signaled
> > RBF) of a well-known general problem (optional policies leading to
> > mempool inconsistencies, allowing free relay) and appear to be arguing
> > that devs don't care about free relay because they refused to reverse a
> > previous decision (to not change the RBF configuration default) that has
> > been hotly debated multiple times.
>
> I think what is more interesting and noteworhty in the whole line of
> reaosning
> of Peter with the present disclosure is how much the adversial effect is
> favor
> by the supermajority of miners running `mempoolfullrbf` [1].
>
> [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316
Not just miners: any node running with mempoolfullrbf=1 is going to waste less
bandwidth if someone actually does this attack.
> Under those conditions, where it took 9 years for the bitcoin core project
> to disclosre
> some vulnerabilitires, personally I'm more likely to understand that the
> bitcoin core project
> is under-staffed is competent experts to keep public disclosure in
> reasonable timeframe (-- at
> least equivalent to the kernel world), and as corollorary to fully evaluate
> technical proposal
> with all its strength and weaknesses.
>
> Saying an "already overdiscussed issues that gets nobody closer to
> fundamental solutions" is
> insulting for Peter, honestly.
Indeed. You'd think solid evidence, trivially verifiable by anyone, that almost
all miners had adopted full-rbf would be enough. Instead that evidence doesn't
even receive any acknowledgement.
> As an offchain protocol developers which has been involved in the majority
> of technical conversations,
> implementations and deployment of the "anchor output" upgrade, I believe on
> the long-term CPFP-style fee-bumping
> of contract protocol, including lighting, is not the most robust technical
> solutions. I think anyone can check
> in the bitcoin optech anchor output glossary the numerous vulnerabilities
> that have plagued this fee-bumping
> solutions over the past years.
RBF is way underused in protocols in general. And there have probably been
literally millions of dollars wasted on fees spent by inefficient CPFP
solutions when RBF (via pre-signed transactions) could have been used instead.
This financial figure will only get higher as Lightning gets more adoption. It
also limits Lightning in mass failure scenarios: every byte saved while force
closing a channel is room that could be used to force close another channel.
> I already reviewed some parts of cluster mempool. Fundamentally, economical
> mempool pinnings for second-layers (bip125 absolute
> fee) with pre-signed time-sensitive transactions arises from a world where
> there is (a) an asynchronicity of mempools and (b) one
> cannot guess feerates at block + 1 (-- let's say in a deterministic fashion
> as understood by traditional cryptographic litterature
> when doing cryptanalysis). Better RBF policies won't solve that, including
> RBFr.
I have to disagree here. The nature of protocols like Lightning is there is a
maximum amount that it's worth attempting to pay to get a transaction mined to
perform some action. There also a deadline to perform that action.
For example, an HTLC has a clear expiry time and value. *Even if* you have no
idea what fee-rates are needed to get a transaction mined, you can simply do
repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate that
spends the entire value of the HTLC. As long as you do in fact have uncensored
access to miner mempools - as long as you haven't been sybil attacked - this
approach will do about as well as is possible, modulo pinning attacks. So our
job is now to simply fix the pinning attacks with better RBF policy.
IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper introduced
in LND v0.18 does. Face with, eg, high blockspace demand the sum total of LND
RBF sweepers will result in the most valuable HTLCs and similar things being
mined, while less valuable transactions don't (ignoring pinning of course).
That's fine! That's the best we can do given a limited blockspace.
Traditional cryptography literature is not relevant here, as it's based on the
difficulty of mathematical problems, not economics; the security of L2
protocols is based on economics.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp52WDL4hV16CbKV%40petertodd.org.
--wJF0WFIB45ivDp/7
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaedkYACgkQLly11TVR
LzdRcBAAuRFNBgQT9MMUBBdhtAayB7gPo8ugGaaKevOHfHMibbYBrJqQ1NZR50LA
ssEpC2dSFnFE6pIxmULpxpfAor28xvelcApKxuO0lNQHbsuHtGjB4Nj+LfX7tjpK
ApBdL5vbvyrIRqu32N/VyduA0SiAyLJ9hM4yuegqG2MpXGMK63CdiwEdD7JQrxxK
saPYcPTNUCU/XZ1fYvqo8c/xQrw9f0U9//L6pi+4eJ35OLFyd3WZay1P6eVfUOua
iI3IOA2F3mfpSgt5kAjKBAh3GxnADS7og0eFH1lXEo+8xz6Ijh0blXdgm2Wxpm9c
et0KmBrXoQwD4e6yjD0SndyroI/VHvnftrqTBHJN7gI4ZrU3buxm0DU3xH68fto9
54yatDcy7e5g6zwOq+3CkqMt2RVmrChRCm8vjfrArbUTAuDtDHcpdn9nRYzHw7Km
W0f988HXlfVBEg9/Zn6jknvMziWi4sbBy+GNxCT8/zVi1+wQEqRkz/XQy5IeIvqn
HZE9wY0B/gu6d+OMHbGx/wt55yEkqgn6gnB199fABXSAlHwgK65bq3vPAzD8LcKP
cl2f5URfntvcJ5frCiJgu0b3py5JxEirrNKSdK6kLVH+bJiTI4bupDfoUo7NmtNq
dg8do3dAA66kwkARph5f7eTil9tYrSVHKtTp8kbEuXCMbUWUz4E=
=iEOb
-----END PGP SIGNATURE-----
--wJF0WFIB45ivDp/7--
|