From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8FE05C002D for ; Wed, 24 Aug 2022 09:19:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5B03A4026E for ; Wed, 24 Aug 2022 09:19:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5B03A4026E Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=oQGWcUFu 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0me9KYijQRpW for ; Wed, 24 Aug 2022 09:18:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 37ACD401B7 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by smtp4.osuosl.org (Postfix) with ESMTPS id 37ACD401B7 for ; Wed, 24 Aug 2022 09:18:58 +0000 (UTC) Received: by mail-lf1-x135.google.com with SMTP id n15so2068179lfe.3 for ; Wed, 24 Aug 2022 02:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=+L++2WAs50JizUuuSMMZnrm3enj0F1CUpGseGt0B+ug=; b=oQGWcUFu0KaQIvl+m+US0dKgL0ZiEePkDRYQoMNMRF+PWBZmjtX/jJ9uhqKrjXzr67 jOb/0jNpqf0U22UpLzg82QyJ7cVMiMyQTvjJivWk3Sg1hOVeczKX7N4uVy/clynS5jG7 E0StW9+b9zOkTgCB5Ty1BNNrtRfzA8As9d/6ERPFehKqUmZYZ/17ZjSvDFZDrUY3+cSx xA37nXWFA9eTSyhirHi2kASsi227IsKfBdjrmFxUJ4C6Xirck4osoDJlG2eVjZQ6FPky JSQ9+TwQGD0J/UtBkNyuHjnSJIV/BKN0SB67OyQD+4zmZMLSlzNKTZgOAkBc6DLV59qM 6WAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=+L++2WAs50JizUuuSMMZnrm3enj0F1CUpGseGt0B+ug=; b=DsCjRmDxCoGKc0dyogsSnn/BNjZ89w04Db6NpH07o+FTYHnFXblWNCytT1czWvrk5z mcL80t/GSV3sb1rtYvEItRFSC9f3XZmF8QFPrw9WlrOAIlxDaWC8icVdyq/1sbYG12E7 jBPv0Ug+gvxjwivdO04FyW8c0Z96Vo2Ih6wxr6egJrh6n5h5FtwQZIsGZWkbmOv1ua7k xmBAULHm4F+2mvFJhs3NOwS4/jFOJr6Mt27G2a1rFONjMb6aoJtLbYx/oZsghaAhMZI7 Fx2UR/IZtIJDOJpbjNqkhcBaattzf54v8ZIBgNmOhvvWY66htuqGL6+yWGUxaLw1objd yn4Q== X-Gm-Message-State: ACgBeo1dPPZLv13VGkZoficOwTuEwX/OqUvsEHOsu4ZMyEPsWdWHWkQw 0d34f5z+4Plx3KM4QQexA5NodENt3kG0+LZxZq8WAkn6vRQ= X-Google-Smtp-Source: AA6agR7/TuqJn2oLHH5g+fV2gKVhkTGsPsGFMqaZBmJEHddyaTUvg0wCqJC1aINkbvBX/OjaKVHw3pdYQiy3u5CwkKc= X-Received: by 2002:a05:6512:33c2:b0:492:d679:f8ec with SMTP id d2-20020a05651233c200b00492d679f8ecmr6440206lfg.240.1661332735101; Wed, 24 Aug 2022 02:18:55 -0700 (PDT) MIME-Version: 1.0 From: Craig Raw Date: Wed, 24 Aug 2022 11:18:43 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000087903905e6f92b4f" X-Mailman-Approved-At: Wed, 24 Aug 2022 09:45:58 +0000 Subject: [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: Wed, 24 Aug 2022 09:19:00 -0000 --00000000000087903905e6f92b4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 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 --- 
  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-labels
  Status: Draft
  Type: Informational
  Created: 2022-08-23
  License: BSD-2-Clause
=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, BIP44 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 may 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 leaks 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 (txid) * Address * Input (rendered as txid) * Output (rendered as txid>index or txid:index) 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 .csv 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 .zip file extension. This .zip 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 .zip files encrypted with 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. =3D=3DImporting=3D=3D When importing, a naive algorithm may simply match against any reference, but it is possible to disambiguate between transactions, addresses, inputs and outputs. 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
Importing applications may truncate labels if necessary. =3D=3DTest Vectors=3D=3D The following fragment represents a wallet label export: 
Reference,Label
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E,T=
ransaction
1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E<0=
,Input
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E>0=
,Output
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E:0=
,Output
(alternative)
=3D=3DReference Implementation=3D=3D TBD --00000000000087903905e6f92b4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I would=C2=A0like to propose a = BIP that specifies a format=C2=A0for 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=C2=A0labels remain= siloed and difficult to extract despite their value, particularly in a pri= vacy context.

