{"type":"rich","version":"1.0","author_name":"npub1glk4wtcgyl40v0zr2sz4vsxg5c00zx3ffrf3amr362pgx3fcd39q8l5ays","author_url":"https://nostr.ae/npub1glk4wtcgyl40v0zr2sz4vsxg5c00zx3ffrf3amr362pgx3fcd39q8l5ays","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-08-25\n📝 Original message:\u003e Not only is JSON limited to editing only through specific software or text 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.\n\nI think quite simply: A forgiving format is not appropriate for a standard.\n\nIt'd be hard to understate how much extra and pointless effort it creates for everyone, and every implementation ends up creating its own defacto standard for what it produces and accepts. Even doing something as simple as adding an extra column will not be possible in the future because it'll break comparability with previous parsers.\n\nI've literally worked on projects where the csv parser has evolved into scan-ahead to use heuristics to understand \"rules\" of a csv file, and then do line-by-line heuristics to override those rules in pathological cases. Makes a bit of sense when you're trying to achieve 30 years of backwards compatibility. Doesn't make sense for much else..\n\nIf your application users really like csv, then introduce an application-specific import-from-csv and export-to-csv with your own rules.\n-Ryan\n\n------- Original Message -------\nOn Thursday, August 25th, 2022 at 1:59 AM, Craig Raw \u003ccraigraw at gmail.com\u003e wrote:\n\n\u003e Thanks for your thoughts Ryan.\n\u003e\n\u003e Without reference to the quality feedback on this proposal, I was aware when submitting it for review that it provides an excellent opportunity for bike shedding. As developers, we have all experienced frustration with data 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.\n\u003e\n\u003e 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 are 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.\n\u003e\n\u003e 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 text 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 propose a format that is generally usable, even if occasionally a label is escaped incorrectly.\n\u003e\n\u003e 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 labels as CSV files. This proposal simply attempts to create a standard for importing and exporting all the labels in a wallet.\n\u003e\n\u003e Craig\n\u003e\n\u003e On Wed, Aug 24, 2022 at 9:01 PM \u003crhavar at protonmail.com\u003e wrote:\n\u003e\n\u003e\u003e 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 been a clusterfuck.\n\u003e\u003e\n\u003e\u003e 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 other way.\n\u003e\u003e\n\u003e\u003e 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).\n\u003e\u003e\n\u003e\u003e Over time it morphs into its own mini-monster that introduces so much pain.\n\u003e\u003e\n\u003e\u003e On a similar note, allowing alternatives (like: txid\u003eindex vs txid:index) provides no benefit, but creates additional work for implementations (who quite likely only test formats they produce) and future incompatibilities.\n\u003e\u003e\n\u003e\u003e I know everyone loves to hate on it, but really (line-separated?) json is the way to go.\n\u003e\u003e\n\u003e\u003e { \"tx\": \"c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\", \"label\": \"wow, such label\" }\n\u003e\u003e { \"tx: \"c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b\", \"txout\": 4, \"label\": \"omg this is so easy to parse\" }\n\u003e\u003e { \"tx: \"c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b\", \"txin\": 0, \"label\": \"wow this is going to be extensible as well\" }\n\u003e\u003e\n\u003e\u003e -Ryan\n\u003e\u003e\n\u003e\u003e ------- Original Message -------\n\u003e\u003e On Wednesday, August 24th, 2022 at 2:18 AM, Craig Raw via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi all,\n\u003e\u003e\u003e\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Feedback is appreciated.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Thanks,\n\u003e\u003e\u003e Craig Raw\n\u003e\u003e\u003e\n\u003e\u003e\u003e ---\n\u003e\u003e\u003e\n\u003e\u003e\u003e \u003cpre\u003e\n\u003e\u003e\u003e BIP: wallet-labels\n\u003e\u003e\u003e Layer: Applications\n\u003e\u003e\u003e Title: Wallet Labels Export Format\n\u003e\u003e\u003e Author: Craig Raw \u003ccraig at sparrowwallet.com\u003e\n\u003e\u003e\u003e Comments-Summary: No comments yet.\n\u003e\u003e\u003e Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-wallet-labels\n\u003e\u003e\u003e Status: Draft\n\u003e\u003e\u003e Type: Informational\n\u003e\u003e\u003e Created: 2022-08-23\n\u003e\u003e\u003e License: BSD-2-Clause\n\u003e\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Abstract==\n\u003e\u003e\u003e\n\u003e\u003e\u003e This document specifies a format for the export of labels that may be attached to the transactions, addresses, input and outputs in a wallet.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Copyright==\n\u003e\u003e\u003e\n\u003e\u003e\u003e This BIP is licensed under the BSD 2-clause license.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Motivation==\n\u003e\u003e\u003e\n\u003e\u003e\u003e The export and import of funds across different Bitcoin wallet applications is well defined through standards such as BIP39, BIP32, BIP44 etc.\n\u003e\u003e\u003e These standards are well supported and allow users to move easily between different wallets.\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e In both cases, care must be taken when spending to avoid undesirable leaks of private information.\n\u003e\u003e\u003e Labels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets.\n\u003e\u003e\u003e Allowing users to export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application.\n\u003e\u003e\u003e In addition, by using common formats, this BIP seeks to make manual or bulk management of labels accessible to users without specific technical expertise.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Specification==\n\u003e\u003e\u003e\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e The fields may be quoted, but this is unnecessary, as the first comma in the line will always be the delimiter.\n\u003e\u003e\u003e The first line in the file is a header, and should be ignored on import.\n\u003e\u003e\u003e Thereafter, each line represents a record that refers to a label applied in the wallet.\n\u003e\u003e\u003e The order in which these records appear is not defined.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The first field in the record contains a reference to the transaction, address, input or output in the wallet.\n\u003e\u003e\u003e This is specified as one of the following:\n\u003e\u003e\u003e * Transaction ID (\u003ctt\u003etxid\u003c/tt\u003e)\n\u003e\u003e\u003e * Address\n\u003e\u003e\u003e * Input (rendered as \u003ctt\u003etxid\u003cindex\u003c/tt\u003e)\n\u003e\u003e\u003e * Output (rendered as \u003ctt\u003etxid\u003eindex\u003c/tt\u003e or \u003ctt\u003etxid:index\u003c/tt\u003e)\n\u003e\u003e\u003e\n\u003e\u003e\u003e The second field contains the label applied to the reference.\n\u003e\u003e\u003e Exporting applications may omit records with no labels or labels of zero length.\n\u003e\u003e\u003e Files exported should use the \u003ctt\u003e.csv\u003c/tt\u003e file extension.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In order to reduce file size while retaining wide accessibility, the CSV file may be compressed using the ZIP file format, using the \u003ctt\u003e.zip\u003c/tt\u003e file extension.\n\u003e\u003e\u003e This \u003ctt\u003e.zip\u003c/tt\u003e file may optionally be encrypted using either AES-128 or AES-256 encryption, which is supported by numerous applications including Winzip and 7-zip.\n\u003e\u003e\u003e In order to ensure that weak encryption does not proliferate, importers following this standard must refuse to import \u003ctt\u003e.zip\u003c/tt\u003e files encrypted with the weaker Zip 2.0 standard.\n\u003e\u003e\u003e The textual representation of the wallet's extended public key (as defined by BIP32, with an \u003ctt\u003expub\u003c/tt\u003e header) should be used as the password.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Importing==\n\u003e\u003e\u003e\n\u003e\u003e\u003e When importing, a naive algorithm may simply match against any reference, but it is possible to disambiguate between transactions, addresses, inputs and outputs.\n\u003e\u003e\u003e For example in the following pseudocode:\n\u003e\u003e\u003e \u003cpre\u003e\n\u003e\u003e\u003e if reference length \u003c 64\n\u003e\u003e\u003e Set address label\n\u003e\u003e\u003e else if reference length == 64\n\u003e\u003e\u003e Set transaction label\n\u003e\u003e\u003e else if reference contains '\u003c'\n\u003e\u003e\u003e Set input label\n\u003e\u003e\u003e else\n\u003e\u003e\u003e Set output label\n\u003e\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Importing applications may truncate labels if necessary.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Test Vectors==\n\u003e\u003e\u003e\n\u003e\u003e\u003e The following fragment represents a wallet label export:\n\u003e\u003e\u003e \u003cpre\u003e\n\u003e\u003e\u003e Reference,Label\n\u003e\u003e\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎,Transaction\n\u003e\u003e\u003e 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address\n\u003e\u003e\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\u003c0,Input\n\u003e\u003e\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎\u003e0,Output\n\u003e\u003e\u003e c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b‎:0,Output (alternative)\n\u003e\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ==Reference Implementation==\n\u003e\u003e\u003e\n\u003e\u003e\u003e TBD\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220825/b57b0503/attachment-0001.html\u003e"}