path: root/c4/fb351f07112cdf7013d9dff375e79775dea378

Return-Path: <ali@notatether.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B86F9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 05:37:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D89AA60A98
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 05:37:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D89AA60A98
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=notatether.com header.i=@notatether.com
 header.a=rsa-sha256 header.s=protonmail header.b=f3842D1A
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Level: 
X-Spam-Status: No, score=-1.603 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, PDS_BTC_ID=0.499,
 SPF_HELO_PASS=-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 IbF6bkoEAifh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 05:37:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 71EE360A81
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
 [185.70.41.103])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 71EE360A81
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Jul 2022 05:37:36 +0000 (UTC)
Date: Thu, 21 Jul 2022 05:36:11 +0000
Authentication-Results: mail-41103.protonmail.ch;
 dkim=pass (2048-bit key) header.d=notatether.com header.i=@notatether.com
 header.b="f3842D1A"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
 s=protonmail; t=1658381778; x=1658640978;
 bh=vu4akmB5U63p5bYxr4NRZmqMAjG7Bk6lPk6IlnS+IUQ=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
 Feedback-ID:Message-ID;
 b=f3842D1Arfk3AKKhE1Znci21eo1FX03e4MVi9I62t4JPJO6iRiWSBh5mhb+VEfAPx
 cAWpcw3ag1K/vz81BJsEJd2PWLwRjywlJsBL/13cTRT08fZTWj+qO83wNOlK7ZUU3K
 8eF/qUaHAADsh1mdTjCiJ6sAnNSPnTn+TiJha9Jo7TdAWCcO1ykbZipU5erNc9yNeV
 A5mY/X8waUlCUjmRWbSnJoqYuaYm7GQHRUxaWkVVhuoSxxPkIoZkCrb0wvtOfnoGUO
 Qz6hPC5bXJGNZS8tL4Dcb1Cab8wuXA5h7v9Q6cydkiZfp+bLAIU+IWxXFI3W0Cu2CE
 MDpiuT5bCOfxA==
To: Peter <peter@coinkite.com>
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <KS9u6Zywp61RSBB0mQd0u9ULqU-tg90_VF5VYi8bOb1b2KpJ7SCdunNDbYz3XYnsykahVLBeSocwoabj9xbiI0k7gJIJtuxCJAtSFzTux-8=@notatether.com>
In-Reply-To: <YtgDqWSIbX8EJc3B@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>
 <YtgDqWSIbX8EJc3B@coinkite.com>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 21 Jul 2022 08:30:33 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
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 05:37:39 -0000

Hi Peter,

> COLDCARD makes signatures exacly like that, when told to sign with a segw=
it address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNT=
WH9qkDoqZTpnPc=3D
>
> Unfortunately, I do not know of any "verifiers" that will accept the abov=
e signature, but there is no alternative since the various BIP-322 proposal=
s never gained wide acceptance.

This is largely why I avoided basing my idea off of BIP-322. Not only does =
a BIP has a higher chance of acceptance the less aspects it modifies, but I=
 feel that although its not urgent (such as, for example, the segwit deploy=
ment BIP), this BIP should be made as soon as possible. It's also why I avo=
ided specifying anything about testnet or regtest address singing - thankfu=
lly, I have yet to see ayone sign messages from these networks.

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

Yes, if it looks possible from the UX, chances are that its very straightfo=
rward to implement in code. That's why I'm not expecting any problems when =
I finally draft the BIP.

In my original plans, I said the verifier was going to try Legacy, Nested S=
egwit, and Native Segwit encodings in sequence, but now, I think this step-=
by-step procedure is unnecessary. The correct encoding can be guessed by lo=
oking at the address prefix:

- If it starts with a "1", attempt the Legacy encoding. (Fail verification =
if it does not yield the correct address).
- If it starts with a "3", attempt the Nested Segwit encoding. (Fail verifi=
cation if it does not yield the correct address).
- If it starts with a "bc1", fetch the version number from the immediately =
following character, and attempt the Native Segwit encoding with that versi=
on number. (Fail verification if it does not yield the correct address).
- If it starts with any other prefix, fail verification.

In my opinion, the signing and verification processes have to be precisely =
defined in the BIP - to be exactly the same as it presently is, and then th=
ese additions - to ensure that the BIP clearly deescribes how signing and v=
erification should be implemented today - in addition to "tomorrow" when th=
e BIP is widely accepted.

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

Since I already plan on adding a Python example for the signing and verific=
ation process, it will be a straightforward process to translate it to C++ =
without even minor interface/implementation difficulties.

