From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id AF324C002D for ; 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 ; 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 ; 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 ; 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 Mime-Version: 1.0 (1.0) Date: Mon, 29 Aug 2022 15:52:17 -0400 Message-Id: References: In-Reply-To: To: Craig Raw , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 
>   BIP: wallet-labels
>   Layer: Applications
>   Title: Wallet Labels Export Format
>   Author: Craig Raw 
>   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
>
>=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 (txid) > * Address > * Input (rendered as txid) > * Output (rendered as txid>index or txid:index) >=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 .csv 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 .zip fil= e extension. > This .zip 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 .zip 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 xpub 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: > 
>   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
>
>=20 > Importing applications may truncate labels if necessary. >=20 > =3D=3DTest Vectors=3D=3D >=20 > The following fragment represents a wallet label export: > 
> 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)
>
>=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
Hello,

Tha= nks for this proposal.

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.

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.

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.

In regards to encryption, AES o= n 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.linuxfoundation.org> wrote:

=EF=BB=BF
Hi all,

=
I would like to propose a BIP that specifies a format 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 labels remain siloed and difficult to extract despi= te their value, particularly in a privacy context.

= 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.

The full text of the BIP can be found at http= s://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki and= also copied below.

Feedback is appreciated.
<= div>
Thanks,
Craig Raw

---<= /div>

<pre>
  BIP: wallet-labels
  L= ayer: Applications
  Title: Wallet Labels Export Format
  Au= thor: Craig Raw <craig@sparrow= wallet.com>
  Comments-Summary: No comments yet.
  Co= mments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels<= /a>
  Status: Draft
  Type: Informational
  Created:= 2022-08-23
  License: BSD-2-Clause
</pre>

=3D=3DAbs= tract=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 B= SD 2-clause license.

=3D=3DMotivation=3D=3D

The export and imp= ort of funds across different Bitcoin wallet applications is well defined th= rough standards such as BIP39, BIP32, BIP44 etc.
These standards are well= supported and allow users to move easily between different wallets.
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.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 t= aken when spending to avoid undesirable leaks of private information.
Lab= els 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, t= his BIP seeks to make manual or bulk management of labels accessible to user= s 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 w= idely supported by consumer, business, and scientific applications.
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.
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.

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.
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 i= gnored on import.
Thereafter, each line represents a record that refers t= o a label applied in the wallet.
The order in which these records appear i= s not defined.

The first field in the record contains a reference to t= he 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>)
* O= utput (rendered as <tt>txid>index</tt> or <tt>txid:inde= x</tt>)

The second field contains the label applied to the refe= rence.
Exporting applications may omit records with no labels or labels o= f zero length.
Files exported should use the <tt>.csv</tt> fi= le extension.

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 <tt>.zip</tt> file extension.
This <tt>.zip</tt>= ; 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 <tt>.zip</tt> files= encrypted with the weaker Zip 2.0 standard.
The textual representation o= f the wallet's extended public key (as defined by BIP32, with an <tt>x= pub</tt> header) should be used as the password.

=3D=3DImportin= g=3D=3D

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.
For example in the following pseudocode:
<= ;pre>
  if reference length < 64
    Set address l= abel
  else if reference length =3D=3D 64
    Set trans= action label
  else if reference contains '<'
    Se= t input label
  else
    Set output label
</pre&g= t;

Importing applications may truncate labels if necessary.

=3D= =3DTest Vectors=3D=3D

The following fragment represents a wallet labe= l export:
<pre>
Reference,Label
c3bdad6e7dcd7997e16a5b7b7cf4d= 8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E,Transaction
1A69TXnEM2ms9fMa= Y9UuiJ7415X7xZaUSg,Address
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5= fcbb2ad088f767b37b=E2=80=8E<0,Input
c3bdad6e7dcd7997e16a5b7b7cf4d8f607= 9820ff2eedd5fcbb2ad088f767b37b=E2=80=8E>0,Output
c3bdad6e7dcd7997e16a5= b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E:0,Output (alternative)<= br></pre>

=3D=3DReference Implementation=3D=3D

TBD


_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /span>
= --Apple-Mail-486AE8F6-7A00-4009-9637-7B26BEE4B453--