path: root/8c/5a0e5cb19c4429671002a74c4fbd3d18dac1e9

Return-Path: <rodolfo@coinkite.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AF324C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 20:01:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 73ADB40461
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 20:01:47 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 73ADB40461
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 5mjXeDCS4YMe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 20:01:45 +0000 (UTC)
X-Greylist: delayed 00:09:20 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CA52C400FE
Received: from smtp71.ord1d.emailsrvr.com (smtp71.ord1d.emailsrvr.com
 [184.106.54.71])
 by smtp2.osuosl.org (Postfix) with ESMTPS id CA52C400FE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 29 Aug 2022 20:01:45 +0000 (UTC)
X-Auth-ID: rodolfo@coinkite.com
Received: by smtp17.relay.ord1d.emailsrvr.com (Authenticated sender:
 rodolfo-AT-coinkite.com) with ESMTPSA id BD3E820083; 
 Mon, 29 Aug 2022 15:52:23 -0400 (EDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-486AE8F6-7A00-4009-9637-7B26BEE4B453
Content-Transfer-Encoding: 7bit
From: NVK <rodolfo@coinkite.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 29 Aug 2022 15:52:17 -0400
Message-Id: <E6BFAF8D-9FD7-4C9D-813C-62C73E9FE26C@coinkite.com>
References: <CAPR5oBNKQEPCAXcMoneGv2vLVmOLZGyxNEoZ4_=tyQT_mkAkmw@mail.gmail.com>
In-Reply-To: <CAPR5oBNKQEPCAXcMoneGv2vLVmOLZGyxNEoZ4_=tyQT_mkAkmw@mail.gmail.com>
To: Craig Raw <craigraw@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (19G82)
X-Classification-ID: 3f4fc290-d3ed-417f-b1df-caed94a5080f-1-1
X-Mailman-Approved-At: Mon, 29 Aug 2022 20:19:54 +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, 29 Aug 2022 20:01:47 -0000


--Apple-Mail-486AE8F6-7A00-4009-9637-7B26BEE4B453
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Thanks for this proposal.

I was trying to avoid adding more opinions / bike-shdding to the discussion a=
nd didn=E2=80=99t want to particularly pick at any of the threads.

But, I think I=E2=80=99d like to at least voice at how important having a hu=
man readable format for this is. CSV is indeed a format with many shortcomin=
gs, but so are most cross applications open formats that are human readable.=
 I go through this every month for business and personal.

If contention is too high for CSV as cross application for import/export the=
n maybe the route of two file formats maybe awkward but necessary. JSON mayb=
e used as the choice for bitcoin clients for label syncing and CSV as the ex=
port for other purposes. I believe CSV is importable by most accounting soft=
ware, old and new. JSON is not.

In regards to encryption, AES on 7z is a great, wide os native support.

Best,

NVK

> On Aug 24, 2022, at 05:46, Craig Raw via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
> =EF=BB=BF
> Hi all,
>=20
> I would like to propose a BIP that specifies a format for the export and i=
mport of labels from a wallet. While transferring access to funds across wal=
let applications has been made simple through standards such as BIP39, walle=
t labels remain siloed and difficult to extract despite their value, particu=
larly in a privacy context.
>=20
> The proposed format is a simple two column CSV file, with the reference to=
 a transaction, address, input or output in the first column, and the label i=
n the second column. CSV was chosen for its wide accessibility, especially t=
o users without specific technical expertise. Similarly, the CSV file may be=
 compressed using the ZIP format, and optionally encrypted using AES.
>=20
> 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.
>=20
> Feedback is appreciated.
>=20
> Thanks,
> Craig Raw
>=20
> ---
>=20
> <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-l=
abels
>   Status: Draft
>   Type: Informational
>   Created: 2022-08-23
>   License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies a format for the export of labels that may be atta=
ched to the transactions, addresses, input and outputs in a wallet.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> The export and import of funds across different Bitcoin wallet application=
s is well defined through standards such as BIP39, BIP32, BIP44 etc.
> These standards are well supported and allow users to move easily between d=
ifferent wallets.
> There is, however, no defined standard to transfer any labels the user may=
 have applied to the transactions, addresses, inputs or outputs in their wal=
let.
> The UTXO model that Bitcoin uses makes these labels particularly valuable a=
s 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 leaks=
 of private information.
> Labels provide valuable guidance in this regard, and have even become mand=
atory when spending in several Bitcoin wallets.
> Allowing users to export their labels in a standardized way ensures that t=
hey do not experience lock-in to a particular wallet application.
> In addition, by using common formats, this BIP seeks to make manual or bul=
k management of labels accessible to users without specific technical expert=
ise.
>=20
> =3D=3DSpecification=3D=3D
>=20
> 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 wid=
ely supported by consumer, business, and scientific applications.
> Although the technical specification of CSV in RFC4180 is not always follo=
wed, the application of the format in this BIP is simple enough that compati=
bility should not present a problem.
> Moreover, the simplicity and forgiving nature of CSV (over for example JSO=
N) lends itself well to bulk label editing using spreadsheet and text editin=
g tools.=20
>=20
> A CSV export of labels from a wallet must be a UTF-8 encoded text file, co=
ntaining one record per line, with records containing two fields delimited b=
y a comma.
> The fields may be quoted, but this is unnecessary, as the first comma in t=
he 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 i=
n the wallet.
> The order in which these records appear is not defined.
>=20
> The first field in the record contains a reference to the transaction, add=
ress, 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>)
>=20
> The second field contains the label applied to the reference.=20
> Exporting applications may omit records with no labels or labels of zero l=
ength.
> Files exported should use the <tt>.csv</tt> file extension.
>=20
> In order to reduce file size while retaining wide accessibility, the CSV f=
ile may be compressed using the ZIP file format, using the <tt>.zip</tt> fil=
e extension.
> This <tt>.zip</tt> file may optionally be encrypted using either AES-128 o=
r AES-256 encryption, which is supported by numerous applications including W=
inzip and 7-zip.=20
> In order to ensure that weak encryption does not proliferate, importers fo=
llowing this standard must refuse to import <tt>.zip</tt> files encrypted wi=
th the weaker Zip 2.0 standard.
> The textual representation of the wallet's extended public key (as defined=
 by BIP32, with an <tt>xpub</tt> header) should be used as the password.
