From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 81CD4C002D for ; Mon, 29 Aug 2022 15:46:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C70A94086D for ; Mon, 29 Aug 2022 15:46:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C70A94086D Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=notatether.com header.i=@notatether.com header.a=rsa-sha256 header.s=protonmail header.b=VcrpWpqC X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 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, PDS_BTC_ID=0.499, PDS_BTC_MSGID=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aqUr9A9b_ST for ; Mon, 29 Aug 2022 15:46:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2A95C407D7 Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2A95C407D7 for ; Mon, 29 Aug 2022 15:46:23 +0000 (UTC) Date: Mon, 29 Aug 2022 15:46:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com; s=protonmail; t=1661787979; x=1662047179; bh=KL6MIhO8jCG++nJvmZRsAptRGA7SZnJ7RbqFROZ33wU=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=VcrpWpqCD9tnhrhiJV55/j8+eq8yeKjjjInDxyJS8uLUH1YaG4Bl5fxwLai2A3M+W jm4irE+9Cag2mIUKqcpOyWMp7Js5yr3O7zPWdzEUD3iCkdCOEImyn8TU6hMYF1KDvF AvqoXrUExUpub5QIhdCYb9k6NTuL4dFat9rsLdmDh9PedyjzK4icbzTI5QqlJoghWE uduYAQ7qh31gFoIXU0ghSps8F2mL79tTMpzgStPSHo9xeRNBVYsDs+BnpO6NfLY1mu 2Q93Z4il2xglN1r6f7NnuGFEoigJ27K4faAmHyxl+GWs+T3ICnWhSHcVI/mAShaiQ8 9U9RycyYWdAUA== To: craigraw@gmail.com From: Ali Sherief Reply-To: Ali Sherief Message-ID: <20220829154603.fec7mlm526vdfo2i@artanis> In-Reply-To: References: Feedback-ID: 34210769:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 29 Aug 2022 16:12:05 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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: Mon, 29 Aug 2022 15:46:28 -0000 > I am attempting to achieve two goals with this proposal, primarily for th= e > benefit of wallet users: > > Goal #1. Transfer labels between different wallet implementations > Goal #2. Manage labels in applications outside of Bitcoin wallets (such a= s > Excel) > > Much of the feedback so far has indicated the tension between these two > goals - it may be that it is too difficult to achieve both, in which case > Goal #1 is the most important. That said, I think further exploration is > still necessary before abandoning Goal #2, because removing it would > significantly reduce the value of this proposal and mean users need to re= ly > on application-specific workarounds. In my opinion, it would be best if these two goals were split into two sepa= rate BIPs where the BIP for Goal 2 requires Goal 1's BIP, gut Goal 1's BIP = is independent. This is because wallet software and business spreadsheet pr= ocesses have different and in some cases divergent needs. A BIP shouldn't try to address too many things at once, that's why technolo= gies like Segwit and Taproot were split into four or five BIPs each. > > Don't mandate the file extension... There is no way to enforce this on= a > BIP level. > I'm not quite sure what you mean here - for example BIP174, which is wide= ly > used, states "Binary PSBT files should use the .psbt file extension." Als= o, > this contradicts Goal #2 - Excel and Numbers register as handlers for .cs= v, > and so make it clear that the file is editable outside of a wallet. BIP174's assignment is a specification but not a hard requirement, becase i= f you have a file whose extension implies one type, but its MIME type (obta= ined from inspecting the file contents) indicates another type, then the ex= tension should be disregarded by the parser. I am aware that business processes are mostly CSV file oriented so you can = make a statement akin to BIP174 in the Goal 2 BIP, that expects the medium = of exchange to be in files ending in .csv. I wouldn't mind if you require .= csv file extension in a BIP for Goal 2. But such a statement is not appropr= iate in the Goal 1 BIP which is only concerned with the wallet label format= itself. > > ZIP does not have good performance or compression ratio > Indeed, but it is very widely available. That said, gzip is supported > widely too these days. Unfortunately, gzip does not offer encryption (see > next answer). > > > ZIP is an archiving format, that happens to have its own compression > format. > I agree this is not ideal. My main reason for choosing ZIP was that it > supports encryption. It seems to me that without considering encryption, = an > application must create label export files that allow privacy-sensitive > wallet information to be readable in plain text. Being able to transfer > labels without risking privacy is IMO valuable. I considered other > encryption formats such as PGP, but they are much more niche and so again > contradict Goal #2. Both of these look like parts of the spec that should be in the Goal 2 BIP.= Because Goal 1, which is only concerned with wallet label importing, does = not need to interact with compression or encryption. I don't mind if you make Goal 2 BIP utilize ZIP compression with optional e= ncryption, it's just that specifying this in the same place in the Goal 1 B= IP stuff forces wallets to check for that stuff too to be compliant. It's i= mportant to make compliance as easy as possible. Regardless, I still believe that making the xpub the ZIP password is a bad = design, because some wallets that are made from a random list of private ke= ys do not have xpubs at all. If the purpose of a password is to make label = sharing between two parties secure, then why not simply let them agree on a= password for their own use? > > I don't see the benefit of encrypting addresses and labels together... > additionally, the password you propose is insecure - anybody with access = to > the wallet can unlock it > I'm not sure I understand your question, but both wallet addresses and > wallet labels contain privacy-sensitive information that should be > protected. Wrt to the password, there is actually a more fundamental > problem with using the wallet xpub - there is no equivalent for multisig > wallets. For this reason I'll remove that requirement in future iteration= s. Let me explain. Before you partitioned the BIP into two goals, I was under the impression t= hat wallets would have to read an encrypted export file, which seemed very = overkill to me (for one, all wallets would now need to bundle a ZIP or AES = dependency module with their program). But now I see why a password and encryption would be desireable for Goal 2 = BIP applications. Like I said though, Goal 1 BIP applications (i.e. wallets= ) do not need any of that. > > Why the need for input and output formats? There is no difference betwe= en > them on the wallet level, because they are always identified with a txid > and output index. > The input refers to the txid and the input index (in the set of vin), so > the difference is the context in which they are displayed. A wallet will > not necessarily store the spent outputs for a funding transaction > containing a UTXO coming into the wallet, but it will contain references = to > the inputs as part of that transaction. > > > Another important point is that practically nobody labels inputs or > outputs > To the contrary, UTXOs are very frequently labelled, as they link and > reveal information when spent. Inputs are much less frequently labelled, > but there is no particular reason to exclude them. > > > there is a net benefit for the addresses to be exported in ascending or= der > Indeed, but it makes achieving Goal #2 much more difficult for marginal > benefit. Fair enough. > > It's better to mandate that they should always be double-quoted, since > only wallets will generate label exports anyway. > Rather I think it's better to mandate RFC4180 is followed, as per > recommendations in other feedback. I agree with this. > > The importing code is too naive... it should utilize a dedicate item ty= pe > field that unambiguously identifies the item > It's unclear to me what you mean here. As I've indicated it is currently > possible to disambiguate between addresses/transactions/etc without the > need for a 3rd column, but in any case the hash functions used ensure tha= t > labels will not be associated incorrectly. Even in the unlikely event of > some future address type being indistinguishable from a txid, it will > simply not match any txids in the wallet. You already have a custom format proposed here, but this importer relies on= heuristics of the data like how long it is, what characters it has, and so= on. It is better for the importer to have the same kind of conditions. You can make parsing vastly simpler by prefixing the items with some text. = Similar to how we have "bitcoin:" for indicating a bitcoin address, you can= have "address:", "transaction:", "input:", and "output:" at the beginning = of each entity. This has a major advantage: You can add new formats in a backward-compatibl= e way without breaking parsers, since the parsers never depended on the tex= t heuristics in the first place, therefore you don't have to clutter the BI= P(s) with even more test vectors for these cases. You won't even need a ver= sion byte, since the only revision that will ever be made (that doesn't mod= ify any existing format to preserve backward-compatibility) are adding new = formats. Take a look at your sample: > > > 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 versus how mine would look: > if reference.startsWith("address:") > Set address label > else if reference.startsWith("transaction:") > Set transaction label > else if reference.startsWith("input:") > Set input label > else if reference.startsWith("output:") > Set output label > # No else case: allows for future extensions See how simpler it is to understand? The truth is, a format has to be defined that developers find it easy to im= plement. If the implementation is such that a developer could misunderstand= at a first glance, they will implement it wrongly, creating bugs. Looking at your sample, a developer would think as such: "anything less tha= n 64 chars is an address, anything 64 chars long is a transaction, anything= that contains a '<' is an input (and is also greater than 64 chars), and e= verything else is an output (>64 chars and has no '<')." In light of all this, is it not much easier to simply introduce a prefix at= the beginning of each entity? It has a negligible space cost. The "else" c= ase can be ommitted hypothetically (although that's not strictly necessary)= , so developers can just add more "else if"'s when a BIP revision is made. A good way to see if a reference implementation has a good design is by ask= ing yourself the following question: Imagine you are committing your refere= nce into Bitcoin Core. Based on the code quality, would a pull request for = that be merged, or not? So to summarize, I strongly suggest you do the following: - Split the BIP into two, one defines the CSV format for label import/expor= t between wallets, and the other defines workflows for distributing and sha= ring label CSVs in a universal and safe way. - Add prefixes before each entity, so in other words: "adddress:bc1q23456..= .", "transaction:432abd874d...", "input:432abd874d...1", "output= :432abd874d...1". Replace with any delimiter you wan= t, it doesn't have to be consistent. This will make it much simpler to impl= ement an importer, without applications doing any of the hacks that RHavar = wrote about (IMO this is what people mean when they say that implementing a= CSV importer will be complex work). - Ali On Mon, Aug 29, 2022 at 11:26:32AM +0000, craigraw@gmail.com wrote: > Thanks for your feedback @Ali. > > > > it is important that a version byte is defined > If Goal #2 is to be achieved it's difficult to mandate this, particularly > if one requires bit flags to be set. Should an importing wallet fail to > import if the version byte is not present, even if all the data is > otherwise correct? Although it is difficult to know in advance how a form= at > may be extended, it is certainly possible to extend this format with > additional types where the nature of hashes serve as unique identifiers > (more on this below). > > > Don't mandate the file extension... There is no way to enforce this on= a > BIP level. > I'm not quite sure what you mean here - for example BIP174, which is wide= ly > used, states "Binary PSBT files should use the .psbt file extension." Als= o, > this contradicts Goal #2 - Excel and Numbers register as handlers for .cs= v, > and so make it clear that the file is editable outside of a wallet. > > > ZIP does not have good performance or compression ratio > Indeed, but it is very widely available. That said, gzip is supported > widely too these days. Unfortunately, gzip does not offer encryption (see > next answer). > > > ZIP is an archiving format, that happens to have its own compression > format. > I agree this is not ideal. My main reason for choosing ZIP was that it > supports encryption. It seems to me that without considering encryption, = an > application must create label export files that allow privacy-sensitive > wallet information to be readable in plain text. Being able to transfer > labels without risking privacy is IMO valuable. I considered other > encryption formats such as PGP, but they are much more niche and so again > contradict Goal #2. > > > I don't see the benefit of encrypting addresses and labels together... > additionally, the password you propose is insecure - anybody with access = to > the wallet can unlock it > I'm not sure I understand your question, but both wallet addresses and > wallet labels contain privacy-sensitive information that should be > protected. Wrt to the password, there is actually a more fundamental > problem with using the wallet xpub - there is no equivalent for multisig > wallets. For this reason I'll remove that requirement in future iteration= s. > > > Why the need for input and output formats? There is no difference betwe= en > them on the wallet level, because they are always identified with a txid > and output index. > The input refers to the txid and the input index (in the set of vin), so > the difference is the context in which they are displayed. A wallet will > not necessarily store the spent outputs for a funding transaction > containing a UTXO coming into the wallet, but it will contain references = to > the inputs as part of that transaction. > > > Another important point is that practically nobody labels inputs or > outputs > To the contrary, UTXOs are very frequently labelled, as they link and > reveal information when spent. Inputs are much less frequently labelled, > but there is no particular reason to exclude them. > > > there is a net benefit for the addresses to be exported in ascending or= der > Indeed, but it makes achieving Goal #2 much more difficult for marginal > benefit. > > > It's better to mandate that they should always be double-quoted, since > only wallets will generate label exports anyway. > Rather I think it's better to mandate RFC4180 is followed, as per > recommendations in other feedback. > > > The importing code is too naive... it should utilize a dedicate item ty= pe > field that unambiguously identifies the item > It's unclear to me what you mean here. As I've indicated it is currently > possible to disambiguate between addresses/transactions/etc without the > need for a 3rd column, but in any case the hash functions used ensure tha= t > labels will not be associated incorrectly. Even in the unlikely event of > some future address type being indistinguishable from a txid, it will > simply not match any txids in the wallet. > > Craig > > > > On Wed, Aug 24, 2022 at 9:10 PM Ali Sherief wrote: > > > Hi Craig, > > > > This a really good proposal. I studied your BIP and I have some feedbac= k > > on some parts of it. > > > > > The first line in the file is a header, and should be ignored on impo= rt. > > > > From past experience and lessons, most notably BIP39, it is important t= hat > > a version byte is defined somewhere in case someone wants to extend it = in > > the future, currently there is no version byte which someone can increm= ent > > if somebody wants to extend it. In the unique case of CSV files, you sh= ould > > make the header line mandatory (I see you have already implied this, bu= t > > you should make it explicit in the BIP), but instead of a line with col= umns > > in it, I suggest instead of Reference,Label, you make the format like t= his: > > > > BIP-wallet-labels, > > > > Since there are two columns per record, this works out nicely. The firs= t > > column can be the name of the BIP - BIPxxxx where the x's are numbers, = and > > the second column can be an unsigned 32-bit integer (most significant 8 > > bits reserved for version, the remaining for flags, or perhaps the enti= rety > > for version - but I recommend leaving at least some bits for flags, eve= n if > > they all end up being just "reserved"). > > > > You should make importing fail if the header line is not exactly as > > specified - or appropriate, should you decide a different format for th= e > > header. > > > > > Files exported should use the .csv file extension. > > Don't mandate the file extension (read below for why): > > > > > In order to reduce file size while retaining wide accessibility, the = CSV > > > file may be compressed using the ZIP file format, using the .zip<= /tt> > > > file extension. > > I see three problems with this. The first is more important than the la= ter > > two because it makes them moot points, but I'll mention them anyway so = you > > get a background of the situation: > > - The BIP is trying to specify in what file format the export format ca= n > > be written in onto the filesystem. There is no way to enforce this on a= BIP > > level (besides, Unix operating systems don't even consider the file > > extension, they use its mimetype). Also specifying this in the BIP will > > prevent modular "Layer 2" protocols and schemes from encoding the Expor= t > > labels into another format - for example Base64 or with their own > > compression algorithm. > > > > Now for the two "moot problems": > > - ZIP does not have good performance or compression ratio, there are > > better algorithms out there like gzip (which also happens to be more > > ubiquitous; nearly all websites are serving HTML compressed with gzip > > compression). > > - ZIP is an archiving format, that happens to have its own compression > > format. Archiving format parsers can have serious vulnerabilities in th= eir > > implementation that can allow malware to swipe private keys and passwor= ds, > > since the primary target for this BIP is wallets. For example, there wa= s > > Zip Slip[1] in 2018, which allows for remote code execution. So the mal= ware > > can even hide in memory until private keys or passwords are written to > > memory, then send them accros the network. Assuming it's targeting a > > specific wallet software it's not hard to carry out at all. > > > > There's two solutions for all this: > > 1. The duck-tape solution: Use some compression algorithm like gzip > > instead of ZIP archive format. > > 2. The "throw it out and buy a new one" solution: Get rid of the option= al > > compression specs altogether, because users are responsible for supplyi= ng > > the export labels in the first place, so all the compression stuff is > > redundant and should be left up to the user use if they desire to. > > > > I prefer the second solution because it hits the nail at the problem > > directly instead of putting duck tape on it like the first one. > > > > > This .zip file may optionally be encrypted using either AES-= 128 > > or > > > AES-256 encryption, which is supported by numerous applications inclu= ding > > > Winzip and 7-zip. > > > The textual representation of the wallet's extended public key (as > > defined > > > by BIP32, with an xpub header) should be used as the passwor= d. > > Not specific to AES, but I don't see the benefit of encrypting addresse= s > > and labels together. Can you please elaborate why this would be desirea= ble? > > > > Like I said though, it's better to leave it up to users to decide how t= o > > store their exports, since BIPs can't enforce that anyway (additionally= , > > the password you propose is insecure - anybody with access to the walle= t > > can unlock it, which is not desireable to some users who want their own > > security). > > > > > * Transaction ID (txid) > > > * Address > > > * Input (rendered as txid) > > > * Output (rendered as txid>index or txid:index) > > Why the need for input and output formats? There is no difference betwe= en > > them on the wallet level, because they are always identified with a txi= d > > and output index. To distinguish between them and hence write them with= the > > correct format would require a UTXO set and thus access to a full node, > > otherwise the CSV cannot be verified to be completely well-formed. > > > > Another important point is that practically nobody labels inputs or > > outputs because most people do not know that those things even exist, a= nd > > the rest don't bother to label them. > > > > But the biggest downside to including them is related to the problem of > > information leaking which you make reference to here: > > > In both cases, care must be taken when spending to avoid undesirable > > leaks > > > of private information. > > A CSV dump that has inputs/outputs and addresses mixed together can inf= er > > the owner of all those items. In fact, A CVS label dump is basically a > > personal information store so everything in it can be correlated as com= ing > > from the same wallet, so it's important that unnecessary types are kept= out > > of the format. People are known to leave files lying around on their > > computer that they don't need anymore, so these files can find their wa= y > > via telemetry to surveillence entities. While we can't specify what use= rs > > can do with their exports, we can control the information leak by > > preventing certain types of items that we know most users will never us= e > > from being exported in the first place. > > > > > The order in which these records appear is not defined. > > Again, since the primary use case for this BIP is wallets, which likely > > use heirarchical derivation schemes like BIP44, there is a net benefit = for > > the addresses to be exported in ascending order of their `address_type`= . It > > means that wallets can import them in O(n) time as opposed to O(n^2) ti= me > > spent serially checking in which index the address appears at. Of cours= e, > > this implies that all addresses up to a certain index have to be export= ed > > into the CSV as well, but most wallets I know of like Core, Electrum > > already store addresses like that. > > > > Also if you do this, you will need to group all the transaction records > > before the address records or vice versa - you can use lexigraphical > > sorting if you want (ie. Addresses before Transactions). The benefit of > > this separation of parts is that wallets can split the imported address > > records from the transaction records internally, and feed them to separ= ate > > functions which set these labels internally. > > > > If you decide on doing it this way, then you need a 3rd column to ident= ify > > the item type, and also you should quote the label (see below). I stron= gly > > recommend using numbers for identification as opposed to character stri= ngs, > > so you don't have to worry about localization or character case issues. > > There is always one unique number, but there could be multiple strings = that > > reference the same type. This will complicate importing functions. > > > > If you insist on include Input and Output types then they can both be > > specified as : if you do this change. They won't be used t= o > > determine the type anyway. > > > > > The fields may be quoted, but this is unnecessary, as the first comma= in > > > the line will always be the delimiter. > > Don't implement it like that, because that will break CSV parsers which > > expect a fixed amount of rows in each record (2 in the header, and some > > rows have >2 rows). It's better to mandate that they should always be > > double-quoted, since only wallets will generate label exports anyway. I= f > > you plan to use headers then the 3rd column can be blank for it (or you= can > > split the version and flags from each other). > > > > > =3D=3DImporting=3D=3D > > > > > > When importing, a naive algorithm may simply match against any refere= nce, > > > but it is possible to disambiguate between transactions, addresses, > > inputs > > > 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
> > >
> > The importing code is too naive and in its current form will prevent th= e > > BIP from getting a number. It is perhaps the single most important part= of > > a BIP. When implementing an importer, it should utilize a dedicate item > > type field that unambiguously identifies the item. So the naive importe= r is > > not good, you need use a 3rd column for that like I explained above, so > > that the importer becomes robust. > > > > In summary (exclamation marks indicate severity - one means low, two me= ans > > medium, and three means high): > > > > 1. Convert the header into a version line with optional flags, otherwis= e > > nobody can extend this format without compatibility issues (!) > > 2. Get rid of the specs related to file compression (!!!) > > 3. Add a 3rd column for item type (address, transaction etc.) preferabl= y > > as numeric constants and grouping items of one type after items of anot= her > > type, or if you insist on strings, then only recognize their Titlecase > > ASCII versions > the words> (!!) > > 4. Require double quotes around the label (or single quotes if you pref= er, > > as long as spreadsheet software doesn't choke on them) (!!) > > 5. Require sorting the records according to the order they are stored i= n > > the wallet implementation. (!) > > 6. Consider getting rid of Input and Output item types. (!) > > 7. And last and most importantly, please write a more robust importer > > algorithm in the example given by the BIP, because code in BIPs are > > frequently used as references for software. (!!!) > > > > I hope you will consider these points in future revisions of your BIP. > > > > - Ali > > > > [1] https://github.com/snyk/zip-slip-vulnerability > > > > On Wed, 24 Aug 2022 11:18:43 +0200, craigraw@gmail.com 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 ac= ross > > > wallet applications has been made simple through standards such as BI= P39, > > > wallet labels remain siloed and difficult to extract despite their va= lue, > > > particularly in a privacy context. > > > > > > The proposed format is a simple two column CSV file, with the referen= ce > > 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 fil= e > > may > > > be compressed using the ZIP format, and optionally encrypted using AE= S. > > > > > > The full text of the BIP can be found at > > > https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediaw= iki > > > 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 walle= t. > > > > > > =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, BIP44 etc. > > > These standards are well supported and allow users to move easily bet= ween > > > different wallets. > > > There is, however, no defined standard to transfer any labels the use= r > > may > > > have applied to the transactions, addresses, inputs or outputs in the= ir > > > wallet. > > > The UTXO model that Bitcoin uses makes these labels particularly valu= able > > > 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 t= hat > > > they do not experience lock-in to a particular wallet application. > > > In addition, by using common formats, this BIP seeks to make manual o= r > > 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, whic= h 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 exampl= e > > > JSON) lends itself well to bulk label editing using spreadsheet and t= ext > > > editing tools. > > > > > > A CSV export of labels from a wallet must be a UTF-8 encoded text fil= e, > > > 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 impo= rt. > > > Thereafter, each line represents a record that refers to a label appl= ied > > 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 z= ero > > > 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<= /tt> > > > file extension. > > > This .zip file may optionally be encrypted using either AES-= 128 > > or > > > AES-256 encryption, which is supported by numerous applications inclu= ding > > > Winzip and 7-zip. > > > In order to ensure that weak encryption does not proliferate, importe= rs > > > following this standard must refuse to import .zip 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 xpub header) should be used as the passwor= d. > > > > > > =3D=3DImporting=3D=3D > > > > > > When importing, a naive algorithm may simply match against any refere= nce, > > > but it is possible to disambiguate between transactions, addresses, > > inputs > > > 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?,Trans=
action
> > > 1A69TXnEM2ms9fMaY9UuiJ7415X7xZaUSg,Address
> > > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?<0,I=
nput
> > >
> > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?>0,Out=
put
> > >
> > c3bdad6e7dcd7997e16a5b7b7cf4d8f6079820ff2eedd5fcbb2ad088f767b37b?:0,Out=
put
> > > (alternative)
> > >
> > > > > > =3D=3DReference Implementation=3D=3D > > > > > > TBD