summaryrefslogtreecommitdiff
path: root/b7/f4ff1bbd36595d9df7a091ba737653188abbb6
blob: ca83fcd3f16b6b9340b8d6ed8b8b12495b25900f (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
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
Return-Path: <craigraw@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 234E4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Aug 2022 08:59:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 02392408AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Aug 2022 08:59:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 02392408AC
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=kD9QhtR6
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Pd1LsJsEH3Op
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Aug 2022 08:59:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2EA924017E
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
 [IPv6:2a00:1450:4864:20::22c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 2EA924017E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Aug 2022 08:59:22 +0000 (UTC)
Received: by mail-lj1-x22c.google.com with SMTP id x24so699390lji.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Aug 2022 01:59:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc;
 bh=3zVIxCm/l6sVTNK2HVEMPk5hnewdSaKj9kXkZzD+69g=;
 b=kD9QhtR6Li1umToEK7617bBLWu4qgkM8cD6rXW3z2V3IoJ6lFFB9VDxsgBYNqdFwVV
 JFxVLVJmPg+O9F+SYWT5pTfndjxEINDtJOPdpX61i7MxedGjlMLPJKvouBsTV6ul4MAN
 HC3MXhDP1mQmn95ZiTfy8thDZq7WaVxfX9T0CmfSPuzu9TjEQx+fzm4KKAADqW2gcO5O
 DtMlfKArAZ1lssSY1h9jNhOp1WwUxkl8uuSRJCZIb9st3iE9Vl8ARC65hV6Ehw5EQWj2
 1eYhrqcKS+Xc8zZtTGGYaEtMq6cG/i9fDQhyDw8G0Fjd2QG+F1cIO45tUetuUDShbfyt
 vyJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc;
 bh=3zVIxCm/l6sVTNK2HVEMPk5hnewdSaKj9kXkZzD+69g=;
 b=gzmOaDrNcjFjo2MxBoWZjTPokjVCZ+A1V4Ci6StLfXPTAbAvZsb6FHb38memA/JL9i
 Eb6PhpG66EfHuIsW7Fh8TQaL3JumWilAxoLJpMcGzh5a440bcqs2ovDm2IdNcWrhOafl
 CQrrhAY3q+kaGwutlWpjGOaht8TnR/Smixyw+sArb0zLBBohnM8mJQWWtXJTQ8ZFep5+
 puYGcNhNagOy/QPc5KWVXQSry7R6moQY1wKggTPjfVJs350gXT7JVlUUjk4/KOnKEVih
 EKuzqPICnChz4Ym5f8ocuJ6/dAYj1WmeyGnzYAtuUeU3IHbrjwWxVcZ8YOUEFybzdtno
 OM5A==
X-Gm-Message-State: ACgBeo1Sx/5JKV9SSnEeW9UkynyFGYvqRJycjbG7iV1XSXkokk/lkrO6
 nn0dGdN+DAoB07ReOy8jkP9ZRAFQr952kH3rPJJ0/ACb
X-Google-Smtp-Source: AA6agR6KGIvsIu65FSgO8Rb6uDLlmxqU/0ltf4fB2/cSRVB5FwGVvWbCQKsoi4VUdyXSlrQPIBdQZ7f6sSmMwiWnMVg=
X-Received: by 2002:a2e:7d05:0:b0:261:d01d:873f with SMTP id
 y5-20020a2e7d05000000b00261d01d873fmr864349ljc.484.1661417959937; Thu, 25 Aug
 2022 01:59:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAPR5oBNKQEPCAXcMoneGv2vLVmOLZGyxNEoZ4_=tyQT_mkAkmw@mail.gmail.com>
 <VtNrPzpaNh8DFSFOR9fvaWaxoJBmNn7mEnTnsIx5AJD1YhU-VR9TmUELZvVaSS1K1TclB7jitPM3Gc5zTz0bIFOw1bjil49VPwNRxVy4G14=@clarkmoody.com>
In-Reply-To: <VtNrPzpaNh8DFSFOR9fvaWaxoJBmNn7mEnTnsIx5AJD1YhU-VR9TmUELZvVaSS1K1TclB7jitPM3Gc5zTz0bIFOw1bjil49VPwNRxVy4G14=@clarkmoody.com>
From: Craig Raw <craigraw@gmail.com>
Date: Thu, 25 Aug 2022 10:59:08 +0200
Message-ID: <CAPR5oBMccmn9PB4gT=XiGcMvy-7KrbK_yBDngS1JJKiZhzRUzA@mail.gmail.com>
To: Clark Moody <clark@clarkmoody.com>
Content-Type: multipart/alternative; boundary="000000000000535bea05e70d032d"
X-Mailman-Approved-At: Thu, 25 Aug 2022 09:45:49 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format
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, 25 Aug 2022 08:59:24 -0000

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

Thanks Clark - despite having worked in the Bitcoin wallet space for a
number of years I have not come across SLIP-0015. I did try to find prior
work on this - this one escaped me.

That said, having reviewed SLIP-0015, I think it has different design
goals. For example, it requires private key derivation from seed, which
means wallets functioning as coordinators cannot use the format without
access to the devices storing the private keys. It seems to me that wallet
labels are more privacy rather than security sensitive, and coordinators
should be able to import and export a wallet label format independently.

Secondly, it uses JSON as a data format, which I wanted to avoid for
reasons I'll describe in a separate reply in this thread. Finally (and this
is minor as it could easily be extended) SLIP-0015 does not currently
support transaction labels.

Craig

On Wed, Aug 24, 2022 at 3:53 PM Clark Moody <clark@clarkmoody.com> wrote:

> Craig,
>
> Thanks for the proposal.
>
> How does this proposal compare with SLIP-0015, which provides encryption
> by default? Would it be worth exploring a merge of the two approaches?
>
> https://github.com/satoshilabs/slips/blob/master/slip-0015.md
>
> Clark
>
> ------- Original Message -------
> On Wednesday, August 24th, 2022 at 4:18 AM, Craig Raw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> I would like to propose a BIP that specifies a format for the export and
> import of labels from a wallet. While transferring access to funds across
> wallet applications has been made simple through standards such as BIP39,
> wallet labels remain siloed and difficult to extract despite their value,
> particularly in a privacy context.
>
> The proposed format is a simple two column CSV file, with the reference t=
o
> a transaction, address, input or output in the first column, and the labe=
l
> in the second column. CSV was chosen for its wide accessibility, especial=
ly
> to users without specific technical expertise. Similarly, the CSV file ma=
y
> be compressed using the ZIP format, and optionally encrypted using AES.
>
> The full text of the BIP can be found at
> https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki
> and also copied below.
>
> Feedback is appreciated.
>
> Thanks,
> Craig Raw
>
> ---
>
> <pre>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw <craig@sparrowwallet.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
> Status: Draft
> Type: Informational
> Created: 2022-08-23
> License: BSD-2-Clause
> </pre>
>
> =3D=3DAbstract=3D=3D
>
> This document specifies a format for the export of labels that may be
> attached to the transactions, addresses, input and outputs in a wallet.
>
> =3D=3DCopyright=3D=3D
>
> This BIP is licensed under the BSD 2-clause license.
>
> =3D=3DMotivation=3D=3D
>
> The export and import of funds across different Bitcoin wallet
> applications is well defined through standards such as BIP39, BIP32, BIP4=
4
> etc.
> These standards are well supported and allow users to move easily between
> different wallets.
> There is, however, no defined standard to transfer any labels the user ma=
y
> have applied to the transactions, addresses, inputs or outputs in their
> wallet.
> The UTXO model that Bitcoin uses makes these labels particularly valuable
> as they may indicate the source of funds, whether received externally or =
as
> a result of change from a prior transaction.
> In both cases, care must be taken when spending to avoid undesirable leak=
s
> of private information.
> Labels provide valuable guidance in this regard, and have even become
> mandatory when spending in several Bitcoin wallets.
> Allowing users to export their labels in a standardized way ensures that
> they do not experience lock-in to a particular wallet application.
> In addition, by using common formats, this BIP seeks to make manual or
> bulk management of labels accessible to users without specific technical
> expertise.
>
> =3D=3DSpecification=3D=3D
>
> In order to make the import and export of labels as widely accessible as
> possible, this BIP uses the comma separated values (CSV) format, which is
> widely supported by consumer, business, and scientific applications.
> Although the technical specification of CSV in RFC4180 is not always
> followed, the application of the format in this BIP is simple enough that
> compatibility should not present a problem.
> Moreover, the simplicity and forgiving nature of CSV (over for example
> JSON) lends itself well to bulk label editing using spreadsheet and text
> editing tools.
>
> A CSV export of labels from a wallet must be a UTF-8 encoded text file,
> containing one record per line, with records containing two fields
> delimited by a comma.
> The fields may be quoted, but this is unnecessary, as the first comma in
> the line will always be the delimiter.
> The first line in the file is a header, and should be ignored on import.
> Thereafter, each line represents a record that refers to a label applied
> in the wallet.
> The order in which these records appear is not defined.
>
> The first field in the record contains a reference to the transaction,
> address, input or output in the wallet.
> This is specified as one of the following:
> * Transaction ID (<tt>txid</tt>)
> * Address
> * Input (rendered as <tt>txid<index</tt>)
> * Output (rendered as <tt>txid>index</tt> or <tt>txid:index</tt>)
>
> The second field contains the label applied to the reference.
> Exporting applications may omit records with no labels or labels of zero
> length.
> Files exported should use the <tt>.csv</tt> file extension.
>
> In order to reduce file size while retaining wide accessibility, the CSV
> file may be compressed using the ZIP file format, using the <tt>.zip</tt>
> file extension.
> This <tt>.zip</tt> file may optionally be encrypted using either AES-128
> or AES-256 encryption, which is supported by numerous applications
> including Winzip and 7-zip.
> In order to ensure that weak encryption does not proliferate, importers
> following this standard must refuse to import <tt>.zip</tt> files encrypt=
ed
> with the weaker Zip 2.0 standard.
> The textual representation of the wallet's extended public key (as define=
d
> by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>
> =3D=3DImporting=3D=3D
>
> When importing, a naive algorithm may simply match against any reference,
> but it is possible to disambiguate between transactions, addresses, input=
s
> and outputs.
> For example in the following pseudocode:
> <pre>
> if reference length < 64
> Set address label
> else if reference length =3D=3D 64
> Set transaction label
> else if reference contains '<'
> Set input label
> else
> Set output label
> </pre>
>
> Importing applications may truncate labels if necessary.
>
> =3D=3DTest Vectors=3D=3D
>
> The following fragment represents a wallet label export:
> <pre>
> Reference,Label
>
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E=
,Transaction
> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E=
<0,Input
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E=
>0,Output
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E=
:0,Output
> (alternative)
> </pre>
>
> =3D=3DReference Implementation=3D=3D
>
> TBD
>
>
>
>

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

<div dir=3D"ltr">Thanks Clark - despite having worked in the Bitcoin wallet=
 space for a number of years I have not come across SLIP-0015. I did try to=
 find prior work on this - this one escaped me.=C2=A0<div><br></div><div>Th=
at said, having reviewed SLIP-0015, I think it has different design goals. =
For example, it requires private key derivation from seed, which means wall=
ets functioning as coordinators cannot use the format without access to the=
 devices storing the private keys. It seems to me that wallet labels are mo=
re privacy rather than security sensitive, and coordinators should be able =
to import and export a wallet label format independently.=C2=A0</div><div><=
br></div><div>Secondly, it uses JSON as a data format, which I wanted to av=
oid for reasons I&#39;ll describe in a separate reply in this thread. Final=
ly (and this is minor as it could easily be extended) SLIP-0015 does not cu=
rrently support transaction labels.</div><div><br></div><div>Craig</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Wed, Aug 24, 2022 at 3:53 PM Clark Moody &lt;<a href=3D"mailto:clark@clarkm=
oody.com" target=3D"_blank">clark@clarkmoody.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:A=
rial;font-size:14px">Craig,</div><div style=3D"font-family:Arial;font-size:=
14px"><br></div><div style=3D"font-family:Arial;font-size:14px">Thanks for =
the proposal.<br></div><div style=3D"font-family:Arial;font-size:14px"><br>=
</div><div style=3D"font-family:Arial;font-size:14px">How does this proposa=
l compare with SLIP-0015, which provides encryption by default? Would it be=
 worth exploring a merge of the two approaches?<br></div><div style=3D"font=
-family:Arial;font-size:14px"><br></div><div style=3D"font-family:Arial;fon=
t-size:14px"><span><a rel=3D"noreferrer nofollow noopener" href=3D"https://=
github.com/satoshilabs/slips/blob/master/slip-0015.md" target=3D"_blank">ht=
tps://github.com/satoshilabs/slips/blob/master/slip-0015.md</a></span><br><=
/div><div style=3D"font-family:Arial;font-size:14px"><br></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div>
        <div style=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)">Cl=