Since I can't think of any more ways to streamline the BIP, I'm going to st=
art a draft along these principles shortly.

- Ali

On Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) <peter@coink=
ite.com> wrote:


> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My p=
roposal is simply going to standardize the practice of placing the segwit a=
ddress into the address field, and does not require alterations to the mess=
age signing format like those BIPs.
>
>
> COLDCARD makes signatures exacly like that, when told to sign with a segw=
it address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNT=
WH9qkDoqZTpnPc=3D
>
> Unfortunately, I do not know of any "verifiers" that will accept the abov=
e signature, but there is no alternative since the various BIP-322 proposal=
s 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 metho=
d - what is its number?
>
>
> My understanding that the original approach was directly from Satoshi him=
self 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 litt=
le 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 op=
inion. 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 mana=
ged 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 standardizat=
ion for Segwit message signatures, but I want some advice before proceeding=
.
> >
> > The current state of affairs is that the wallets that do support signin=
g and verifying a bitcoin message can only sign legacy addresses. It is tec=
hnically possible to sign and verify segwit addresses, since ECDSA only dep=
ends on the public key (hence why you need a private key to sign messages).
> >
> > However, because there is no generally-accepted standard for signing se=
gwit messages, the wallets that do support this feature simply insert the s=
egwit address into the address field. Verification also only works using th=
e procedure on that specific wallet software, if only because the conventio=
nal tools for verifying messages attempt to reconstruct a legacy address on=
ly.
> >
> > This BIP is not going to enforce anything, it's just going to set guide=
lines for writing a message signing and verification procedure.
> >
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My p=
roposal is simply going to standardize the practice of placing the segwit a=
ddress into the address field, and does not require alterations to the mess=
age signing format like those BIPs.
> >
> > In summary, in the verification part, the following address hashing alg=
orithms 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 segw=
it with version 0 as well as future native segwit address types such as Tap=
root) - 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 corre=
ct address, and fails if all of the above methods fail to reproduce the add=
ress 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 si=
gned messages, and the original sign/verify algorithms will continue to int=
eroperate with this improved sign/verify algorithm, without any action nece=
ssary from the developers.
> >
> > So as you can see, this is the entire framework of the BIP I plan to dr=
aft. 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 metho=
d - what is its number?



Owner and administrator of https://notatether.com - Run Tools & Apps Online=
 or Buy an API Key


------- Original Message -------
On Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) <peter@coink=
ite.com> wrote:


> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My p=
roposal is simply going to standardize the practice of placing the segwit a=
ddress into the address field, and does not require alterations to the mess=
age signing format like those BIPs.
>
>
> COLDCARD makes signatures exacly like that, when told to sign with a segw=
it address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNT=
WH9qkDoqZTpnPc=3D
>
> Unfortunately, I do not know of any "verifiers" that will accept the abov=
e signature, but there is no alternative since the various BIP-322 proposal=
s 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 metho=
d - what is its number?
>
>
> My understanding that the original approach was directly from Satoshi him=
self 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 litt=
le 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 op=
inion. 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 mana=
ged 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 standardizat=
ion for Segwit message signatures, but I want some advice before proceeding=
.
> >
> > The current state of affairs is that the wallets that do support signin=
g and verifying a bitcoin message can only sign legacy addresses. It is tec=
hnically possible to sign and verify segwit addresses, since ECDSA only dep=
ends on the public key (hence why you need a private key to sign messages).
> >
> > However, because there is no generally-accepted standard for signing se=
gwit messages, the wallets that do support this feature simply insert the s=
egwit address into the address field. Verification also only works using th=
e procedure on that specific wallet software, if only because the conventio=
nal tools for verifying messages attempt to reconstruct a legacy address on=
ly.
> >
> > This BIP is not going to enforce anything, it's just going to set guide=
lines for writing a message signing and verification procedure.
> >
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My p=
roposal is simply going to standardize the practice of placing the segwit a=
ddress into the address field, and does not require alterations to the mess=
age signing format like those BIPs.
> >
> > In summary, in the verification part, the following address hashing alg=
orithms 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 segw=
it with version 0 as well as future native segwit address types such as Tap=
root) - 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 corre=
ct address, and fails if all of the above methods fail to reproduce the add=
ress 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 si=
gned messages, and the original sign/verify algorithms will continue to int=
eroperate with this improved sign/verify algorithm, without any action nece=
ssary from the developers.
> >
> > So as you can see, this is the entire framework of the BIP I plan to dr=
aft. 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 metho=
d - what is its number?