path: root/0f/9ce2b3e36bd1e33f5afe6a5214262bc6eedff4

Return-Path: <stick@satoshilabs.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 38B1FC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Aug 2022 20:18:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 01DCC60FE0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Aug 2022 20:18:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 01DCC60FE0
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=satoshilabs.com header.i=@satoshilabs.com
 header.a=rsa-sha256 header.s=google header.b=ZVmZwHao
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 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, 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 AlxtllerPMqy
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Aug 2022 20:18:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4FE2D6063B
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com
 [IPv6:2607:f8b0:4864:20::1131])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4FE2D6063B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Aug 2022 20:18:39 +0000 (UTC)
Received: by mail-yw1-x1131.google.com with SMTP id
 00721157ae682-333b049f231so490327347b3.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Aug 2022 13:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=satoshilabs.com; s=google;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc;
 bh=Yn7gKXwvukHt9W5v2QW7HjLidMrQLeDtUsoDNOyx2lU=;
 b=ZVmZwHaoGJbQbQMbDLcP0BUWgAF0/9WJf6MhYOVQfFwQV1yQy6tYwG5bA8O2YmTI3o
 pab3mBfCAtYAj51ugYD0PRDNJvP1UyWlNvPw8vYo4EJuYMomcdrzUzgpR1DgRI7TPLHE
 RWIzvjyR+D3aimyZ04XIX8Ik5ca3Oz9K15AkfulQWdhvHtt377cA6wLVd1R9D4GkjfwG
 HmgmD20sWS4quLFsVw6cWEhaoNwaN22nER/r/22imZ2yb+z4/7Tv2qc9cG/wcW+b56np
 lY55AidzoQP3rv7d9EfYhvaa032kxPP67gcZ+qbSs/MN30VZ7h4lIbrBwCY4f7UcNQyj
 cRhg==
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=Yn7gKXwvukHt9W5v2QW7HjLidMrQLeDtUsoDNOyx2lU=;
 b=6Ur90oC8BUafKQ/GxJ5Kj5konYRCpt45PDGl7bcfXQWuj6EvvIYCc4jqcdzYLje2kP
 4K5DQ4F6zxGD2Isd6yvj5NA685l1V3bqEXMErWkh5v9w9C5rZi2VtpAWI2znComFdGJy
 B8pDPSycfFgH31Uk0TmetSLyRyseQeuFfPFmlY7N80Q07sxMVb37U9241CHXSJ84vkBg
 Qc0Tea+aXjMyRNeEPp9iHNF0DNwTIiL/odCTGSZ+WI8oCd8i5ssbaT81kHjSq3R4GDfT
 Xt2PItxSfvTBEGW1oS7wB4FhnXn2PLkQMUco67M5rlFg3wnb8AJSMz6xuj4/kWoMyvJJ
 Qvhw==
X-Gm-Message-State: ACgBeo1KCmrTCuWB3D/TMlLwxTM5PVWny8WQtgap2snq0D3L7P5kMUrQ
 wNJ7E8CEfWUrhoY+DfyN20ag+lJ7DVUs3fhQga3aRFAgESE=
X-Google-Smtp-Source: AA6agR6d87DxoVjgMOzqoI7twYYlNbiLC+XfXRp/98v7CIweg8vlUx+/5GavZMET5yXKosHyHiM/oFI4BlAagMrVR0c=
X-Received: by 2002:a81:a095:0:b0:336:8cf3:4b44 with SMTP id
 x143-20020a81a095000000b003368cf34b44mr921877ywg.228.1661372317997; Wed, 24
 Aug 2022 13:18:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAPR5oBNKQEPCAXcMoneGv2vLVmOLZGyxNEoZ4_=tyQT_mkAkmw@mail.gmail.com>
 <1UV4d_Y74sQ_C8l5s6_gwZOOaFcB0hWnWYWl8TJ_PFs9bQ-fb_w_CYZjZOom2JJ0CSC6-w-Xi999ocafkWa7Mkz0MzsCs2Vg91M5to2fafA=@protonmail.com>
In-Reply-To: <1UV4d_Y74sQ_C8l5s6_gwZOOaFcB0hWnWYWl8TJ_PFs9bQ-fb_w_CYZjZOom2JJ0CSC6-w-Xi999ocafkWa7Mkz0MzsCs2Vg91M5to2fafA=@protonmail.com>
From: Pavol Rusnak <stick@satoshilabs.com>
Date: Wed, 24 Aug 2022 22:18:27 +0200
Message-ID: <CAF90AvknWwhtP01x2xJxeqkVd7zge4dv6DD0yR3+pSvTPWPJPQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 rhavar@protonmail.com
Content-Type: multipart/alternative; boundary="000000000000dab4af05e7026280"
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: Wed, 24 Aug 2022 20:18:41 -0000

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

There is already a JSON standard that has been already used in the wild for
the last 7 years described in SLIP-0015 (mentioned by Clark in this
thread). No need to reinventing the wheel again.

