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

Create SLIP-0137: Like BIP 137 but it defines the sign/verify procedure for all address types. #1555

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ZenulAbidin
Copy link

This was a BIP I created to somewhat standardize the procedure for generating signed messages for post-P2PKH address types. You can see it here on the mailing list. It was unceremoniously rejected with the reason being that more effort should be directed to BIP 322.

None of the recent efforts on BIP 322 came into any fruition on the BIPs repo.

Some companies such as Coinkite (the coldcard makers) are already using this BIP so it's best for all parties to officially publish this document in some capacity so that people don't have to rely on the source of the document being on my website, which can go down at any time.

Only superficial modifications such as changing "BIP" to "SLIP" have been made to the original BIP. I'm also open to deleting some of the optional modules if it means the core parts of the document get merged.

@ZenulAbidin
Copy link
Author

ZenulAbidin commented May 27, 2023

Some further questions:

  • Should I drop Taproot address signing capability altogether, since signatures are not using ECDSA anyway? Coldcard is not supporting Taproot yet, although elements of it are present in alpha builds of their firmware.
  • I have encountered some libraries that serialize messages to ASCII before signing with them. Since this is very bad for internationalization, should I make UTF8 encoding a requirement instead of optional?
  • Maybe I could add a Recommendations section and move the parts about message text cleanup there, and state it should be a best practice for wallet software, instead of defining it as a format or extension of some sort?

Ideally I don't want there to be any "extensions", and those existing ones to either be requirements or dropped altogether.

@ZenulAbidin
Copy link
Author

Really guys? No comments?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant