Date: Wed, 20 Jul 2022 09:31:21 -0400
From: "Peter (Coinkite Inc)" <peter@coinkite.com>
To: Ali Sherief <ali@notatether.com>
Message-ID: <YtgDqWSIbX8EJc3B@coinkite.com>
Reply-To: Peter <peter@coinkite.com>
References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid>
 <mailman.84940.1658205911.8511.bitcoin-dev@lists.linuxfoundation.org>
 <20220719104725.ppic7jy4ghfieeap@artanis>
 <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="xUUxadUa803MdFgj"
Content-Disposition: inline
In-Reply-To: <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com>
Organization: Coinkite Inc. (coinkite.com)
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trying all address types in message signing
 verification (BIP)
Precedence: list


--xUUxadUa803MdFgj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Ali.

> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My pro=
posal is simply going to standardize the practice of placing the segwit add=
ress into the address field, and does not require alterations to the messag=
e signing format like those BIPs.

COLDCARD makes signatures exacly like that, when told to sign with a segwit=
 address:

    % ckcc msg -s Hello
    Hello                            =20
    bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
    HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5m=
NTWH9qkDoqZTpnPc=3D

Unfortunately, I do not know of any "verifiers" that will accept the above =
signature, but there is no alternative since the various BIP-322 proposals =
never gained wide acceptance.

Bitcoin Core does not support verifying that message, even though the UX ma=
kes it look possible. In effect segwit features never got implemented to th=
at depth in Core. It's sad because the community is not maintaining core (C=
ore?) features to the same depth as Satoshi did when he was active in the p=
roject.

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

My understanding that the original approach was directly from Satoshi himse=
lf when the original client was written. It has never been codified in a BI=
P as far as I know.

A related issue the the "ascii armor" that is sometimes used. It's a little=
 like RFC2440 <https://www.ietf.org/rfc/rfc2440.txt> but newline-treatment =
isn't defined well enough for good interoperability, in my personal experie=
nce.

So in summary... yes a "defacto" BIP is needed and useful to do, in my opin=
ion. Then Core should be updated to support it as well.

---
@DocHEX  ||  Coinkite  ||  PGP: A3A31BAD 5A2A5B10


On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:
> [my third attempt at getting this message through. Surprisingly, I manage=
d to send this at the second try with the correct SMTP, From, To and all, b=
ut maybe it was caught in GreyListing (protonmail).]
>=20
> I was thinking about creating a BIP to address the lack of standardizatio=
n for Segwit message signatures, but I want some advice before proceeding.
>=20
> 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 techn=
ically possible to sign and verify segwit addresses, since ECDSA only depen=
ds on the public key (hence why you need a private key to sign messages).
>=20
> However, because there is no generally-accepted standard for signing segw=
it messages, the wallets that do support this feature simply insert the seg=
wit address into the address field. Verification also only works using the =
procedure on that specific wallet software, if only because the conventiona=
l tools for verifying messages attempt to reconstruct a legacy address only.
>=20
> This BIP is not going to enforce anything, it's just going to set guideli=
nes for writing a message signing and verification procedure.
>=20
> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My pro=
posal is simply going to standardize the practice of placing the segwit add=
ress into the address field, and does not require alterations to the messag=
e signing format like those BIPs.
>=20
> In summary, in the verification part, the following address hashing algor=
ithms 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 Tapro=
ot) - where MAX_WITNESS_VERSION is the maximum supported witness version by=
 the bech32 encoding.
>=20
> 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 addre=
ss in the signed message.
>=20
> In the signing procedure, the only modification is the insertion of the s=
egwit address in place of the legacy address in the signed message.
>=20
> If this BIP is approved, it does not require any changes to existing sign=
ed messages, and the original sign/verify algorithms will continue to inter=
operate with this improved sign/verify algorithm, without any action necess=
ary from the developers.
>=20
> So as you can see, this is the entire framework of the BIP I plan to draf=
t. There is no need for any auxilliary feature additions into this BIP. I j=
ust want to hear the mailing list's advice about how I should draft such a =
BIP.
>=20
> - Ali
>=20
> PS. I am pretty sure that there is a BIP for the original signing method =
- what is its number?
>=20


--xUUxadUa803MdFgj
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEERYl3mt/BTzMnU06oo6MbrVoqWxAFAmLYA6kACgkQo6MbrVoq
WxAyhwgAsfRD0zjiuEtwA7tDg+rCrOzzljl3bXJD1sJ9PmgZbTYt5v8bc+4chD/t
Q3KhFyNdWEoNVPPtgI2ExqmPFTFeYXoMbXWU6mth5LE6npc+468cUiutP3jIHM6E
hSQ0bQm/dUAxNrN2G3cLKwkxMspQVxp4Ure+EvjM9be4QTBpM4Z/CMZXjugeaZ+O
HOuSVdaYaWAO7ENJqhsWsRV8DL7IzNc/ho/p4OM63/zLA6DRqnffKG86Kirdvlhf
rBiSrgx1g1NMhUgs3AOJCpzn9Mo1QcwWKYOjx1eXKXlrsh6jJtfL1VhS6/kyHjMl
MeJnvoBCDo6a8pYD9B4mgaBXUnHMYQ==
=Ly4+
-----END PGP SIGNATURE-----

--xUUxadUa803MdFgj--