Date: Wed, 20 Jul 2022 04:10:09 +0000
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com>
In-Reply-To: <20220719104725.ppic7jy4ghfieeap@artanis>
References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid>
 <mailman.84940.1658205911.8511.bitcoin-dev@lists.linuxfoundation.org>
 <20220719104725.ppic7jy4ghfieeap@artanis>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Trying all address types in message signing
	verification (BIP)
Precedence: list

[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 an=
d verifying a bitcoin message can only sign legacy addresses. It is technic=
ally 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 segwi=
t address into the address field. Verification also only works using the pr=
ocedure 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 guideline=
s for writing a message signing and verification procedure.

This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My propo=
sal is simply going to standardize the practice of placing the segwit addre=
ss 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 algorit=
hms will be tried in sequence in an attempt to reconstruct the address in t=
he signed message:
- P2PKH (legacy address)
- P2WPKH-P2SH (nested segwit)
- P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit w=
ith version 0 as well as future native segwit address types such as Taproot=
) - where MAX_WITNESS_VERSION is the maximum supported witness version by t=
he bech32 encoding.

The verification procedure stops if any of these hashes yield the correct a=
ddress, 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 seg=
wit 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 interop=
erate with this improved sign/verify algorithm, without any action necessar=
y 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 jus=
t want to hear the mailing list's advice about how I should draft such a BI=
P.

- Ali

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