ark<br></div>
    </div>
   =20
            <div>
       =20
            </div>
</div>
<div style=3D"font-family:Arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Wednesday, August 24th, 2022 at 4:18 AM, Craig Raw via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr">Hi all,<div><br></div><div>I would like to pro=
pose a BIP that specifies a format for the export and import of labels from=
 a wallet. While transferring access to funds across wallet applications ha=
s been made simple through standards such as BIP39, wallet labels remain si=
loed and difficult to extract despite their value, particularly in a privac=
y context.</div><div><br></div><div>The proposed format is a simple two col=
umn CSV file, with the reference to a transaction, address, input or output=
 in the first column, and the label in the second column. CSV was chosen fo=
r its wide accessibility, especially to users without specific technical ex=
pertise. Similarly, the CSV file may be compressed using the ZIP format, an=
d optionally encrypted using AES.</div><div><br></div><div>The full text of=
 the BIP can be found at <a href=3D"https://github.com/craigraw/bips/blob/m=
aster/bip-wallet-labels.mediawiki" rel=3D"noreferrer nofollow noopener" tar=
get=3D"_blank">https://github.com/craigraw/bips/blob/master/bip-wallet-labe=
ls.mediawiki</a> and also copied below.</div><div><br></div><div>Feedback i=
s appreciated.</div><div><br></div><div>Thanks,</div><div>Craig Raw</div><d=
iv><br></div><div>---</div><div><br></div><div>&lt;pre&gt;<br>  BIP: wallet=
-labels<br>  Layer: Applications<br>  Title: Wallet Labels Export Format<br=
>  Author: Craig Raw &lt;<a href=3D"mailto:craig@sparrowwallet.com" rel=3D"=
noreferrer nofollow noopener" target=3D"_blank">craig@sparrowwallet.com</a>=
&gt;<br>  Comments-Summary: No comments yet.<br>  Comments-URI: <a href=3D"=
https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels" rel=3D"nor=
eferrer nofollow noopener" target=3D"_blank">https://github.com/bitcoin/bip=
s/wiki/Comments:BIP-wallet-labels</a><br>  Status: Draft<br>  Type: Informa=
tional<br>  Created: 2022-08-23<br>  License: BSD-2-Clause<br>&lt;/pre&gt;<=
br><br>=3D=3DAbstract=3D=3D<br><br>This document specifies a format for the=
 export of labels that may be attached to the transactions, addresses, inpu=