>=20
> =3D=3DImporting=3D=3D
>=20
> When importing, a naive algorithm may simply match against any reference, b=
ut it is possible to disambiguate between transactions, addresses, inputs an=
d outputs.=20
> 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>
>=20
> Importing applications may truncate labels if necessary.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> 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>
>=20
> =3D=3DReference Implementation=3D=3D
>=20
> TBD
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-486AE8F6-7A00-4009-9637-7B26BEE4B453
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><meta http-equiv=3D"conten=
t-type" content=3D"text/html; charset=3Dutf-8">Hello,<div><br></div><div>Tha=
nks for this proposal.<br><div><br></div><div>I was trying to avoid adding m=
ore opinions / bike-shdding to the discussion and didn=E2=80=99t want to par=
ticularly pick at any of the threads.</div><div><br></div><div>But, I think I=
=E2=80=99d like to at least voice at how important having a human readable f=
ormat for this is. CSV is indeed a format with many shortcomings, but so are=
 most cross applications open formats that are human readable. I go through t=
his every month for business and personal.</div><div><br></div><div>If conte=
ntion is too high for CSV as cross application for import/export then maybe t=
he route of two file formats maybe awkward but necessary. JSON maybe used as=
 the choice for bitcoin clients for label syncing and CSV as the export for o=
ther purposes. I believe CSV is importable by most accounting software, old a=
nd new. JSON is not.</div><div><br></div><div>In regards to encryption, AES o=
n 7z is a great, wide os native support.</div><div><br></div><div>Best,</div=
><div><br></div><div>NVK</div><div><div><br><div dir=3D"ltr"><blockquote typ=
e=3D"cite">On Aug 24, 2022, at 05:46, Craig Raw via bitcoin-dev &lt;bitcoin-=
dev@lists.linuxfoundation.org&gt; wrote:<br><br></blockquote></div><blockquo=
te type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr">Hi all,<div><br>=
</div><div>I would&nbsp;like to propose a BIP that specifies a format&nbsp;f=
or the export and import of labels from a wallet. While transferring access t=
o funds across wallet applications has been made simple through standards su=
ch as BIP39, wallet&nbsp;labels remain siloed and difficult to extract despi=
te their value, particularly 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, input or output in the first column, and the label in=
 the second column. CSV was chosen for its wide accessibility, especially to=
 users without specific technical expertise. Similarly, the CSV file may be c=
ompressed using the ZIP format, and optionally encrypted using AES.</div><di=
v><br></div><div>The full text of the BIP can be found at&nbsp;<a href=3D"ht=
tps://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki">http=
s://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki</a> and=
 also copied below.</div><div><br></div><div>Feedback is appreciated.</div><=
div><br></div><div>Thanks,</div><div>Craig Raw</div><div><br></div><div>---<=
/div><div><br></div><div>&lt;pre&gt;<br>&nbsp; BIP: wallet-labels<br>&nbsp; L=
ayer: Applications<br>&nbsp; Title: Wallet Labels Export Format<br>&nbsp; Au=
thor: Craig Raw &lt;<a href=3D"mailto:craig@sparrowwallet.com">craig@sparrow=
wallet.com</a>&gt;<br>&nbsp; Comments-Summary: No comments yet.<br>&nbsp; Co=
mments-URI: <a href=3D"https://github.com/bitcoin/bips/wiki/Comments:BIP-wal=
let-labels">https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels<=
/a><br>&nbsp; Status: Draft<br>&nbsp; Type: Informational<br>&nbsp; Created:=
 2022-08-23<br>&nbsp; License: BSD-2-Clause<br>&lt;/pre&gt;<br><br>=3D=3DAbs=
