(Copied from bitcoin-dev):

Following discussion with several wallet developers, I have come to the conclusion that the secondary goal of managing labels in non-specialized applications must be sacrificed in order to achieve the primary goal of wide implementation across different wallets. While this tradeoff was perhaps inevitable, it was worth a try!

As such I have rewritten the specification to use JSON, specifically the JSON Lines format. This allows documents to be split or streamed, and is convenient for command-line processing. The format is also now self describing via a type field, permitting simple type identification. Public keys and xpubs have been added as types following further suggestions. To keep the specification simple, compression and encryption have been removed - with the strong recommendation to consider protecting the data in a way suitable to its application.

The rewritten BIP can be found at https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki

It is perhaps simplest to understand it by looking at an example export:

{ "type": "tx", "ref":"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd", "label": "Transaction" }
{ "type": "addr", "ref": "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c", "label": "Address" }
{ "type": "pubkey", "ref":"0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448", "label": "Public Key" }
{ "type": "input", "ref":"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0", "label": "Input" }
{ "type": "output", "ref":"f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1", "label": "Output" }
{ "type": "xpub", "ref":"xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...", "label": "Extended Public Key" }

This proposal is intended as a foundational BIP for wallet label interchange - further BIPs may add label synchronization protocols etc.

This just changes the algorithm from character and length matching, to string matching. Also, similar to as I pointed out above, you introduce the possibility of typos causing difficult to detect omissions in data imports, and resultant variations in how implementations handle this. Canonical representations of references are preferred for this reason.

The proposed algorithm is complete and non-ambiguous for all considered data types. If new types need to be added in future, a new BIP would required in any case.

I mean user. For example, typos like 'Addres' would mean labels are skipped on import, which might be difficult to detect in a file with many labels. Of course the wallet could try to determine what the user meant from the reference itself, but then we are back at square one (and some implementations might not do this).

Thanks all for the useful feedback - it's particularly useful to hear from users, as opposed to just developers.

As noted, the main reason I didn't use descriptors is because txids and inputs aren't supported. In addition, it's less than user friendly to read and edit them.


This an interesting point. When designing this I considered it to be more work for everyone manually editing files to add a 3rd field, which in addition increases the export file size without aiding the parsing of the file in any material way (given it's currently possible to disambiguate from the reference alone). Further, it creates additional complexity and increases the potential for mistakes due to typos. But easily sorting to differentiate between types is a good counterpoint - I'm just not sure it's worth the cost.


This is generally good advice and has been suggested elsewhere. However, the 'use-in-excel' goal makes this tricky. If such a version must be specified but is not present (and all other data is fine), should the import fail? In general users won't know which version number to use, even if it is readily possible to add it (say in the column headers). Also, it's difficult to see how this format could be extended in a way that required a version number to differentiate, so again I'm not sure it's worth the cost.