Wallet Label Export Format: A Proposal by Craig Raw

[banzai2]

I wouldn't worry too much about human readability so much as human usability.

The proposed two-column format allows for a trivial CTRL-F to locate any specific desired one-off info, should someone want/need to find something directly in the raw CSV file (most likely looking up by addr or by label text).

And I don't think it's a reasonable use-case/design constraint to try to insure that the format be easy for humans to directly edit or add to themselves. Manually logging inputs or outputs is going to be incredibly error-prone regardless of how the format is defined. Excel or Google Sheets is fine as a convenience viewer, but manual editing only really makes sense within some kind of dedicated Bitcoin-savvy helper UI that can look up each txid entered, etc.

Ongoing management via direct human edits isn't practical (or at least wouldn't be a recommended practice) so let's not agonize over it.

[1714990949]

1714990949

[1714990949]

1714990949

[1714990949]

1714990949

[1714990949]

1714990949

[NotATether]

I wouldn't worry too much about human readability so much as human usability.

The proposed two-column format allows for a trivial CTRL-F to locate any specific desired one-off info, should someone want/need to find something directly in the raw CSV file (most likely looking up by addr or by label text).

And I don't think it's a reasonable use-case/design constraint to try to insure that the format be easy for humans to directly edit or add to themselves. Manually logging inputs or outputs is going to be incredibly error-prone regardless of how the format is defined. Excel or Google Sheets is fine as a convenience viewer, but manual editing only really makes sense within some kind of dedicated Bitcoin-savvy helper UI that can look up each txid entered, etc.

Ongoing management via direct human edits isn't practical (or at least wouldn't be a recommended practice) so let's not agonize over it.

Specifically related to the last sentence, do you think that adding a prefix at the beginning of some data will hamper the human usability? I'm starting to think that might be the case, assuming people autofill such data from other sheets.

[banzai2]

Specifically related to the last sentence, do you think that adding a prefix at the beginning of some data will hamper the human usability? I'm starting to think that might be the case, assuming people autofill such data from other sheets.

No, but I think it's an unnecessary addition to the format that attempts to fix a problem that shouldn't be/can't be solved in the first place (i.e. making it friendly for humans to directly work with the raw CSV or manually add valid entries in Excel).

The focus should remain on this being a bare-bones software-to-software interchange format.

That it is reasonably not too terrible for a human to look up a single one-off value is a nice bonus. But I think any human requirement beyond that is impossible to satisfy.

[n0nce]

The focus should remain on this being a bare-bones software-to-software interchange format.

I guess a purely software-to-software oriented format could also facilitate writing a simple script that generates an excel file or some other human-friendly representation.

[craigraw]

(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.

[NotATether]

(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!

Approach ACK. This revised BIP looks much more focused.

If you want, you can make a 3rd party JSON-Lines to CSV generator to interface with your original design goal of business editing of label spreadsheets.

Good luck getting it numbered.

[n0nce]

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" }

Looks good to me! Good luck with the BIP.

If you want, you can make a 3rd party JSON-Lines to CSV generator to interface with your original design goal of business editing of label spreadsheets.

Agreed, as written above!

I guess a purely software-to-software oriented format could also facilitate writing a simple script that generates an excel file or some other human-friendly representation.