summaryrefslogtreecommitdiff
path: root/57/5917df6b701177a808536e074676b259a1527a
blob: a979661301ef4ea614b42e15a81b8860270e0aff (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
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
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4BBADC6E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 05:08:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com
	[209.85.219.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0BCD23D0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 05:07:59 +0000 (UTC)
Received: by mail-yb1-f170.google.com with SMTP id j15so808274ybh.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 26 Jun 2019 22:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bitcoinbank.co.jp; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=q2k25HIg7Prh5GzRFwfELsxVMYtAjnDA1V3hhMnG82g=;
	b=WrNyUBeYmAvMLy7xMzbRuBDKeJeTbNp2rM1qdaKEASJdEZs/AkqwsMsw3NqmMsZN9H
	zaafpd6NYBjAwOoku+dyIv/yEvuYAw3W7JKxFDvm7UNEtBa5HBWJ4sKRYkGTuUm8+/NH
	/CJCbIJNeSNc024rfzB4cFyo7cHYZ2rOC504sTVc4VBkjnx9gPhEhrqQI2TQ1p+I50y8
	Gg85ICwP9vPfL/upaJsfQi0jjclCk5sMDaCC++NQwIo7bfsran9YQlaKeFMMWWbLFCC9
	xjeEFmOy0Y80fsXo7p0YIPYH3YtGzcp7+gJY8UrdAakDlYW+TDY0khC7A80u63DUPvd/
	t8Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=q2k25HIg7Prh5GzRFwfELsxVMYtAjnDA1V3hhMnG82g=;
	b=eCyc2I31lqO8i/0iez/+KV7Ae+Ya+iGrALr5Ghd/cW4cAvvWgY8xTAZ4eaVcSEffM4
	viwxCkz4sZI/XqCgDRfuOHeWUHHfa23vmMg3arTNwZaGNaBGWeBLW7P2jmort5x9riq5
	B8P7n4A1FKwY20i/HjxjzUcK3OEhv92cPHMjz+g3u1rqXGa6YHdmagAYI1J6FxEOqAyz
	PYxLQWpp/1grLUe0Xx0nQdxioOX6nJNk7t2T7eGp/kGVw5fxBCSqPO8Esfa3bIya/pk7
	7JWlcz4LDxO8HvzgpOhu59J9oHLkhjyjkZNiabdDYQ0/+7Dighd/CpbFPz6TOGTvPjbr
	534w==
X-Gm-Message-State: APjAAAXt49XY96mkCLG1UGbQS9r6nPr1svqB/gY/pjC3fY05WG0Zp3+L
	jXC2cMKrk9kW/lLZHTbIoIjm+PKCyjRfpyWLBnuRBrHlIqvq
X-Google-Smtp-Source: APXvYqy62B9EgC366Cj1o2kOZTpF8Zs3Y6kjfZCXEEu49f/QPD1eVeGhWz08wPDll6uM8Nsu25ehldAFoJksSappe8U=
X-Received: by 2002:a25:da50:: with SMTP id n77mr1241790ybf.52.1561612078984; 
	Wed, 26 Jun 2019 22:07:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
	<20190627095031.4d5817b8@simplexum.com>
In-Reply-To: <20190627095031.4d5817b8@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Thu, 27 Jun 2019 14:07:47 +0900
Message-ID: <CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="0000000000003ecb99058c47252a"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 27 Jun 2019 05:14:36 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type:
	PSBT_GLOBAL_XPUB_SIGNATURE)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2019 05:08:01 -0000

--0000000000003ecb99058c47252a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the reply.

The way we would do it is:

Let's say we have 3 cold keys for multisig: A B and C

Whose xpubs are: xA xB and xC

We all sign each other's xpubs, whose signatures are:
sAxB
sAxC
sBxA
sBxC
sCxA
sCxB

We can then create a wallet that says "when verifying change with 0x01
global type proposed by Andrew Chow, if the change is multisig, we MUST
require the other pubkeys to have signatures via my 0x02 proposal"

This way, all my PSBTs for my cold will have:
1. an 0x01 entry to tell me how to get my change.
2. All 6 of the signatures above.

And the signer will then look at the change, check my pubkey by deriving
the xpub and checking equality to the BIP_DERIVATION of the output... it
will then check the OTHER pubkeys via BIP32_DERIVATION to master
fingerprint, then link that fingerprint to a 0x02 sig from MY key,
verifying all pubkeys.

So this proposal of mine would not only fix the "send to address
verification" problem for HD, but also the multisig change problem with
0x01.

Cool.

Only thing that is kind of sad is having to include n! (of m-of-n)
signatures in every PSBT... but tbh, the PSBT size is not of much concern.

Thanks for the reply.
- Jonathan


2019=E5=B9=B46=E6=9C=8827=E6=97=A5(=E6=9C=A8) 13:49 Dmitry Petukhov <dp@sim=
plexum.com>:

> Hi!
>
> I wonder how your scheme handles multisig ?
>
> As I understand, you sign individual xpubs with cold keys, so that cold
> keys can check destination addresses are trusted.
>
> I seems to me that if you sign individual xpubs of a multisig warm
> wallet, and one key from that multisig is compromized, attackers can
> then create a single-sig destination address that they control, and
> move the coins in a chain of two transactions, first to this single-sig
> address, and then to an address that they independently control.
>
> My idea to prevent this [1] is to sign the whole 'xpub package' of the
> multisig wallet, but there is also an issue of 'partial compromize',
> where some of the keys in a multisig warm wallet is compromized, and
> you do not want to regard a particular 'xpub package' as trusted. My
> idea was [2] to use an auxiliary message that would be signed along with
> the 'xpub package', and that message can include specific 'epoch' word
> that hardware wallet can show prominently before signing, or have
> 'serial number' for xpub packages (but that will require to store last
> known serial inside hw wallet, making it stateful).
>
> I like the idea to extend PSBT to accomodate these schemes, but given
> that the huge number of possible schemes that each may probably
> require its own PSBT field type, I think that this is better dealt with
> outside of PSBT, as 'PSBT metainformation', or using some form of
> 'vendor-specific', or 'metainformation-specific' PSBT field. This way
> each usecase can be independently described in its own documentation,
> that would include the particulars of the format for the
> metainformation. This would also make it easier to implement PSBT for
> simple cases, because the 'core specification' would not grow that big.
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.h=
tml
>
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.h=
tml
>
>
> =D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Hello all,
> >
> > Just wanted to pick your brains about an idea for PSBT extension.
> >
> > One problem we try to solve with cold -> warm and warm -> hot sends
> > for our exchange wallet is "How do I know that the address I am
> > sending to is not a hacker's address that was swapped in between
> > unsigned tx creation and first signature?"
> >
> > We have a proprietary JSON based encoding system which we are looking
> > to move towards PSBT, but PSBT is missing this key functionality.
> >
> > BIP32_DERIVATION does allow us to verify the address is from a certain
> > XPUB, but, for example, it can not allow us to verify a signature of
> > that xpub.
> >
> > I have made a rough draft of the proposed key value specification.
> >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specif=
ication
> >
> > The signing key path used in the spec is just randomly chosen 31 x 4
> > bits shown as numbers with hardened paths.
> >
> > Since this issue seems similar to the change address issue, I started
> > from that as a base. With the HW wallet case, I can verify the xpub
> > by just deriving it locally and comparing equality, however, in our
> > case, we need to verify an xpub that we do not have access to via
> > derivation from our cold key(s) (since we don't want to import our
> > warm private key into our cold signer)
> >
> > So the flow would be:
> > 1. Securely verify the xpub of the warm / hot wallet.
> > 2. Using the airgap signing tool, sign the xpub with all cold keys.
> > 3. Upload the signature/xpub pairs to the online unsigned transaction
> > generator.
> > 4. Include one keyval pair per coldkey/xpub pairing.
> > 5. When offline signing, if the wallet detects there is a global
> > keyval XPUB_SIGNATURE with its pubkey in the key, it must verify that
> > all outputs have BIP32_DERIVATION and that it can verify the outputs
> > through the derivation, to the xpub, and to the signature.
> >
> > In my attempt to fitting this into PSBT, I am slightly altering our
> > current system, so don't take this as an indication 100% of how we
> > work in the backend.
> >
> > However, I would like to hear any feedback on this proposal.
> >
> > Thanks,
> > Jonathan
> >
>
>

--=20
-----------------
Jonathan Underwood
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE =E3=83=81=
=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=B3=E3=
=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC
-----------------

=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3=
=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=8A=E3=81=AE=E6=96=B9=E3=81=
=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=E9=8D=B5=E3=82=92=E3=81=94=
=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=80=82

=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

--0000000000003ecb99058c47252a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the reply.<div><br></div><div>The way we would =
do it is:<br><br>Let&#39;s say we have 3 cold keys for multisig: A B and C<=
br><br>Whose xpubs are: xA xB and xC<div><br></div><div>We all sign each ot=
her&#39;s xpubs, whose signatures are:<br>sAxB<br>sAxC<br></div><div>sBxA<b=
r>sBxC<br></div><div>sCxA<br>sCxB<br></div><div><br></div><div>We can then =
create a wallet that says &quot;when verifying change with 0x01 global type=
 proposed by Andrew Chow, if the change is multisig, we MUST require the ot=
her pubkeys to have signatures via my 0x02 proposal&quot;<br><br>This way, =
all my PSBTs for my cold will have:<br>1. an 0x01 entry to tell me how to g=
et my change.<br>2. All 6 of the signatures above.<br><br>And the signer wi=
ll then look at the change, check my pubkey by deriving the xpub and checki=
ng equality to the BIP_DERIVATION of the output... it will then check the O=
THER pubkeys via BIP32_DERIVATION to master fingerprint, then link that fin=
gerprint to a 0x02 sig from MY key, verifying all pubkeys.<br><br>So this p=
roposal of mine would not only fix the &quot;send to address verification&q=
uot; problem for HD, but also the multisig change problem with 0x01.</div><=
div><br></div><div>Cool.<br><br>Only thing that is kind of sad is having to=
 include n! (of m-of-n) signatures in every PSBT... but tbh, the PSBT size =
is not of much concern.</div><div><br></div><div>Thanks for the reply.</div=
><div>- Jonathan</div><div><br></div></div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=B9=B46=E6=9C=8827=E6=97=
=A5(=E6=9C=A8) 13:49 Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com=
">dp@simplexum.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Hi!<br>
<br>
I wonder how your scheme handles multisig ?<br>
<br>
As I understand, you sign individual xpubs with cold keys, so that cold<br>
keys can check destination addresses are trusted.<br>
<br>
I seems to me that if you sign individual xpubs of a multisig warm<br>
wallet, and one key from that multisig is compromized, attackers can<br>
then create a single-sig destination address that they control, and<br>
move the coins in a chain of two transactions, first to this single-sig<br>
address, and then to an address that they independently control.<br>
<br>
My idea to prevent this [1] is to sign the whole &#39;xpub package&#39; of =
the<br>
multisig wallet, but there is also an issue of &#39;partial compromize&#39;=
,<br>
where some of the keys in a multisig warm wallet is compromized, and<br>
you do not want to regard a particular &#39;xpub package&#39; as trusted. M=
y<br>
idea was [2] to use an auxiliary message that would be signed along with<br=
>
the &#39;xpub package&#39;, and that message can include specific &#39;epoc=
h&#39; word<br>
that hardware wallet can show prominently before signing, or have<br>
&#39;serial number&#39; for xpub packages (but that will require to store l=
ast<br>
known serial inside hw wallet, making it stateful).<br>
<br>
I like the idea to extend PSBT to accomodate these schemes, but given<br>
that the huge number of possible schemes that each may probably<br>
require its own PSBT field type, I think that this is better dealt with<br>
outside of PSBT, as &#39;PSBT metainformation&#39;, or using some form of<b=
r>
&#39;vendor-specific&#39;, or &#39;metainformation-specific&#39; PSBT field=
. This way<br>
each usecase can be independently described in its own documentation,<br>
that would include the particulars of the format for the<br>
metainformation. This would also make it easier to implement PSBT for<br>
simple cases, because the &#39;core specification&#39; would not grow that =
big.<br>
<br>
[1]<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May=
/016917.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2019-May/016917.html</a><br>
<br>
[2]<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May=
/016926.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2019-May/016926.html</a><br>
<br>
<br>
=D0=92 Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bitcoin-dev<b=
r>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; Hello all,<br>
&gt; <br>
&gt; Just wanted to pick your brains about an idea for PSBT extension.<br>
&gt; <br>
&gt; One problem we try to solve with cold -&gt; warm and warm -&gt; hot se=
nds<br>
&gt; for our exchange wallet is &quot;How do I know that the address I am<b=
r>
&gt; sending to is not a hacker&#39;s address that was swapped in between<b=
r>
&gt; unsigned tx creation and first signature?&quot;<br>
&gt; <br>
&gt; We have a proprietary JSON based encoding system which we are looking<=
br>
&gt; to move towards PSBT, but PSBT is missing this key functionality.<br>
&gt; <br>
&gt; BIP32_DERIVATION does allow us to verify the address is from a certain=
<br>
&gt; XPUB, but, for example, it can not allow us to verify a signature of<b=
r>
&gt; that xpub.<br>
&gt; <br>
&gt; I have made a rough draft of the proposed key value specification.<br>
&gt; <a href=3D"https://github.com/junderw/bips/blob/addXpubSig/bip-0174.me=
diawiki#specification" rel=3D"noreferrer" target=3D"_blank">https://github.=
com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification</a><br>
&gt; <br>
&gt; The signing key path used in the spec is just randomly chosen 31 x 4<b=
r>
&gt; bits shown as numbers with hardened paths.<br>
&gt; <br>
&gt; Since this issue seems similar to the change address issue, I started<=
br>
&gt; from that as a base. With the HW wallet case, I can verify the xpub<br=
>
&gt; by just deriving it locally and comparing equality, however, in our<br=
>
&gt; case, we need to verify an xpub that we do not have access to via<br>
&gt; derivation from our cold key(s) (since we don&#39;t want to import our=
<br>
&gt; warm private key into our cold signer)<br>
&gt; <br>
&gt; So the flow would be:<br>
&gt; 1. Securely verify the xpub of the warm / hot wallet.<br>
&gt; 2. Using the airgap signing tool, sign the xpub with all cold keys.<br=
>
&gt; 3. Upload the signature/xpub pairs to the online unsigned transaction<=
br>
&gt; generator.<br>
&gt; 4. Include one keyval pair per coldkey/xpub pairing.<br>
&gt; 5. When offline signing, if the wallet detects there is a global<br>
&gt; keyval XPUB_SIGNATURE with its pubkey in the key, it must verify that<=
br>
&gt; all outputs have BIP32_DERIVATION and that it can verify the outputs<b=
r>
&gt; through the derivation, to the xpub, and to the signature.<br>
&gt; <br>
&gt; In my attempt to fitting this into PSBT, I am slightly altering our<br=
>
&gt; current system, so don&#39;t take this as an indication 100% of how we=
<br>
&gt; work in the backend.<br>
&gt; <br>
&gt; However, I would like to hear any feedback on this proposal.<br>
&gt; <br>
&gt; Thanks,<br>
&gt; Jonathan<br>
&gt; <br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=
=3D"ltr"><div>-----------------<br></div><div>Jonathan Underwood</div><div>=
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE=E3=80=80=E3=
=83=81=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=
=B3=E3=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC</div><div>----------------=
-</div><div><br></div><div>=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=
=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=
=8A=E3=81=AE=E6=96=B9=E3=81=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=
=E9=8D=B5=E3=82=92=E3=81=94=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=
=80=82</div><div><br></div><div>=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3=
FDAD998682F3590FEA3</div></div></div></div></div></div>

--0000000000003ecb99058c47252a--