t and outputs in a wallet.<br><br>=3D=3DCopyright=3D=3D<br><br>This BIP is =
licensed under the BSD 2-clause license.<br><br>=3D=3DMotivation=3D=3D<br><=
br>The export and import of funds across different Bitcoin wallet applicati=
ons is well defined through standards such as BIP39, BIP32, BIP44 etc.<br>T=
hese standards are well supported and allow users to move easily between di=
fferent wallets.<br>There is, however, no defined standard to transfer any =
labels the user may have applied to the transactions, addresses, inputs or =
outputs in their wallet.<br>The UTXO model that Bitcoin uses makes these la=
bels particularly valuable as they may indicate the source of funds, whethe=
r received externally or as a result of change from a prior transaction.<br=
>In both cases, care must be taken when spending to avoid undesirable leaks=
 of private information.<br>Labels provide valuable guidance in this regard=
, and have even become mandatory when spending in several Bitcoin wallets.<=
br>Allowing users to export their labels in a standardized way ensures that=
 they do not experience lock-in to a particular wallet application.<br>In a=
ddition, by using common formats, this BIP seeks to make manual or bulk man=
agement of labels accessible to users without specific technical expertise.=
<br><br>=3D=3DSpecification=3D=3D<br><br>In order to make the import and ex=
port of labels as widely accessible as possible, this BIP uses the comma se=
parated values (CSV) format, which is widely supported by consumer, busines=
s, and scientific applications.<br>Although the technical specification of =
CSV in RFC4180 is not always followed, the application of the format in thi=
s BIP is simple enough that compatibility should not present a problem.<br>=
Moreover, the simplicity and forgiving nature of CSV (over for example JSON=
) lends itself well to bulk label editing using spreadsheet and text editin=
g tools. <br><br>A CSV export of labels from a wallet must be a UTF-8 encod=
ed text file, containing one record per line, with records containing two f=
ields delimited by a comma.<br>The fields may be quoted, but this is unnece=
ssary, as the first comma in the line will always be the delimiter.<br>The =
first line in the file is a header, and should be ignored on import.<br>The=
reafter, each line represents a record that refers to a label applied in th=
e wallet.<br>The order in which these records appear is not defined.<br><br=
>The first field in the record contains a reference to the transaction, add=
ress, input or output in the wallet.<br>This is specified as one of the fol=
lowing:<br>* Transaction ID (&lt;tt&gt;txid&lt;/tt&gt;)<br>* Address<br>* I=
nput (rendered as &lt;tt&gt;txid&lt;index&lt;/tt&gt;)<br>* Output (rendered=
 as &lt;tt&gt;txid&gt;index&lt;/tt&gt; or &lt;tt&gt;txid:index&lt;/tt&gt;)<=