The proposed format is a simple two = column CSV file, with the reference to a transaction, address, input or out= put 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 compressed using the ZIP format,= and optionally encrypted using AES.

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

Feedback is appreciated.

Thanks,=
Craig Raw

---

= <pre>
=C2=A0 BIP: wallet-labels
=C2=A0 Layer: Applications
= =C2=A0 Title: Wallet Labels Export Format
=C2=A0 Author: Craig Raw <<= a href=3D"mailto:craig@sparrowwallet.com">craig@sparrowwallet.com>=C2=A0 Comments-Summary: No comments yet.
=C2=A0 Comments-URI: https:= //github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels
=C2=A0 Sta= tus: Draft
=C2=A0 Type: Informational
=C2=A0 Created: 2022-08-23
= =C2=A0 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-claus= e license.

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

The export and import of fu= nds across different Bitcoin wallet applications is well defined through st= andards such as BIP39, BIP32, BIP44 etc.
These standards are well suppor= ted and allow users to move easily between different wallets.
There is, = however, no defined standard to transfer any labels the user may have appli= ed to the transactions, addresses, inputs or outputs in their wallet.
Th= e 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 t= aken when spending to avoid undesirable leaks of private information.
La= bels provide valuable guidance in this regard, and have even become mandato= ry when spending in several Bitcoin wallets.
Allowing users to export th= eir labels in a standardized way ensures that they do not experience lock-i= n to a particular wallet application.
In addition, by using common forma= ts, this BIP seeks to make manual or bulk management of labels accessible t= o users without specific technical expertise.

=3D=3DSpecification=3D= =3D

In order to make the import and export of labels as widely acces= sible as possible, this BIP uses the comma separated values (CSV) format, w= hich is widely supported by consumer, business, and scientific applications= .
Although the technical specification of CSV in RFC4180 is not always f= ollowed, the application of the format in this BIP is simple enough that co= mpatibility should not present a problem.
Moreover, the simplicity and f= orgiving nature of CSV (over for example JSON) lends itself well to bulk la= bel 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 r= ecord 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 t= he line will always be the delimiter.
The first line in the file is a he= ader, and should be ignored on import.
Thereafter, each line represents = a record that refers to a label applied in the wallet.
The order in whic= h these records appear is not defined.

The first field in the record= contains a reference to the transaction, address, input or output in the w= allet.
This is specified as one of the following:
* Transaction ID (&= lt;tt>txid</tt>)
* Address
* Input (rendered as <tt>tx= id<index</tt>)
* Output (rendered as <tt>txid>index<= ;/tt> or <tt>txid:index</tt>)

The second field contai= ns the label applied to the reference.
Exporting applications may omit = records with no labels or labels of zero length.
Files exported should u= se the <tt>.csv</tt> file extension.

In order to reduce = file size while retaining wide accessibility, the CSV file may be compresse= d using the ZIP file format, using the <tt>.zip</tt> file exten= sion.
This <tt>.zip</tt> file may optionally be encrypted us= ing either AES-128 or AES-256 encryption, which is supported by numerous ap= plications including Winzip and 7-zip.
In order to ensure that weak enc= ryption does not proliferate, importers following this standard must refuse= to import <tt>.zip</tt> files encrypted with the weaker Zip 2.= 0 standard.
The textual representation of the wallet's extended publ= ic key (as defined by BIP32, with an <tt>xpub</tt> header) shou= ld be used as the password.

=3D=3DImporting=3D=3D

When import= ing, a naive algorithm may simply match against any reference, but it is po= ssible to disambiguate between transactions, addresses, inputs and outputs.=
For example in the following pseudocode:
<pre>
=C2=A0 if r= eference length < 64
=C2=A0 =C2=A0 Set address label
=C2=A0 else i= f reference length =3D=3D 64
=C2=A0 =C2=A0 Set transaction label
=C2= =A0 else if reference contains '<'
=C2=A0 =C2=A0 Set input la= bel
=C2=A0 else
=C2=A0 =C2=A0 Set output label
</pre>
Importing applications may truncate labels if necessary.

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

The following fragment represents a wallet label expo= rt:
<pre>
Reference,Label
c3bdad6e7dcd7997e16a5b7b7cf4d8f607= 9820ff2eedd5fcbb2ad088f767b37b=E2=80=8E,Transaction
1A69TXnEM2ms9fMaY9Uu= iJ7415X7xZaUSg,Address
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcb= b2ad088f767b37b=E2=80=8E<0,Input
c3bdad6e7dcd7997e16a5b7b7cf4d8f60798= 20ff2eedd5fcbb2ad088f767b37b=E2=80=8E>0,Output
c3bdad6e7dcd7997e16a5b= 7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E:0,Output (alternative)<= br></pre>

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

TBD
<= /div>


--00000000000087903905e6f92b4f--