MIME-Version: 1.0
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>
 <YtgDqWSIbX8EJc3B@coinkite.com>
In-Reply-To: <YtgDqWSIbX8EJc3B@coinkite.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 20 Jul 2022 17:50:53 -0400
Message-ID: <CAB3F3Du0OXcUvi6h8v0VZEj4cG24DJs04Vho8sM4Frhdhj5DrA@mail.gmail.com>
To: Peter <peter@coinkite.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fd142e05e44398de"
Cc: Ali Sherief <ali@notatether.com>
Subject: Re: [bitcoin-dev] Trying all address types in message signing
 verification (BIP)
Precedence: list

--000000000000fd142e05e44398de
Content-Type: text/plain; charset="UTF-8"

Please see BIP322
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki

On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Ali.
>
> > 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.
>
> COLDCARD makes signatures exacly like that, when told to sign with a
> segwit address:
>
>     % ckcc msg -s Hello
>     Hello
>     bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
>
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> 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
> makes it look possible. In effect segwit features never got implemented to
> that depth in Core. It's sad because the community is not maintaining core
> (Core?) features to the same depth as Satoshi did when he was active in the
> project.
>
> > 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
> himself when the original client was written. It has never been codified in
> a BIP 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 experience.
>
> So in summary... yes a "defacto" BIP is needed and useful to do, in my
> opinion. 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
> 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?
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000fd142e05e44398de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Please see BIP322=C2=A0<a href=3D"https://github.com/bitc=
oin/bips/blob/master/bip-0322.mediawiki">https://github.com/bitcoin/bips/bl=
ob/master/bip-0322.mediawiki</a></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 20, 2022, 5:46 PM Peter (Coinki=
te Inc) via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">Hi Ali.<br>
<br>
&gt; 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 mes=
sage signing format like those BIPs.<br>
<br>
COLDCARD makes signatures exacly like that, when told to sign with a segwit=
 address:<br>
<br>
=C2=A0 =C2=A0 % ckcc msg -s Hello<br>
=C2=A0 =C2=A0 Hello=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>
=C2=A0 =C2=A0 bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5<br>
=C2=A0 =C2=A0 HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYb=
bmqSRXqI5mNTWH9qkDoqZTpnPc=3D<br>
<br>
Unfortunately, I do not know of any &quot;verifiers&quot; that will accept =
the above signature, but there is no alternative since the various BIP-322 =
proposals never gained wide acceptance.<br>
<br>
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&#39;s sad because the community is not maintaining cor=
e (Core?) features to the same depth as Satoshi did when he was active in t=
he project.<br>
<br>
&gt; PS. I am pretty sure that there is a BIP for the original signing meth=
od - what is its number?<br>
<br>
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.<br>
<br>
A related issue the the &quot;ascii armor&quot; that is sometimes used. It&=
#39;s a little like RFC2440 &lt;<a href=3D"https://www.ietf.org/rfc/rfc2440=
.txt" rel=3D"noreferrer noreferrer" target=3D"_blank">https://www.ietf.org/=
rfc/rfc2440.txt</a>&gt; but newline-treatment isn&#39;t defined well enough=
 for good interoperability, in my personal experience.<br>
<br>
So in summary... yes a &quot;defacto&quot; BIP is needed and useful to do, =
in my opinion. Then Core should be updated to support it as well.<br>
<br>
---<br>
@DocHEX=C2=A0 ||=C2=A0 Coinkite=C2=A0 ||=C2=A0 PGP: A3A31BAD 5A2A5B10<br>
<br>
<br>
On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:<br>
&gt; [my third attempt at getting this message through. Surprisingly, I man=
aged to send this at the second try with the correct SMTP, From, To and all=
, but maybe it was caught in GreyListing (protonmail).]<br>
&gt; <br>
&gt; I was thinking about creating a BIP to address the lack of standardiza=
tion for Segwit message signatures, but I want some advice before proceedin=
g.<br>
&gt; <br>
&gt; The current state of affairs is that the wallets that do support signi=
ng and verifying a bitcoin message can only sign legacy addresses. It is te=
chnically possible to sign and verify segwit addresses, since ECDSA only de=
pends on the public key (hence why you need a private key to sign messages)=
.<br>
&gt; <br>
&gt; However, because there is no generally-accepted standard for signing s=
egwit messages, the wallets that do support this feature simply insert the =
segwit address into the address field. Verification also only works using t=
he procedure on that specific wallet software, if only because the conventi=
onal tools for verifying messages attempt to reconstruct a legacy address o=
nly.<br>
&gt; <br>
&gt; This BIP is not going to enforce anything, it&#39;s just going to set =
guidelines for writing a message signing and verification procedure.<br>
&gt; <br>
&gt; 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 mes=
sage signing format like those BIPs.<br>
&gt; <br>
&gt; In summary, in the verification part, the following address hashing al=
gorithms will be tried in sequence in an attempt to reconstruct the address=
 in the signed message:<br>
&gt; - P2PKH (legacy address)<br>
&gt; - P2WPKH-P2SH (nested segwit)<br>
&gt; - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native seg=
wit with version 0 as well as future native segwit address types such as Ta=
proot) - where MAX_WITNESS_VERSION is the maximum supported witness version=
 by the bech32 encoding.<br>
&gt; <br>
&gt; The verification procedure stops if any of these hashes yield the corr=
ect address, and fails if all of the above methods fail to reproduce the ad=
dress in the signed message.<br>
&gt; <br>
&gt; In the signing procedure, the only modification is the insertion of th=
e segwit address in place of the legacy address in the signed message.<br>
&gt; <br>
&gt; If this BIP is approved, it does not require any changes to existing s=
igned messages, and the original sign/verify algorithms will continue to in=
teroperate with this improved sign/verify algorithm, without any action nec=
essary from the developers.<br>
&gt; <br>
&gt; So as you can see, this is the entire framework of the BIP I plan to d=
raft. There is no need for any auxilliary feature additions into this BIP. =
I just want to hear the mailing list&#39;s advice about how I should draft =
such a BIP.<br>
&gt; <br>
&gt; - Ali<br>
&gt; <br>
&gt; PS. I am pretty sure that there is a BIP for the original signing meth=
od - what is its number?<br>
&gt; <br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000fd142e05e44398de--