path: root/0a/251d8ab8074634e48c5bd3602271249f51f4db

Return-Path: <craigraw@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C11E7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 08:23:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 938C760E1B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 08:23:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 938C760E1B
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=onqZwc0U
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id q7bsCgbhPyNM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 08:23:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EBBF36059B
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [IPv6:2a00:1450:4864:20::22d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id EBBF36059B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 08:23:32 +0000 (UTC)
Received: by mail-lj1-x22d.google.com with SMTP id c7so6504798ljm.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Sep 2022 01:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date;
 bh=rnsE15bYcjuXlruKdYDK/uSKuAhGvto1AAFN6aeIp/Q=;
 b=onqZwc0UOtAuhaOMUXz6ruWLkoC7srIc1baveSQMUdO3Qgh48bEO0AScle1MGUbWEJ
 uSmB6pMZFrsf3Y+huTC4gTqiiIPPIJQqd5hgzG/avVMgjlLMfq7HDE6ZXXlY1CXHmwFD
 4yCDHWstl3pf5Uxk7xhetVEfUJcQmcKb3kH4dgNsFxb3LqywJ5sXJlMwm/3p1MezWEaj
 XVldZkKWgbTnokrCE+I2LQYk8bzWcKHE9MTK3FpQuS9mK7ngxpj9xPmH2XBBZXyLt2JG
 jENtsRs8KJQpLvE4Q5cMPX3Zb6U0pCDghlrYu53jHuOvNdYrWz9XbWLwMjEFETJreZHw
 szgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date;
 bh=rnsE15bYcjuXlruKdYDK/uSKuAhGvto1AAFN6aeIp/Q=;
 b=EgBPOg5qn3ICTlqcVL98XHu88CqWFl7FlHuQHAE4wmGNhRJZdYmFeJMI2dmG9GntNI
 MU6ugZVNlUp+mdqaSXyD0ck7S/rFfVkGJP5Y27+0TVE+kbrtGTTI05BINq7AiVX9xjBg
 uVjoGc4Y+mW42eopHszHjG6fh0RE6icOmJMV/ECvEaqYbRvi063asnoV1y5xNINcisX1
 Ugqo8Wdp1QxtfhuK46CB4y6cy64+fHoq/YJAm4fAtYek1tOJP7FrSMpFDtX6TKOLCuXW
 4RWus1CemRmvxnELNDQj4i8pI9S7Rej/66qEMcPwLjT6QYXjKKjWZAWpZR5YqV2KVUmV
 rkkQ==
X-Gm-Message-State: ACrzQf3yvF48l49qnVJPAscxbHN7iStk2nKvmsJLnr34IXHlq4kwL8Cw
 1VHZTDMdcov+FphiowiCkwCzOEMKoheAOU+5lvAIMUUyqbA=
X-Google-Smtp-Source: AMsMyM5cqvw45FCQ+v8USEToKzTKt88G/o4otlhzUIfrAVmbpjdFuIa5R5nhKSlPboXY5MxQ2DQUW0ipPkNjR78mHrE=
X-Received: by 2002:a2e:8e70:0:b0:26c:549b:dd0d with SMTP id
 t16-20020a2e8e70000000b0026c549bdd0dmr6876493ljk.172.1664180610053; Mon, 26
 Sep 2022 01:23:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAPR5oBNKQEPCAXcMoneGv2vLVmOLZGyxNEoZ4_=tyQT_mkAkmw@mail.gmail.com>
In-Reply-To: <CAPR5oBNKQEPCAXcMoneGv2vLVmOLZGyxNEoZ4_=tyQT_mkAkmw@mail.gmail.com>
From: Craig Raw <craigraw@gmail.com>
Date: Mon, 26 Sep 2022 10:23:18 +0200
Message-ID: <CAPR5oBNuja7L9VAx+YEB=JmcCGStA0tZonHOuaabkwe1nxzyyA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001ab9bd05e9903ee0"
X-Mailman-Approved-At: Mon, 26 Sep 2022 08:26:34 +0000
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: Mon, 26 Sep 2022 08:23:34 -0000

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

Following discussion with several wallet developers, I have come to the
conclusion that the secondary goal of managing labels in non-specialized
applications must be sacrificed in order to achieve the primary goal of
wide implementation across different wallets. While this tradeoff was
perhaps inevitable, it was worth a try!

As such I have rewritten the specification to use JSON, specifically the
JSON Lines format suggested by Ryan Havar and others (thank you). This
allows documents to be split or streamed, and is convenient for
command-line processing. The format is also now self describing via a type
field, permitting simple type identification (thank you Ali Sherief and
others). Public keys and xpubs have been added as types following further
suggestions. To keep the specification simple, compression and encryption
have been removed - with the strong recommendation to consider protecting
the data in a way suitable to its application.

The rewritten BIP can be found at
https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki

It is perhaps simplest to understand it by looking at an example export:

{ "type": "tx", "ref":
"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd",
"label": "Transaction" }
{ "type": "addr", "ref": "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c",
"label": "Address" }
{ "type": "pubkey", "ref":
"0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448",
"label": "Public Key" }
{ "type": "input", "ref":
"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0",
"label": "Input" }
{ "type": "output", "ref":
"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1",
"label": "Output" }
{ "type": "xpub", "ref":
"xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...", "label": "Extended
Public Key" }

Feedback is always appreciated.

Craig


On Wed, Aug 24, 2022 at 11:18 AM Craig Raw <craigraw@gmail.com> 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
>
>
>

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

<div dir=3D"ltr">Following discussion with several wallet developers, I hav=
e come to the conclusion that the secondary goal of managing labels in non-=
specialized applications must be sacrificed=C2=A0in order to achieve the pr=
imary goal of wide implementation across different wallets. While this trad=
eoff was perhaps inevitable, it was worth a try!<div><br></div><div>As such=
 I have rewritten the specification to use JSON, specifically the JSON Line=
s format suggested by Ryan Havar and others (thank you). This allows docume=
nts to be split or streamed, and is convenient=C2=A0for command-line proces=
sing. The format is also now self describing via a type field, permitting s=
imple type identification (thank you Ali Sherief and others). Public keys a=
nd xpubs have been added as types=C2=A0following further suggestions. To ke=
ep the specification simple, compression and encryption have been removed -=
 with the strong recommendation to consider protecting the data in a way su=
itable to its application.</div><div><br></div><div>The rewritten BIP can b=
e found at=C2=A0<a href=3D"https://github.com/craigraw/bips/blob/master/bip=
-wallet-labels.mediawiki" target=3D"_blank">https://github.com/craigraw/bip=
s/blob/master/bip-wallet-labels.mediawiki</a></div><div><br></div><div>It i=
s perhaps simplest to understand it by looking at an example export:</div><=
div><br></div><div>{ &quot;type&quot;: &quot;tx&quot;, &quot;ref&quot;: &qu=
ot;f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd&quot;, =
&quot;label&quot;: &quot;Transaction&quot; }<br>{ &quot;type&quot;: &quot;a=
ddr&quot;, &quot;ref&quot;: &quot;bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7=
c&quot;, &quot;label&quot;: &quot;Address&quot; }<br>{ &quot;type&quot;: &q=
uot;pubkey&quot;, &quot;ref&quot;: &quot;0283409659355b6d1cc3c32decd5d561ab=
aac86c37a353b52895a5e6c196d6f448&quot;, &quot;label&quot;: &quot;Public Key=
&quot; }<br>{ &quot;type&quot;: &quot;input&quot;, &quot;ref&quot;: &quot;f=
91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0&quot;, &q=
uot;label&quot;: &quot;Input&quot; }<br>{ &quot;type&quot;: &quot;output&qu=
ot;, &quot;ref&quot;: &quot;f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c483=
3478b202796c8aafd:1&quot;, &quot;label&quot;: &quot;Output&quot; }<br>{ &qu=
ot;type&quot;: &quot;xpub&quot;, &quot;ref&quot;: &quot;xpub661MyMwAqRbcFtX=
gS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...&quot;, &quot;label&quot;: &quot;Extended =
Public Key&quot; }<br></div><div><br></div><div>Feedback is always apprecia=
ted.</div><div><br></div><div>Craig</div><div><br></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 24, 202=
2 at 11:18 AM Craig Raw &lt;<a href=3D"mailto:craigraw@gmail.com">craigraw@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">Hi all,<div><br></div><div>I would=C2=A0like to=
 propose a BIP that specifies a format=C2=A0for the export and import of la=
bels from a wallet. While transferring access to funds across wallet applic=
ations has been made simple through standards such as BIP39, wallet=C2=A0la=
bels remain siloed and difficult to extract despite their value, particular=
ly in a privacy context.</div><div><br></div><div>The proposed format is a =
simple two column CSV file, with the reference to a transaction, address, i=
nput or output in the first column, and the label in the second column. CSV=
 was chosen for its wide accessibility, especially to users without specifi=
c technical expertise. Similarly, the CSV file may be compressed using the =
ZIP format, and optionally encrypted using AES.</div><div><br></div><div>Th=
e full text of the BIP can be found at=C2=A0<a href=3D"https://github.com/c=
raigraw/bips/blob/master/bip-wallet-labels.mediawiki" target=3D"_blank">htt=
ps://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki</a> a=
nd also copied below.</div><div><br></div><div>Feedback is appreciated.</di=
v><div><br></div><div>Thanks,</div><div>Craig Raw</div><div><br></div><div>=
---</div><div><br></div><div>&lt;pre&gt;<br>=C2=A0 BIP: wallet-labels<br>=
=C2=A0 Layer: Applications<br>=C2=A0 Title: Wallet Labels Export Format<br>=
=C2=A0 Author: Craig Raw &lt;<a href=3D"mailto:craig@sparrowwallet.com" tar=
get=3D"_blank">craig@sparrowwallet.com</a>&gt;<br>=C2=A0 Comments-Summary: =
No comments yet.<br>=C2=A0 Comments-URI: <a href=3D"https://github.com/bitc=
oin/bips/wiki/Comments:BIP-wallet-labels" target=3D"_blank">https://github.=
com/bitcoin/bips/wiki/Comments:BIP-wallet-labels</a><br>=C2=A0 Status: Draf=
t<br>=C2=A0 Type: Informational<br>=C2=A0 Created: 2022-08-23<br>=C2=A0 Lic=
ense: 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 t=
o the transactions, addresses, input and outputs in a wallet.<br><br>=3D=3D=
Copyright=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 applications is well defined through standards su=
ch as BIP39, BIP32, BIP44 etc.<br>These standards are well supported and al=
low users to move easily between different wallets.<br>There is, however, n=
o defined standard to transfer any labels the user may have applied to the =
transactions, addresses, inputs or outputs in their wallet.<br>The UTXO mod=
el that Bitcoin uses makes these labels particularly valuable as they may i=
ndicate the source of funds, whether 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 provi=
de valuable guidance in this regard, and have even become mandatory when sp=
ending 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 par=
ticular wallet application.<br>In addition, by using common formats, this B=
IP seeks to make manual or bulk management of labels accessible to users wi=
thout specific technical expertise.<br><br>=3D=3DSpecification=3D=3D<br><br=
>In order to make the import and export of labels as widely accessible as p=
ossible, this BIP uses the comma separated values (CSV) format, which is wi=
dely supported by consumer, business, and scientific applications.<br>Altho=
ugh the technical specification of CSV in RFC4180 is not always followed, t=
he application of the format in this BIP is simple enough that compatibilit=
y should not present a problem.<br>Moreover, the simplicity and forgiving n=
ature of CSV (over for example JSON) lends itself well to bulk label editin=
g using spreadsheet and text editing tools. <br><br>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.<br>The field=
s may be quoted, but this is unnecessary, as the first comma in the line wi=
ll always be the delimiter.<br>The first line in the file is a header, and =
should be ignored on import.<br>Thereafter, each line represents a record t=
hat refers to a label applied in the wallet.<br>The order in which these re=
cords appear is not defined.<br><br>The first field in the record contains =
a reference to the transaction, address, input or output in the wallet.<br>=
This is specified as one of the following:<br>* Transaction ID (&lt;tt&gt;t=
xid&lt;/tt&gt;)<br>* Address<br>* Input (rendered as &lt;tt&gt;txid&lt;inde=
x&lt;/tt&gt;)<br>* Output (rendered as &lt;tt&gt;txid&gt;index&lt;/tt&gt; o=
r &lt;tt&gt;txid:index&lt;/tt&gt;)<br><br>The second field contains the lab=
el applied to the reference. <br>Exporting applications may omit records wi=
th no labels or labels of zero length.<br>Files exported should use the &lt=
;tt&gt;.csv&lt;/tt&gt; file extension.<br><br>In order to reduce file size =
while retaining wide accessibility, the CSV file may be compressed using th=
e ZIP file format, using the &lt;tt&gt;.zip&lt;/tt&gt; file extension.<br>T=
his &lt;tt&gt;.zip&lt;/tt&gt; file may optionally be encrypted using either=
 AES-128 or AES-256 encryption, which is supported by numerous applications=
 including Winzip and 7-zip. <br>In order to ensure that weak encryption do=
es not proliferate, importers following this standard must refuse to import=
 &lt;tt&gt;.zip&lt;/tt&gt; files encrypted 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&gt;xpub&lt;/tt&gt; header) should be used=
 as the password.<br><br>=3D=3DImporting=3D=3D<br><br>When importing, a nai=
ve algorithm may simply match against any reference, but it is possible to =
disambiguate between transactions, addresses, inputs and outputs. <br>For e=
xample in the following pseudocode:<br>&lt;pre&gt;<br>=C2=A0 if reference l=
ength &lt; 64<br>=C2=A0 =C2=A0 Set address label<br>=C2=A0 else if referenc=
e length =3D=3D 64<br>=C2=A0 =C2=A0 Set transaction label<br>=C2=A0 else if=
 reference contains &#39;&lt;&#39;<br>=C2=A0 =C2=A0 Set input label<br>=C2=
=A0 else<br>=C2=A0 =C2=A0 Set output label<br>&lt;/pre&gt;<br><br>Importing=
 applications may truncate labels if necessary.<br><br>=3D=3DTest Vectors=
=3D=3D<br><br>The following fragment represents a wallet label export:<br>&=
lt;pre&gt;<br>Reference,Label<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2e=
edd5fcbb2ad088f767b37b=E2=80=8E,Transaction<br>1A69TXnEM2ms9fMaY9UuiJ7415X7=
xZaUSg,Address<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f=
767b37b=E2=80=8E&lt;0,Input<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eed=
d5fcbb2ad088f767b37b=E2=80=8E&gt;0,Output<br>c3bdad6e7dcd7997e16a5b7b7cf4d8=
f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E:0,Output (alternative)<br>&lt;/=
pre&gt;<br><br>=3D=3DReference Implementation=3D=3D<br><br>TBD<br></div><di=
v><br></div><div><br></div></div>
</blockquote></div>

--0000000000001ab9bd05e9903ee0--