br><br>The second field contains the label applied to the reference. <br>Ex=
porting applications may omit records with no labels or labels of zero leng=
th.<br>Files exported should use the &lt;tt&gt;.csv&lt;/tt&gt; file extensi=
on.<br><br>In order to reduce file size while retaining wide accessibility,=
 the CSV file may be compressed using the ZIP file format, using the &lt;tt=
&gt;.zip&lt;/tt&gt; file extension.<br>This &lt;tt&gt;.zip&lt;/tt&gt; file =
may optionally be encrypted using either AES-128 or AES-256 encryption, whi=
ch is supported by numerous applications including Winzip and 7-zip. <br>In=
 order to ensure that weak encryption does not proliferate, importers follo=
wing this standard must refuse to import &lt;tt&gt;.zip&lt;/tt&gt; files en=
crypted with the weaker Zip 2.0 standard.<br>The textual representation of =
the wallet&#39;s extended public key (as defined by BIP32, with an &lt;tt&g=
t;xpub&lt;/tt&gt; header) should be used as the password.<br><br>=3D=3DImpo=
rting=3D=3D<br><br>When importing, a naive algorithm may simply match again=
st any reference, but it is possible to disambiguate between transactions, =
addresses, inputs and outputs. <br>For example in the following pseudocode:=
<br>&lt;pre&gt;<br>  if reference length &lt; 64<br>    Set address label<b=
r>  else if reference length =3D=3D 64<br>    Set transaction label<br>  el=
se if reference contains &#39;&lt;&#39;<br>    Set input label<br>  else<br=
>    Set output label<br>&lt;/pre&gt;<br><br>Importing applications may tru=
ncate labels if necessary.<br><br>=3D=3DTest Vectors=3D=3D<br><br>The follo=
wing fragment represents a wallet label export:<br>&lt;pre&gt;<br>Reference=
,Label<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=
=E2=80=8E,Transaction<br>1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address<br>c3bd=
ad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E&lt;0,=
Input<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=
=E2=80=8E&gt;0,Output<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb=
2ad088f767b37b=E2=80=8E:0,Output (alternative)<br>&lt;/pre&gt;<br><br>=3D=
=3DReference Implementation=3D=3D<br><br>TBD<br></div><div><br></div><div><=
br></div></div>

        </blockquote><br>
    </div></blockquote></div>

--000000000000535bea05e70d032d--