Skip to content

BIP139: Wallet Metadata Backup Format#2130

Open
pythcoiner wants to merge 1 commit into
bitcoin:masterfrom
pythcoiner:bip_wallet_backup
Open

BIP139: Wallet Metadata Backup Format#2130
pythcoiner wants to merge 1 commit into
bitcoin:masterfrom
pythcoiner:bip_wallet_backup

Conversation

@pythcoiner

@pythcoiner pythcoiner commented Mar 27, 2026

Copy link
Copy Markdown
Contributor

This is a bip for wallet metadata backup format.
Mailing list post: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8

@pythcoiner pythcoiner force-pushed the bip_wallet_backup branch 3 times, most recently from aa3b808 to 45b4a5b Compare March 27, 2026 12:54
@murchandamus

Copy link
Copy Markdown
Member

Could you perhaps expound the relationship to #1951?

@seedhammer seedhammer left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This BIP seems to overlap #2099. It would be ideal to have a single way of encoding wallet metadata.

Comment thread bip-0139.md
Comment on lines +103 to +108
- `timestamp`: Optional integer Unix timestamp representing account creation time in
seconds.
- `iso_8601_datetime`: optional string representing account creation time in ISO 8601
format.
- `block_height`: Optional integer representing account creation time in bitcoin block
height unit.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread bip-0139.md
- `version`: Optional integer version of the backup format.
- `bip`: Optional integer value representing the number of this BIP.
- `name`: Optional string wallet name.
NOTE: `alias` is an alias of `name`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why mention alias in a new BIP?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread bip-0139.md
- `name`: Optional string account name.
NOTE: `alias` is an alias of `name`.
- `description`: Optional string account description.
- `active`: Optional boolean field indicating if the account is active.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment thread bip-0139.md Outdated
Comment on lines +126 to +127
- `bip39_mnemonic`: Optional string containing mnemonic words following BIP39.
Since backups may be stored online, storing mainnet mnemonics is strongly discouraged.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reworded

Comment thread bip-0139.md
Comment on lines +80 to +81
- `network`: Optional string network identifier.
Valid values are `bitcoin` (mainnet), `testnet3`, `testnet4`, `signet`, and `regtest`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cf previous message for rationale

@murchandamus

Copy link
Copy Markdown
Member

Thanks for reviewing related work, @seedhammer!

@pythcoiner

Copy link
Copy Markdown
Contributor Author

Thanks for review @seedhammer, I'll reply inline

@pythcoiner

Copy link
Copy Markdown
Contributor Author

This BIP seems to overlap #2099. It would be ideal to have a single way of encoding wallet metadata.

I think they have different use case:

  • I see whats offered in BIP393: Output Script Descriptor Annotations #2099 as a minimal backup that a user make once at wallet(descriptor) creation time, that contains only informations related to "scanning"
  • Whats offered in this PR intends to be a format for backup/export of a complete wallet state, that could be also done later & recurently in the wallet lifetime.

@pythcoiner

Copy link
Copy Markdown
Contributor Author

Something that I should add in the bip abstract is, that I see this bip as a "central repository" where a wallet implementer can "register" a field usage & share it's usage of the format in a test vector. The intend is not to force anyone to be interoperable in both way with every other implem, but rather to make it easy if one want to be interoperable in at least one way.

@murchandamus

murchandamus commented Apr 7, 2026

Copy link
Copy Markdown
Member

I think this also has overlap with BIPs 329. Perhaps @craigraw would be interested in taking a look.

@pythcoiner

pythcoiner commented Apr 9, 2026

Copy link
Copy Markdown
Contributor Author

I've clauded a draft implem of this format on bitcoin core here and then added few fields and a transaction object here

@pythcoiner

Copy link
Copy Markdown
Contributor Author

Could you perhaps expound the relationship to #1951?

added an Encryption section in order to link them, will update as soon as there is a BIP # for #1951

@pythcoiner pythcoiner marked this pull request as ready for review April 24, 2026 07:29

@murchandamus murchandamus left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a quick first pass. I think I’d be interested in seeing a few more wallet developers take a look at this and provide their thoughts on how this would match their needs.

Comment thread bip-wallet-backup.md Outdated
Comment thread bip-wallet-backup.md Outdated
Comment thread bip-wallet-backup.md Outdated
Comment thread bip-wallet-backup.md Outdated
@pythcoiner pythcoiner force-pushed the bip_wallet_backup branch 2 times, most recently from 3d74fd1 to 1fc70c4 Compare April 29, 2026 06:51
@pythcoiner

Copy link
Copy Markdown
Contributor Author

@murchandamus thanks for your review, comments addressed.

@murchandamus

Copy link
Copy Markdown
Member

Assigned BIP139

@murchandamus murchandamus changed the title Bip draft: Wallet Backup Metadata Format BIP139: Wallet Backup Metadata Format May 11, 2026
@murchandamus murchandamus force-pushed the bip_wallet_backup branch 2 times, most recently from b0b0667 to b17c8a5 Compare May 11, 2026 20:06
@murchandamus

Copy link
Copy Markdown
Member

It took me a moment to figure out what the issue was: the preamble needed to be indented.

@murchandamus murchandamus changed the title BIP139: Wallet Backup Metadata Format BIP139: Wallet Metadata Backup Format May 11, 2026
Comment thread bip-0139.md Outdated

## Encryption

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@murchandamus murchandamus added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label May 19, 2026
@Sjors

Sjors commented May 26, 2026

Copy link
Copy Markdown
Member

I'm not sure if it's a good idea to create one kitchen-sink JSON blob for everything. BIP138 can easily handle multiple JSON blobs each specified in their own BIP.

@murchandamus

Copy link
Copy Markdown
Member

Hey, any update on this? Is there something I could help with? I was waiting for the open review to be addressed to take another look, but I wanted to check that we are not crossing our wires in regard to where it’s currently held up.

@pythcoiner

Copy link
Copy Markdown
Contributor Author

I'm not sure if it's a good idea to create one kitchen-sink JSON blob for everything. BIP138 can easily handle multiple JSON blobs each specified in their own BIP.

I think the OP was misleading, look like I've copy/pasted from BIP-138 PR w/o edit.

This spec is only related to BIP-139 in the way that it could be encryptd with it but have an independent purpose.

@pythcoiner

Copy link
Copy Markdown
Contributor Author

Hey, any update on this? Is there something I could help with? I was waiting for the open review to be addressed to take another look, but I wanted to check that we are not crossing our wires in regard to where it’s currently held up.

Thanks for the BIP # @murchandamus!

Sorry for late reply, I was a bit underwater on past weeks, I think all comments are adressed now.

@murchandamus murchandamus removed the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Jun 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants