path: root/49/976d7d0d69d74b69d7feb3f818918b48785677

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 98F70C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Jul 2022 21:51:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 6850761109
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Jul 2022 21:51:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6850761109
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=iGPFNwsk
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.349
X-Spam-Level: 
X-Spam-Status: No, score=-1.349 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_ENVFROM_END_DIGIT=0.25, 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Fi763Q7sWl0N
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Jul 2022 21:51:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1C30160B4E
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
 [IPv6:2607:f8b0:4864:20::1029])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1C30160B4E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Jul 2022 21:51:05 +0000 (UTC)
Received: by mail-pj1-x1029.google.com with SMTP id gq7so2787517pjb.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Jul 2022 14:51:05 -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=oNrmBjh3+ExIS3Qq7UzwDDHzBLnFWHH/gILRqqqp4sM=;
 b=iGPFNwsk7sCUyNeczR10nntzMPq+QDc6S2fSu9Awo1v0GW/70Sfi0dXi7Mgg/VgoSZ
 0eKnF1Pjau35xZiH2aC7MypY2tpoMQPqV2k/nbY39jYPhN/ntb3XxTqmMaqePo+7TG1j
 6hheZa6r1mqS5iLWJ2e24YD/CB3q2FD1naM7kdpA7n7cQbs0NiO7IEJ6EVXgETJWVlRB
 TJf/OeKwMfREpMQvsTTnLvcketrQRPDZhfEFo3/TVSlCVQmdQ8SWqEkwij9x+k+s++Fw
 zw5B1Xv7yO20d5dEmr6TDc0HmoTMnPU0D8oFpEjtwjvVqA3whFuNg9P4UZRW6CFC+ZlH
 BOPA==
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=oNrmBjh3+ExIS3Qq7UzwDDHzBLnFWHH/gILRqqqp4sM=;
 b=OfMimp4+4dZhlyX3eW2gMpTPW6QOCtaVwuVUHQgA1w5whW/vAI77p7Nc/R1l8kWk0B
 D737kTxiSC4iiJGV4ZK20s9vXzGUZxTWJX6kubLeQFNjCqpVKkniCG+wj23R3SVgd9o5
 7981f5bSQqfw9nMu1SPqQpZXselOzxthHWMZAQFLYzpD+lrkWqIzzn6xCefbUsWqzQSZ
 YExIoTNgNZin3zpzKvPH17k3JhKSS5Ac3llJ9H3EE+RyoXYftn/A3myHIY/af0z+hyIH
 YX7X+xWBgeI+5g35cv767BP90PRldvgLtmvzkgFunugDsS1eQK4BaXI27oYYqJym11Hd
 e9aQ==
X-Gm-Message-State: AJIora8xtpMP6YjjkLl0eBk4inojUxy3pKVOdWE0RD+pFciMSUJbpJra
 iTws+UNOMfeJbgSPZ1txAw6cll5ncFkNUaoTGr8=
X-Google-Smtp-Source: AGRyM1tiaxrHxtEyW6wC3bDph6aVpZYFDFxB8Hyl9i2y7778OVHRLuN+MWaMym0An5E7zHGlou0h6fTv5M1HzrImw54=
X-Received: by 2002:a17:903:2ce:b0:16c:f66b:50fa with SMTP id
 s14-20020a17090302ce00b0016cf66b50famr16178545plk.109.1658353864215; Wed, 20
 Jul 2022 14:51:04 -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>
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)
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: Wed, 20 Jul 2022 21:51:06 -0000

--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--