Date: Thu, 21 Jul 2022 05:36:11 +0000
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
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

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?