Craig,

Thanks for the proposal.

How does this proposal compare with SLIP-0015, which provides encryption by 
default? Would it be worth exploring a merge of the two approaches?

https://github.com/satoshilabs/slips/blob/master/slip-0015.md

Clark

------- Original Message -------
On Wednesday, August 24th, 2022 at 4: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 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
>
> ---
>
> <pre>
> BIP: wallet-labels
> Layer: Applications
> Title: Wallet Labels Export Format
> Author: Craig Raw <cr...@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>
>
> ==Abstract==
>
> This document specifies a format for the export of labels that may be 
> attached to the transactions, addresses, input and outputs in a wallet.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> 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.
>
> ==Specification==
>
> 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 encrypted 
> with 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.
>
> ==Importing==
>
> 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:
> <pre>
> if reference length < 64
> Set address label
> else if reference length == 64
> Set transaction label
> else if reference contains '<'
> Set input label
> else
> Set output label
> </pre>
>
> Importing applications may truncate labels if necessary.
>
> ==Test Vectors==
>
> The following fragment represents a wallet label export:
> <pre>
> Reference,Label
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction
> 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎<0,Input
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎>0,Output
> c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output 
> (alternative)
> </pre>
>
> ==Reference Implementation==
>
> TBD
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to