path: root/10/dbe4518d836eced7a906deb75a4c62399b24a1

Return-Path: <craigraw@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 02A84C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 07:06:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id D040583FB8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 07:06:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D040583FB8
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=IHH3d4YU
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 5rQtnV69tLwJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 07:06:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5527C83FB0
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [IPv6:2a00:1450:4864:20::12a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5527C83FB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 07:06:23 +0000 (UTC)
Received: by mail-lf1-x12a.google.com with SMTP id n18so1378233lfq.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 00:06:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=icVP7ZRDxgRTDHhwyxre8OCqLAkdvU6qkWdGVgHosZU=;
 b=IHH3d4YUtcQQecAvmaBjn6xfPtH/ZoBRC2HM+T8/xBIi+298ocMqpqKP//sy4SsPdE
 MkCzmNbPGDyEaB6SwvdmEKn9klSTAWS7qu4pb/U5Byal/WxsTVwdSVUISnVhcpSCVjMX
 MQJr4rU8PQPJFzFvrPwjGJFJFuUIW/BayAxlN2cKE7KUQszGQKluiVcqMM5m5aoUWHmB
 LTsqOBJWI6YVvVyt9O/yU0O6kusGwww4duqBrJP8ATdDMp7VCeCZRLj51VeTh3+MCeFH
 tIyi2kYdae3CXXFkhfUBX1QzlQ/2WUSZ09+O5XvdQe8all/cvxxsLrlPKM5eRaxTyMpU
 anZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=icVP7ZRDxgRTDHhwyxre8OCqLAkdvU6qkWdGVgHosZU=;
 b=C3/ZGqFat7mBxOJawN3FfOoFNunVuFTMz3+fMikMHPyUFJTwqVVP/S3d/CKEUcInGo
 J34LiLQUcFgmexoTlhbLLHg6gufSGrxqfrVo9D/Cv4bnp2ij1FqBusfSQUgceNJLEIx2
 I8orYQvjkRjQJ8vwzow4yj22vNUcYWH4yK6zov8GAumw2oxHhSRuGc4BciNbtQzGLNJn
 y2aJF98XvwnFEGEDiiFKbY9GBJ17Y+xlNxauopIq4nnHI1s/TRlA55S0HhMiov2/5/iA
 4lLDifulmoOMmeLKVdbwJ4DU0r/FpyzmTPsAYsGezDeJwC51vFpS0mhf/aBoHdOd7xaY
 L1Ig==
X-Gm-Message-State: AJIora+71izTj66+nZ/mBTwWov3g35UJ/e9KD2pSEbaRmTRSu5vDm2ip
 Cmto4k5a7hefzshjCWkG7Iqjrx7fXmbwriil5Ms=
X-Google-Smtp-Source: AGRyM1v/t5zPPqD/96m7eu0WGmy92VxXcjkb+iwLOlzWGiJ9u60joVVud1DtWsj4C07eFUREtaa6x6ST+I8VsnDdt0Q=
X-Received: by 2002:a05:6512:2354:b0:488:7bf6:e853 with SMTP id
 p20-20020a056512235400b004887bf6e853mr20107964lfu.659.1658387180619; Thu, 21
 Jul 2022 00:06:20 -0700 (PDT)
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>
 <CAB3F3Du0OXcUvi6h8v0VZEj4cG24DJs04Vho8sM4Frhdhj5DrA@mail.gmail.com>
In-Reply-To: <CAB3F3Du0OXcUvi6h8v0VZEj4cG24DJs04Vho8sM4Frhdhj5DrA@mail.gmail.com>
From: Craig Raw <craigraw@gmail.com>
Date: Thu, 21 Jul 2022 09:06:08 +0200
Message-ID: <CAPR5oBMF0WdzDFnytLJjE205KUYR_WGVUxJ5AjwU-0KZgwvkOA@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cd0bba05e44b5ae6"
X-Mailman-Approved-At: Thu, 21 Jul 2022 08:30:33 +0000
Cc: Ali Sherief <ali@notatether.com>, Peter <peter@coinkite.com>
Subject: Re: [bitcoin-dev] Trying all address types in message signing
 verification (BIP)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2022 07:06:25 -0000

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

> Unfortunately, I do not know of any "verifiers" that will accept the
above signature

Sparrow verifies this signature.

The approach used is to convert the message and signature to a public key,
trying first BIP137 and then the approach used by Electrum (they differ in
treatment of the signature header for segwit P2SH). The script type is
extracted from the provided address and compared against the address
constructed with the public key using the same script type. i.e. There is
no need to iterate through all script types, since the script type is
implicitly provided in the address.

Craig

On Wed, Jul 20, 2022 at 11:51 PM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; Unfortunately, I do not know of any &quot;verifiers&q=
uot; that will accept the above signature<div><br></div><div>Sparrow verifi=
es this signature.=C2=A0</div><div><br></div><div>The approach used is to c=
onvert the message and signature to a public key, trying first BIP137 and t=
hen the approach used by Electrum (they differ in treatment of the signatur=
e header for segwit P2SH). The script type is extracted from the provided a=
ddress and compared against the address constructed with the public key usi=
ng the same script type. i.e. There is no need to iterate through all scrip=
t types, since the script type is implicitly provided in the address.</div>=
<div><br></div><div>Craig</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Wed, Jul 20, 2022 at 11:51 PM Greg Sander=
s via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">Please see BIP32=
2=C2=A0<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0322.medi=
awiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-03=
22.mediawiki</a></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);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" rel=3D"noreferrer"=
 target=3D"_blank">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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000cd0bba05e44b5ae6--