From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id DC38CC002D for ; Sat, 27 Aug 2022 22:20:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id A243D8248F for ; Sat, 27 Aug 2022 22:20:50 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A243D8248F Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=jlfllXPL 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UUuw-0Pd_49 for ; Sat, 27 Aug 2022 22:20:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D2AE6823EB Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by smtp1.osuosl.org (Postfix) with ESMTPS id D2AE6823EB for ; Sat, 27 Aug 2022 22:20:48 +0000 (UTC) Received: by mail-vs1-xe2b.google.com with SMTP id m66so4941302vsm.12 for ; Sat, 27 Aug 2022 15:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=HJU0xHX6aGNdCerYeIyI1qy3fE5EdFlGKLn/YLs1rbg=; b=jlfllXPLZTTe/fy6tdvWVzVfSRUrC5gVjSBaMwelFJIL1bI0PfKKjNi0K2o2M8ydPQ S/SLj6w4ELnhduN1paMf9Yz+TrZ87usMNu01UoBvtUWySfAES3H+6d5/tbG54NXEkMSX AF+k9gLDyagNJgiWr+VNAhD4C6PTKnoqqvnTdvvWcGDjfGzikR+z0VrMO+WcOKSlW+TF x1r40yVLj3XBpcfDoKDeqK8gdF0t9S/pKFk/ZX6+oegm/agKZPziyn9eVjSm/e20kC0p 7BNeNEHWSqkvAA5Teb2GfIw6A7BNzao5Ckmxp4vqmh6pw4scsHq0X382QNXQRA30BhLW YS0A== 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=HJU0xHX6aGNdCerYeIyI1qy3fE5EdFlGKLn/YLs1rbg=; b=zYuLNvNawQjmVkUPJZ91NKidMXrDyNoLvyesPhoclRdMeFSgxs+oti96fKSQrXrRqh 0UKtpalWg17K1hR1H2gva1N8VnziBFfp9rEOpA6JplxPoyYVRKedFXE3SQ94QJFk2T6n 5fwleX9oXqkoSDjMob8+GkYrkJOltEj2z0n8T+Tv2MBiDkRJALOZsXZXFMQI3bHZwEbP pyW9rXovRBDJ4A2fRUBLFJdkz54reZcql6mwpKMz3sC5wJqVOJ8Lv4vmejpKNzxZicHw tYbhzX+NseWrQMm91A/7Waz+YY4xnbIO1Om2s1xFRGrW54f9TDMePT2+Lq0nqVBMVdqN DurQ== X-Gm-Message-State: ACgBeo36HxGq/X5vMuiFVYBwpi63j0QSXGnQIZ8RGzQAkfwhpp7OyUvR cBb2XbswygUyEnlwazylkyP3JYSsAw0z01W/yJk= X-Google-Smtp-Source: AA6agR58FIOJBVGjvPXtxUNuSUknN7Bw7tCxmYqQCptN83HbpCthUavB8wHqm/yJ1oQkQbWHhiqlavwIr7XleHIU4I4= X-Received: by 2002:a05:6102:c8a:b0:390:232a:8f29 with SMTP id f10-20020a0561020c8a00b00390232a8f29mr1631742vst.81.1661638847590; Sat, 27 Aug 2022 15:20:47 -0700 (PDT) MIME-Version: 1.0 References: <1UV4d_Y74sQ_C8l5s6_gwZOOaFcB0hWnWYWl8TJ_PFs9bQ-fb_w_CYZjZOom2JJ0CSC6-w-Xi999ocafkWa7Mkz0MzsCs2Vg91M5to2fafA=@protonmail.com> <9LXjLLr8ItwnB6bLt8Ozm21J0m11yiTghdXAAzpEzVKP3l5a9jtRRzJ90SFFbPwmyAV2yuzn5Y9r1wSiEWqbt7evbx9sSLF-EG1ZS__D0yM=@clarkmoody.com> In-Reply-To: <9LXjLLr8ItwnB6bLt8Ozm21J0m11yiTghdXAAzpEzVKP3l5a9jtRRzJ90SFFbPwmyAV2yuzn5Y9r1wSiEWqbt7evbx9sSLF-EG1ZS__D0yM=@clarkmoody.com> From: Billy Tetrud Date: Sat, 27 Aug 2022 17:20:31 -0500 Message-ID: To: Clark Moody , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000041755b05e74071a7" X-Mailman-Approved-At: Sat, 27 Aug 2022 22:31:10 +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: Sat, 27 Aug 2022 22:20:51 -0000 --00000000000041755b05e74071a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it might be a good idea to record something that can directly connect the list of labels with the correct wallet. Imagine someone backs up a bunch of label files and then forgets which wallet they apply to. Sure you could probably look through the list of transactions, addresses, etc and compare against those contained in the actual wallet, but this would be sort of messy and potentially inefficient. It might be useful to include a hash of the wallet descriptor (hash for privacy) that can be compared against potential matching wallet descriptors. On Fri, Aug 26, 2022 at 2:46 AM Clark Moody via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Having previously developed an export format[1] for general cryptocurrenc= y > transaction information, I can attest to the value of the human-readable > CSV. I was careful to mention the RFC 4180 spec so that implementations > could avoid the pitfalls of incorrect CSV encoding. > > [1]: https://github.com/harmony-csv/harmony > > Clark > > ------- Original Message ------- > On Thursday, August 25th, 2022 at 3:59 AM, Craig Raw via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Thanks for your thoughts Ryan. > > Without reference to the quality feedback on this proposal, I was aware > when submitting it for review that it provides an excellent opportunity f= or > bike shedding. As developers, we have all experienced frustration with da= ta > formats. One thing that I did not perhaps make clear enough is that this > format is not solely intended for developers, but general users who are > probably not well represented on this list. > > While doing research for this proposal I spoke to several professional > users of Sparrow Wallet (who are not developers). They all expressed a > desire for the format to integrate with their business processes, which a= re > driven by business tools such as Excel. Labelling provides an important > function in UTXO and address management in these scenarios, and needs to = be > accessible and manageable outside of wallet software. > > If this is to be achieved, it immediately rules out JSON as a data format= . > Not only is JSON limited to editing only through specific software or tex= t > editors, but (in the latter case) it is fragile enough that a single > missing character can cause an entire file to fail parsing. CSV is more > forgiving in this regard. With respect to your comments on escaping, my > expectation would be that developers will be using a mature CSV library > rather than handling character escaping themselves. I would rather propos= e > a format that is generally usable, even if occasionally a label is escape= d > incorrectly. > > Finally, I'll note that CSV files are already common and uncontroversial > in Bitcoin wallet software. Bitcoin Core, Electrum, Sparrow (and no doubt > many others) already export addresses and/or transactions with their labe= ls > as CSV files. This proposal simply attempts to create a standard for > importing and exporting all the labels in a wallet. > > Craig > > On Wed, Aug 24, 2022 at 9:01 PM wrote: > >> I'd strongly suggest not using CSV. Especially for a standard. I've >> worked with it as an interchange format many a times, and it's always be= en >> a clusterfuck. >> >> Right off the bat, you have stuff like "The fields may be quoted, but >> this is unnecessary as the first comma in the line will always be the >> delimiter" which invariably leads to some implementations doing it, some >> implementations not doing it, and others that are intolerant of the othe= r >> way. >> >> 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's quoted and escape quotes, and others >> will assume 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 >> pain. >> >> 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 i= s >> the way to go. >> >> { "tx": "c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37= b=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 acros= s >> 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 encrypte= d >> 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, BIP= 44 >> etc. >> These standards are well supported and allow users to move easily betwee= n >> 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 th= eir >> wallet. >> The UTXO model that Bitcoin uses makes these labels particularly valuabl= e >> 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 i= s >> 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 tha= t >> 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 encryp= ted >> 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, inpu= ts >> 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,Transaction
>> 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 >> >> >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000041755b05e74071a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it might be a good idea to record something that c= an directly connect the list of labels with the correct wallet. Imagine som= eone backs up a bunch of label files and then forgets which wallet they app= ly to. Sure you could probably look through the list of transactions, addre= sses, etc and compare against those contained in the actual=C2=A0wallet, bu= t this would be sort of messy and potentially inefficient. It might be usef= ul to include a hash of the wallet descriptor (hash for privacy) that can b= e compared against potential matching wallet descriptors.

