{"type":"rich","version":"1.0","author_name":"npub1qvg3k0w2c3ggh4wumg3pkzetfeqe9y4wgq7x5aaxz4ypjvap9vksr9t9zs","author_url":"https://nostr.ae/npub1qvg3k0w2c3ggh4wumg3pkzetfeqe9y4wgq7x5aaxz4ypjvap9vksr9t9zs","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-08-25\n📝 Original message:Thanks Clark - despite having worked in the Bitcoin wallet space for a\nnumber of years I have not come across SLIP-0015. I did try to find prior\nwork on this - this one escaped me.\n\nThat said, having reviewed SLIP-0015, I think it has different design\ngoals. For example, it requires private key derivation from seed, which\nmeans wallets functioning as coordinators cannot use the format without\naccess to the devices storing the private keys. It seems to me that wallet\nlabels are more privacy rather than security sensitive, and coordinators\nshould be able to import and export a wallet label format independently.\n\nSecondly, it uses JSON as a data format, which I wanted to avoid for\nreasons I'll describe in a separate reply in this thread. Finally (and this\nis minor as it could easily be extended) SLIP-0015 does not currently\nsupport transaction labels.\n\nCraig\n\nOn Wed, Aug 24, 2022 at 3:53 PM Clark Moody \u003cclark at clarkmoody.com\u003e wrote:\n\n\u003e Craig,\n\u003e\n\u003e Thanks for the proposal.\n\u003e\n\u003e How does this proposal compare with SLIP-0015, which provides encryption\n\u003e by default? Would it be worth exploring a merge of the two approaches?\n\u003e\n\u003e https://github.com/satoshilabs/slips/blob/master/slip-0015.md\n\u003e\n\u003e Clark\n\u003e\n\u003e ------- Original Message -------\n\u003e On Wednesday, August 24th, 2022 at 4:18 AM, Craig Raw via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi all,\n\u003e\n\u003e I would like to propose a BIP that specifies a format for the export and\n\u003e import of labels from a wallet. While transferring access to funds across\n\u003e wallet applications has been made simple through standards such as BIP39,\n\u003e wallet labels remain siloed and difficult to extract despite their value,\n\u003e particularly in a privacy context.\n\u003e\n\u003e The proposed format is a simple two column CSV file, with the reference to\n\u003e a transaction, address, input or output in the first column, and the label\n\u003e in the second column. CSV was chosen for its wide accessibility, especially\n\u003e to users without specific technical expertise. Similarly, the CSV file may\n\u003e be compressed using the ZIP format, and optionally encrypted using AES.\n\u003e\n\u003e The full text of the BIP can be found at\n\u003e https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki\n\u003e and also copied below.\n\u003e\n\u003e Feedback is appreciated.\n\u003e\n\u003e Thanks,\n\u003e Craig Raw\n\u003e\n\u003e ---\n\u003e\n\u003e \u003cpre\u003e\n\u003e BIP: wallet-labels\n\u003e Layer: Applications\n\u003e Title: Wallet Labels Export Format\n\u003e Author: Craig Raw \u003ccraig at sparrowwallet.com\u003e\n\u003e Comments-Summary: No comments yet.\n\u003e Comments-URI:\n\u003e https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels\n\u003e Status: Draft\n\u003e Type: Informational\n\u003e Created: 2022-08-23\n\u003e License: BSD-2-Clause\n\u003e \u003c/pre\u003e\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e This document specifies a format for the export of labels that may be\n\u003e attached to the transactions, addresses, input and outputs in a wallet.\n\u003e\n\u003e ==Copyright==\n\u003e\n\u003e This BIP is licensed under the BSD 2-clause license.\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e The export and import of funds across different Bitcoin wallet\n\u003e applications is well defined through standards such as BIP39, BIP32, BIP44\n\u003e etc.\n\u003e These standards are well supported and allow users to move easily between\n\u003e different wallets.\n\u003e There is, however, no defined standard to transfer any labels the user may\n\u003e have applied to the transactions, addresses, inputs or outputs in their\n\u003e wallet.\n\u003e The UTXO model that Bitcoin uses makes these labels particularly valuable\n\u003e as they may indicate the source of funds, whether received externally or as\n\u003e a result of change from a prior transaction.\n\u003e In both cases, care must be taken when spending to avoid undesirable leaks\n\u003e of private information.\n\u003e Labels provide valuable guidance in this regard, and have even become\n\u003e mandatory when spending in several Bitcoin wallets.\n\u003e Allowing users to export their labels in a standardized way ensures that\n\u003e they do not experience lock-in to a particular wallet application.\n\u003e In addition, by using common formats, this BIP seeks to make manual or\n\u003e bulk management of labels accessible to users without specific technical\n\u003e expertise.\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e In order to make the import and export of labels as widely accessible as\n\u003e possible, this BIP uses the comma separated values (CSV) format, which is\n\u003e widely supported by consumer, business, and scientific applications.\n\u003e Although the technical specification of CSV in RFC4180 is not always\n\u003e followed, the application of the format in this BIP is simple enough that\n\u003e compatibility should not present a problem.\n\u003e Moreover, the simplicity and forgiving nature of CSV (over for example\n\u003e JSON) lends itself well to bulk label editing using spreadsheet and text\n\u003e editing tools.\n\u003e\n\u003e A CSV export of labels from a wallet must be a UTF-8 encoded text file,\n\u003e containing one record per line, with records containing two fields\n\u003e delimited by a comma.\n\u003e The fields may be quoted, but this is unnecessary, as the first comma in\n\u003e the line will always be the delimiter.\n\u003e The first line in the file is a header, and should be ignored on import.\n\u003e Thereafter, each line represents a record that refers to a label applied\n\u003e in the wallet.\n\u003e The order in which these records appear is not defined.\n\u003e\n\u003e The first field in the record contains a reference to the transaction,\n\u003e address, input or output in the wallet.\n\u003e This is specified as one of the following:\n\u003e * Transaction ID (\u003ctt\u003etxid\u003c/tt\u003e)\n\u003e * Address\n\u003e * Input (rendered as \u003ctt\u003etxid\u003cindex\u003c/tt\u003e)\n\u003e * Output (rendered as \u003ctt\u003etxid\u003eindex\u003c/tt\u003e or \u003ctt\u003etxid:index\u003c/tt\u003e)\n\u003e\n\u003e The second field contains the label applied to the reference.\n\u003e Exporting applications may omit records with no labels or labels of zero\n\u003e length.\n\u003e Files exported should use the \u003ctt\u003e.csv\u003c/tt\u003e file extension.\n\u003e\n\u003e In order to reduce file size while retaining wide accessibility, the CSV\n\u003e file may be compressed using the ZIP file format, using the \u003ctt\u003e.zip\u003c/tt\u003e\n\u003e file extension.\n\u003e This \u003ctt\u003e.zip\u003c/tt\u003e file may optionally be encrypted using either AES-128\n\u003e or AES-256 encryption, which is supported by numerous applications\n\u003e including Winzip and 7-zip.\n\u003e In order to ensure that weak encryption does not proliferate, importers\n\u003e following this standard must refuse to import \u003ctt\u003e.zip\u003c/tt\u003e files encrypted\n\u003e with the weaker Zip 2.0 standard.\n\u003e The textual representation of the wallet's extended public key (as defined\n\u003e by BIP32, with an \u003ctt\u003expub\u003c/tt\u003e header) should be used as the password.\n\u003e\n\u003e ==Importing==\n\u003e\n\u003e When importing, a naive algorithm may simply match against any reference,\n\u003e but it is possible to disambiguate between transactions, addresses, inputs\n\u003e and outputs.\n\u003e For example in the following pseudocode:\n\u003e \u003cpre\u003e\n\u003e if reference length \u003c 64\n\u003e Set address label\n\u003e else if reference length == 64\n\u003e Set transaction label\n\u003e else if reference contains '\u003c'\n\u003e Set input label\n\u003e else\n\u003e Set output label\n\u003e \u003c/pre\u003e\n\u003e\n\u003e Importing applications may truncate labels if necessary.\n\u003e\n\u003e ==Test Vectors==\n\u003e\n\u003e The following fragment represents a wallet label export:\n\u003e \u003cpre\u003e\n\u003e Reference,Label\n\u003e\n\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction\n\u003e 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address\n\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\u003c0,Input\n\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\u003e0,Output\n\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output\n\u003e (alternative)\n\u003e \u003c/pre\u003e\n\u003e\n\u003e ==Reference Implementation==\n\u003e\n\u003e TBD\n\u003e\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220825/acdd8972/attachment-0001.html\u003e"}