Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wallet Labels Export Format #1383

Merged
merged 12 commits into from
Jan 16, 2023
Merged

Wallet Labels Export Format #1383

merged 12 commits into from
Jan 16, 2023

Conversation

craigraw
Copy link
Contributor

This was first proposed on the mailing list on Aug 24 as a common format for the export and import of wallet labels.

Following discussion there, on this bitcointalk post and via private channels with other wallet developers, the original proposal was simplified, and changed to use JSON instead of CSV. The revised proposal has been well received, and I believe is ready for consideration as a BIP.

Link: https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki

@abdul-hannan1
Copy link

I have address bsc

@moneymanolis
Copy link

What's blocking the merge of this?

|-
| <tt>pubkey</tt>
| 32 or 33 byte public key in hexadecimal format
| <tt>0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448</tt>
Copy link
Member

Choose a reason for hiding this comment

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

What about 65-byte pubkeys?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, added.

@luke-jr
Copy link
Member

luke-jr commented Jan 16, 2023

Assigned BIP 329

@craigraw
Copy link
Contributor Author

Edited to assign BIP number 329. Pinging @kallewoof

@kallewoof kallewoof merged commit 41490b7 into bitcoin:master Jan 16, 2023
@dipunm
Copy link

dipunm commented Jan 17, 2023

I get that this is closed, but am new to commenting on bips so I'll add my comment here.

An importing wallet may ignore records it does not store, and truncate labels if necessary.

I think adding truncation as a standard is dangerous. Context can be lost, especially if context was at the end. Also different apps may have further restrictions such as character limitations (no emoticon support or Chinese character support)

Is it not more appropriate to warn that care should be taken if truncating or modifying the label and/or a warning should be given if any modifications will be made. UI is up to the app.

Something like that?

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.

8 participants