tract=3D=3D<br><br>This document specifies a format for the export of labels=
 that may be attached to the transactions, addresses, input and outputs in a=
 wallet.<br><br>=3D=3DCopyright=3D=3D<br><br>This BIP is licensed under the B=
SD 2-clause license.<br><br>=3D=3DMotivation=3D=3D<br><br>The export and imp=
ort of funds across different Bitcoin wallet applications is well defined th=
rough standards such as BIP39, BIP32, BIP44 etc.<br>These standards are well=
 supported and allow users to move easily between different wallets.<br>Ther=
e is, however, no defined standard to transfer any labels the user may have a=
pplied to the transactions, addresses, inputs or outputs in their wallet.<br=
>The UTXO model that Bitcoin uses makes these labels particularly valuable a=
s they may indicate the source of funds, whether received externally or as a=
 result of change from a prior transaction.<br>In both cases, care must be t=
aken when spending to avoid undesirable leaks of private information.<br>Lab=
els 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 addition, by using common formats, t=
his BIP seeks to make manual or bulk management of labels accessible to user=
s without 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=
 possible, this BIP uses the comma separated values (CSV) format, which is w=
idely supported by consumer, business, and scientific applications.<br>Altho=
ugh the technical specification of CSV in RFC4180 is not always followed, th=
e application of the format in this BIP is simple enough that compatibility s=
hould not present a problem.<br>Moreover, the simplicity and forgiving natur=
e of CSV (over for example JSON) lends itself well to bulk label editing usi=
ng 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, w=
ith records containing two fields delimited by a comma.<br>The fields may be=
 quoted, but this is unnecessary, 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 i=
gnored on import.<br>Thereafter, each line represents a record that refers t=
o a label applied in the wallet.<br>The order in which these records appear i=
s not defined.<br><br>The first field in the record contains a reference to t=
he transaction, address, input or output in the wallet.<br>This is specified=
 as one of the following:<br>* Transaction ID (&lt;tt&gt;txid&lt;/tt&gt;)<br=
>* Address<br>* Input (rendered as &lt;tt&gt;txid&lt;index&lt;/tt&gt;)<br>* O=
utput (rendered as &lt;tt&gt;txid&gt;index&lt;/tt&gt; or &lt;tt&gt;txid:inde=
x&lt;/tt&gt;)<br><br>The second field contains the label applied to the refe=
rence. <br>Exporting applications may omit records with no labels or labels o=
f zero length.<br>Files exported should use the &lt;tt&gt;.csv&lt;/tt&gt; fi=
le extension.<br><br>In order to reduce file size while retaining wide acces=
sibility, the CSV file may be compressed using the ZIP file format, using th=
e &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 encryptio=
n, which is supported by numerous applications including Winzip and 7-zip. <=
br>In order to ensure that weak encryption does not proliferate, importers f=
ollowing 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 o=
f the wallet's extended public key (as defined by BIP32, with an &lt;tt&gt;x=
pub&lt;/tt&gt; header) should be used as the password.<br><br>=3D=3DImportin=
g=3D=3D<br><br>When importing, a naive algorithm may simply match against an=
y reference, but it is possible to disambiguate between transactions, addres=
ses, inputs and outputs. <br>For example in the following pseudocode:<br>&lt=
;pre&gt;<br>&nbsp; if reference length &lt; 64<br>&nbsp; &nbsp; Set address l=
abel<br>&nbsp; else if reference length =3D=3D 64<br>&nbsp; &nbsp; Set trans=
action label<br>&nbsp; else if reference contains '&lt;'<br>&nbsp; &nbsp; Se=
t input label<br>&nbsp; else<br>&nbsp; &nbsp; Set output label<br>&lt;/pre&g=
t;<br><br>Importing applications may truncate labels if necessary.<br><br>=3D=
=3DTest Vectors=3D=3D<br><br>The following fragment represents a wallet labe=
l export:<br>&lt;pre&gt;<br>Reference,Label<br>c3bdad6e7dcd7997e16a5b7b7cf4d=
8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E,Transaction<br>1A69TXnEM2ms9fMa=
Y9UuiJ7415X7xZaUSg,Address<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5=
fcbb2ad088f767b37b=E2=80=8E&lt;0,Input<br>c3bdad6e7dcd7997e16a5b7b7cf4d8f607=
9820ff2eedd5fcbb2ad088f767b37b=E2=80=8E&gt;0,Output<br>c3bdad6e7dcd7997e16a5=
b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=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>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></div></div></div></div></body></html>=

--Apple-Mail-486AE8F6-7A00-4009-9637-7B26BEE4B453--