{"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-24\n📝 Original message:Hi all,\n\nI would like to propose a BIP that specifies a format for the export and\nimport of labels from a wallet. While transferring access to funds across\nwallet applications has been made simple through standards such as BIP39,\nwallet labels remain siloed and difficult to extract despite their value,\nparticularly in a privacy context.\n\nThe proposed format is a simple two column CSV file, with the reference to\na transaction, address, input or output in the first column, and the label\nin the second column. CSV was chosen for its wide accessibility, especially\nto users without specific technical expertise. Similarly, the CSV file may\nbe compressed using the ZIP format, and optionally encrypted using AES.\n\nThe full text of the BIP can be found at\nhttps://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki\nand also copied below.\n\nFeedback is appreciated.\n\nThanks,\nCraig Raw\n\n---\n\n\u003cpre\u003e\n  BIP: wallet-labels\n  Layer: Applications\n  Title: Wallet Labels Export Format\n  Author: Craig Raw \u003ccraig at sparrowwallet.com\u003e\n  Comments-Summary: No comments yet.\n  Comments-URI:\nhttps://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels\n  Status: Draft\n  Type: Informational\n  Created: 2022-08-23\n  License: BSD-2-Clause\n\u003c/pre\u003e\n\n==Abstract==\n\nThis document specifies a format for the export of labels that may be\nattached to the transactions, addresses, input and outputs in a wallet.\n\n==Copyright==\n\nThis BIP is licensed under the BSD 2-clause license.\n\n==Motivation==\n\nThe export and import of funds across different Bitcoin wallet applications\nis well defined through standards such as BIP39, BIP32, BIP44 etc.\nThese standards are well supported and allow users to move easily between\ndifferent wallets.\nThere is, however, no defined standard to transfer any labels the user may\nhave applied to the transactions, addresses, inputs or outputs in their\nwallet.\nThe UTXO model that Bitcoin uses makes these labels particularly valuable\nas they may indicate the source of funds, whether received externally or as\na result of change from a prior transaction.\nIn both cases, care must be taken when spending to avoid undesirable leaks\nof private information.\nLabels provide valuable guidance in this regard, and have even become\nmandatory when spending in several Bitcoin wallets.\nAllowing users to export their labels in a standardized way ensures that\nthey do not experience lock-in to a particular wallet application.\nIn addition, by using common formats, this BIP seeks to make manual or bulk\nmanagement of labels accessible to users without specific technical\nexpertise.\n\n==Specification==\n\nIn order to make the import and export of labels as widely accessible as\npossible, this BIP uses the comma separated values (CSV) format, which is\nwidely supported by consumer, business, and scientific applications.\nAlthough the technical specification of CSV in RFC4180 is not always\nfollowed, the application of the format in this BIP is simple enough that\ncompatibility should not present a problem.\nMoreover, the simplicity and forgiving nature of CSV (over for example\nJSON) lends itself well to bulk label editing using spreadsheet and text\nediting tools.\n\nA CSV export of labels from a wallet must be a UTF-8 encoded text file,\ncontaining one record per line, with records containing two fields\ndelimited by a comma.\nThe fields may be quoted, but this is unnecessary, as the first comma in\nthe line will always be the delimiter.\nThe first line in the file is a header, and should be ignored on import.\nThereafter, each line represents a record that refers to a label applied in\nthe wallet.\nThe order in which these records appear is not defined.\n\nThe first field in the record contains a reference to the transaction,\naddress, input or output in the wallet.\nThis is specified as one of the following:\n* Transaction ID (\u003ctt\u003etxid\u003c/tt\u003e)\n* Address\n* Input (rendered as \u003ctt\u003etxid\u003cindex\u003c/tt\u003e)\n* Output (rendered as \u003ctt\u003etxid\u003eindex\u003c/tt\u003e or \u003ctt\u003etxid:index\u003c/tt\u003e)\n\nThe second field contains the label applied to the reference.\nExporting applications may omit records with no labels or labels of zero\nlength.\nFiles exported should use the \u003ctt\u003e.csv\u003c/tt\u003e file extension.\n\nIn order to reduce file size while retaining wide accessibility, the CSV\nfile may be compressed using the ZIP file format, using the \u003ctt\u003e.zip\u003c/tt\u003e\nfile extension.\nThis \u003ctt\u003e.zip\u003c/tt\u003e file may optionally be encrypted using either AES-128 or\nAES-256 encryption, which is supported by numerous applications including\nWinzip and 7-zip.\nIn order to ensure that weak encryption does not proliferate, importers\nfollowing this standard must refuse to import \u003ctt\u003e.zip\u003c/tt\u003e files encrypted\nwith the weaker Zip 2.0 standard.\nThe textual representation of the wallet's extended public key (as defined\nby BIP32, with an \u003ctt\u003expub\u003c/tt\u003e header) should be used as the password.\n\n==Importing==\n\nWhen importing, a naive algorithm may simply match against any reference,\nbut it is possible to disambiguate between transactions, addresses, inputs\nand outputs.\nFor example in the following pseudocode:\n\u003cpre\u003e\n  if reference length \u003c 64\n    Set address label\n  else if reference length == 64\n    Set transaction label\n  else if reference contains '\u003c'\n    Set input label\n  else\n    Set output label\n\u003c/pre\u003e\n\nImporting applications may truncate labels if necessary.\n\n==Test Vectors==\n\nThe following fragment represents a wallet label export:\n\u003cpre\u003e\nReference,Label\nc3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction\n1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address\nc3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\u003c0,Input\nc3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\u003e0,Output\nc3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output\n(alternative)\n\u003c/pre\u003e\n\n==Reference Implementation==\n\nTBD\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220824/025a538b/attachment.html\u003e"}