On Wed 24. 8. 2022 at 21:44, Ryan Havar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'd strongly suggest not using CSV. Especially for a standard. I've worke=
d
> with it as an interchange format many a times, and it's always been a
> clusterfuck.
>
> Right off the bat, you have stuff like "The fields may be quoted, but thi=
s
> is unnecessary as the first comma in the line will always be the delimite=
r"
> which invariably leads to some implementations doing it, some
> implementations not doing it, and others that are intolerant of the other
> way.
>
> And you have also made the classic mistake of not strictly defining escap=
e
> rules. So everyone will pick their own (e.g. some will \, escape commas,
> others will not cause it's quoted and escape quotes, and others will assu=
me
> no escaping is required since its the last column in a csv).
>
> Over time it morphs into its own mini-monster that introduces so much pai=
n.
>
> On a similar note, allowing alternatives (like: txid>index vs txid:index)
> provides no benefit, but creates additional work for implementations (who
> quite likely only test formats they produce) and future incompatibilities=
.
>
> I know everyone loves to hate on it, but really (line-separated?) json is
> the way to go.
>
> { "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=
=E2=80=8E",
> "label": "wow, such label" }
> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b"=
,
> "txout": 4, "label": "omg this is so easy to parse" }
> { "tx: "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b"=
,
> "txin": 0, "label": "wow this is going to be extensible as well" }
>
>
>
>
> -Ryan
>
> ------- Original Message -------
>
> On Wednesday, August 24th, 2022 at 2: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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--=20
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs

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

<div dir=3D"auto">There is already a JSON standard that has been already us=
ed in the wild for the last 7 years described in SLIP-0015 (mentioned by Cl=
ark in this thread). No need to reinventing the wheel again.=C2=A0</div><di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On W=
ed 24. 8. 2022 at 21:44, Ryan Havar via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-lef=
t:1ex;border-left-color:rgb(204,204,204)"><div style=3D"font-family:Arial;f=
ont-size:14px">I&#39;d strongly suggest not using CSV. Especially for a sta=
ndard. I&#39;ve worked with it as an interchange format many a times, and i=
t&#39;s always been a clusterfuck.=C2=A0</div><div style=3D"font-family:Ari=
al;font-size:14px"><br></div><div><font face=3D"Arial" style=3D"font-family=
:Arial;color:rgb(0,0,0)">Right off the bat, you have stuff like &quot;The f=
ields may be quoted, but this is unnecessary <span style=3D"font-family:Ari=
al">as the first comma in the line will always be the delimiter</span>&quot=
; which invariably leads to some implementations doing it, some implementat=
ions=C2=A0not doing it, and others that are intolerant of the other way.=C2=
=A0</font></div><div><font face=3D"Arial" style=3D"font-family:Arial;color:=
rgb(0,0,0)"><br></font></div><div><font face=3D"Arial" style=3D"font-family=
:Arial;color:rgb(0,0,0)">And you have also made the classic mistake of not =
strictly defining escape rules. So everyone will pick their own (e.g. some =
will \, escape commas, others will not cause it&#39;s quoted and escape quo=
tes, and others will assume no escaping is required since its the last colu=
mn in a csv).=C2=A0<br><br>Over time it morphs into its own mini-monster th=
at introduces so much pain.<br><br>On a similar=C2=A0note, allowing alterna=
tives (like:=C2=A0<span style=3D"font-family:Arial">txid&gt;index vs txid:i=
ndex) provides no benefit, but creates additional work for implementations =
(who quite likely only test formats they produce) and future incompatibilit=
ies.=C2=A0</span></font></div><div><font face=3D"Arial" style=3D"font-famil=
y:Arial;color:rgb(0,0,0)"><br></font></div><div><font face=3D"Arial" style=
=3D"font-family:Arial;color:rgb(0,0,0)">I know everyone loves to hate on it=
, but really (line-separated?) json is the way to go.=C2=A0</font></div><di=
v><font face=3D"Arial" style=3D"font-family:Arial;color:rgb(0,0,0)"><br></f=
ont></div><div><font face=3D"Arial" style=3D"font-family:Arial;color:rgb(0,=
0,0)">{ &quot;tx&quot;: &quot;<span style=3D"font-family:Arial">c3bdad6e7dc=
d7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E&quot;, &quot=
;label&quot;: &quot;wow, such label&quot; }<br>{ &quot;tx: &quot;<span styl=
e=3D"font-family:Arial;display:inline!important;background-color:rgb(255,25=
5,255)">c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b&qu=
ot;, &quot;txout&quot;: 4, &quot;label&quot;: &quot;omg this is so easy to =
parse&quot; }<br><span style=3D"font-family:Arial;display:inline!important;=
background-color:rgb(255,255,255)">{ &quot;tx: &quot;</span><span style=3D"=
font-family:Arial;display:inline!important;background-color:rgb(255,255,255=
)">c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b&quot;, =
&quot;txin&quot;: 0, &quot;label&quot;: &quot;wow this is going to be exten=
sible as well&quot; }</span><br></span></span></font></div><div><font face=
=3D"Arial" style=3D"font-family:Arial;color:rgb(0,0,0)"><br><br><br><br></f=
ont></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div style=3D"font-family:Arial">
        <div style=3D"font-family:Arial">-Ryan</div>
    </div>
   =20
            <div style=3D"font-family:Arial">
       =20
            </div>
</div>
<div style=3D"font-family:Arial;font-size:14px"><br></div><div>
        ------- Original Message -------</div><div><br>
        On Wednesday, August 24th, 2022 at 2: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>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><=
div></div><div>Best Regards / S pozdravom,</div><div><br></div><div>Pavol &=
quot;stick&quot; Rusnak</div><div>Co-Founder, SatoshiLabs</div></div></div>=
</div></div>

--000000000000dab4af05e7026280--