BIP139: Wallet Metadata Backup Format #2130

3 different ways of representing the birth date doesn't seem ideal. Also "iso_8601_datetime" specifies the data format, not the purpose of the field. I'd prefer short, purposeful names (e.g. "birthblock" or "birthdate") and leave the type and format out of the name.

I'm open to represent in a different way, but few points why it's end up like this:

• we use a backup format based on this in Liana with the timestamp field
• we had a discussion w/ @ethicnology here where he seems prefering iso 8601, I've used a simplified approach in this draft compared to what discussed, but I'm eager to get feedback.
• it comes to my mind later that block_height rather than unix timestamp could make more sense

I was about to comment on there being three different birth time fields as well. Seconding @seedhammer’s concern here.

Why mention alias in a new BIP?

because we already use name in Liana backup format, but in the end I think alias is more clear

active doesn't seem very useful for a backup. In fact, some of these fields feel like the union of all possible metadata fields useful to any wallet software. If so, this leads to the question: what is the standard for adding new fields to this standard?

I think it's better to specify a small(er) set of widely useful fields.

iirc it was requested by @ethicnology to represent an usage they already have in Bull Bitcoin wallet

and I just notice it is also something tracked in bitcoin core: https://github.com/bitcoin/bitcoin/blob/2b541eeb363cd43fc225c7c7f9691c925b0e4f9d/src/wallet/rpc/backup.cpp#L515

It feels wrong to specify a field which is immediately "strongly discouraged".

Need a rewording, I think mainnet mnemonic should be strongly discouraged, but it could be useful for testnet, like in a bug report, join a testnet/signet/regtest backup of a wllet can make it easy to import the wallet state in order to reproduce the bug.

reworded

Non-main networks are not useful for backups. Can the "network" field be left out entirely?

cf previous message for rationale

Did some regex-powered find and replace go wild on this whole document? There is also a fullstop after almost every headline.

BIP: ?
Layer: Applications
Title: Wallet Backup Metadata Format
Authors: Pyth <pythcoiner@wizardsardine.com>
Status: Draft
Type: Specification
Assigned: ?
License: BSD-2-Clause
Discussion: https://x.com/pythcoiner/status/1893923445974425840?s=20
            https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8

I don’t think the Twitter discussion linked there is what we usually have in mind when we think of this preamble header.

Discussion: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8

I’m not sure it’s worth linking to this Twitter discussion, it seems mostly about coordinating and linking to some related work.

Discussion: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8

I think I was a "tired regex" :smile:

dropped

dropped

Wouldn’t it rather be “Wallet Metadata Backup Format”?

changed

This format can be encrypted following [BIP-0138](https://github.com/bitcoin/bips/pull/1951).

I would advise against collecting fields in the BIP directly. We have had several BIPs in the past that were extensible in this form and in each case the authors eventually got tired of reviewing amendments to their BIP. I would suggest that you instead pursue a model like BIP174 (PSBT), where only the registering of the new fields in collected centrally in an auxiliary file for this express purpose, but fields have to be described in their own BIPs. — Maybe separate BIPs are a bit too high of a hurdle in this specific case and there could instead be a description of the fields in the registry directly, but I would heavily recommend not putting the onus of frequently needing to review BIP amendments on your future self.

Nit: BIPs themselves have now an optional version header, so this may be confusing in the future if the document gets updated.

I assume you are talking about "version 1 of the backup format", i.e. the value stored with the version key in the backup, maybe this could be stated a bit more explicitly, though.

Spelled with capital letters just below (and should be spelled capitalized).

  Values used by Bitcoin Core are `legacy`, `p2sh-segwit`, `bech32`, and `bech32m`.  

Ambiguous whether Bitcoin Core is an example or counter-example:

- `change_descriptor`: Optional string or object representing an explicit change-side
  descriptor, paired with `descriptor`. Intended for wallets that do not use BIP-389
  multipath descriptors (as e.g. Bitcoin Core does).  

If you have an idea how to standardize descriptor identifiers, I think that might be a good BIP in itself to write.

cc: @achow101

It strikes me as odd that all fields here are optional. Is that intended? Perhaps there should be at least an "A or B is required"?

I agree, defining a standard requires having mandatory requirements. Take BIP329 as an example: it has many optional fields that some wallets may not support (like "unspendable"), but you can still count on anyone implementing the BIP to support at least the required fields. If everything is optional, then everyone will only implement what they personally care about, and we lose any ability to enforce consistency.