Ali Sherief [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-20 📝 Original message:[my third attempt at ...

📅 Original date posted:2022-07-20
📝 Original message:[my third attempt at getting this message through. Surprisingly, I managed to send this at the second try with the correct SMTP, From, To and all, but maybe it was caught in GreyListing (protonmail).]

I was thinking about creating a BIP to address the lack of standardization for Segwit message signatures, but I want some advice before proceeding.

The current state of affairs is that the wallets that do support signing and verifying a bitcoin message can only sign legacy addresses. It is technically possible to sign and verify segwit addresses, since ECDSA only depends on the public key (hence why you need a private key to sign messages).

However, because there is no generally-accepted standard for signing segwit messages, the wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software, if only because the conventional tools for verifying messages attempt to reconstruct a legacy address only.

This BIP is not going to enforce anything, it's just going to set guidelines for writing a message signing and verification procedure.

This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.

In summary, in the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message:
- P2PKH (legacy address)
- P2WPKH-P2SH (nested segwit)
- P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding.

The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.

In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message.

If this BIP is approved, it does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.

So as you can see, this is the entire framework of the BIP I plan to draft. There is no need for any auxilliary feature additions into this BIP. I just want to hear the mailing list's advice about how I should draft such a BIP.

- Ali

PS. I am pretty sure that there is a BIP for the original signing method - what is its number?