On Fri, Aug 26, 20= 22 at 2:46 AM Clark Moody via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> w= rote:
Having previously developed an export= format[1] for general cryptocurrency transaction information, I can attest= to the value of the human-readable CSV. I was careful to mention the RFC 4= 180 spec so that implementations could avoid the pitfalls of incorrect CSV = encoding.

[1]: https://github.com/harmony-csv/harmony

Cl= ark
=20
=20

------- Original Message -------
On Thursday, August 25th, 2022 at 3:59 AM, Craig Raw via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org> wrote:

Thanks for your thoughts Ryan.

<= div>Without reference to the quality feedback on this proposal, I was aware= when submitting it for review that it provides an excellent opportunity fo= r bike shedding. As developers, we have all experienced frustration with da= ta formats. One thing that I did not perhaps make clear enough is that this= format is not solely intended for developers, but general users who are pr= obably not well represented on this list.

While do= ing research for this proposal I spoke to several professional users of Spa= rrow Wallet (who are not developers). They all expressed a desire for the f= ormat to integrate with their business processes, which are driven by busin= ess tools such as Excel. Labelling provides an important function in UTXO a= nd address management in these scenarios, and needs to be accessible and ma= nageable outside of wallet software.

If this is to= be achieved, it immediately rules out JSON as a data format. Not only is J= SON limited to editing only through specific software or text editors, but = (in the latter case) it is fragile enough that a single missing character c= an cause an entire file to fail parsing. CSV is more forgiving in this rega= rd. With respect to your comments on escaping, my expectation would be that= developers will be using a mature CSV library rather than handling charact= er escaping themselves. I would rather propose a format that is generally u= sable, even if occasionally a label is escaped incorrectly.

<= /div>
Finally, I'll note that CSV files are already common and unco= ntroversial in Bitcoin wallet software. Bitcoin Core, Electrum, Sparrow (an= d no doubt many others) already export addresses and/or transactions with t= heir labels as CSV files. This proposal simply attempts to create a standar= d for importing and exporting all the labels in a wallet.

Craig

On Wed, Aug 24, 2022 at 9:01 PM <rhavar@protonmail.com> wrote:
I'= ;d strongly suggest not using CSV. Especially for a standard. I've work= ed 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 this is unnecessary as the first comma = in the line will always be the delimiter" which invariably lead= s to some implementations doing it, some implementations not doing it, and = others that are intolerant of the other way.

And you have also mad= e the classic mistake of not strictly defining escape rules. So everyone wi= ll pick their own (e.g. some will \, escape commas, others will not cause i= t's quoted and escape quotes, and others will assume no escaping is req= uired since its the last column in a csv).

Over time it morphs into= its own mini-monster that introduces so much pain.

On a similar not= e, allowing alternatives (like: txid>index vs txid:index) provides= no benefit, but creates additional work for implementations (who quite lik= ely 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": "c3bdad6e7dcd7997e16= a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E", "label&q= uot;: "wow, such label" }
{ "tx: "c3bdad6e7dcd7997e16a5b7b7cf4= d8f6079820ff2eedd5fcbb2ad088f767b37b", "txout": 4, "lab= el": "omg this is so easy to parse" }
{ "tx: "c3bdad6e7dcd79= 97e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b", "txin":= 0, "label": "wow this is going to be extensible as well&quo= t; }



-Ryan

------- Original Message -------
On Wednesday, August 24th, 2022 at 2:18 AM, Craig Raw via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:

Hi all,

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.

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.

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

Feedback i= s 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/bip= s/wiki/Comments:BIP-wallet-labels
Status: Draft
Type: Informa= tional
Created: 2022-08-23
License: BSD-2-Clause
</pre><= br>
=3D=3DAbstract=3D=3D

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.

=3D=3DCopyright=3D=3D

This BIP is = licensed under the BSD 2-clause license.

=3D=3DMotivation=3D=3D
<= br>The export and import of funds across different Bitcoin wallet applicati= ons is well defined through standards such as BIP39, BIP32, BIP44 etc.
T= hese standards are well supported and allow users to move easily between di= fferent 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 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.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.<= br>Allowing users to export their labels in a standardized way ensures that= they do not experience lock-in to a particular wallet application.
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.=

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

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

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.
The fields may be quoted, but this is unnece= ssary, 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.
The= reafter, each line represents a record that refers to a label applied in th= e wallet.
The order in which these records appear is not defined.
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 fol= lowing:
* Transaction ID (<tt>txid</tt>)
* Address
* I= nput (rendered as <tt>txid<index</tt>)
* Output (rendered= as <tt>txid>index</tt> or <tt>txid:index</tt>)<= br>
The second field contains the label applied to the reference.
Ex= porting applications may omit records with no labels or labels of zero leng= th.
Files exported should use the <tt>.csv</tt> file extensi= on.

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, whi= ch is supported by numerous applications including Winzip and 7-zip.
In= order to ensure that weak encryption does not proliferate, importers follo= wing this standard must refuse to import <tt>.zip</tt> files en= crypted with the weaker Zip 2.0 standard.
The textual representation of = the wallet's extended public key (as defined by BIP32, with an <tt&g= t;xpub</tt> header) should be used as the password.

=3D=3DImpo= rting=3D=3D

When importing, a naive algorithm may simply match again= st any reference, but it is possible to disambiguate between transactions, = addresses, inputs 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
el= se if reference contains '<'
Set input label
else Set output label
</pre>

Importing applications may tru= ncate labels if necessary.

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

The follo= wing fragment represents a wallet label export:
<pre>
Reference= ,Label
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b= =E2=80=8E,Transaction
1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
c3bd= ad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b=E2=80=8E<0,= Input
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b= =E2=80=8E>0,Output
c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb= 2ad088f767b37b=E2=80=8E:0,Output (alternative)
</pre>

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

TBD

<= br>


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000041755b05e74071a7--