MIME-Version: 1.0
References: <4Lz70s3l79z4x2h7@mail-41103.protonmail.ch>
 <20220804121851.7e4zoqxaaolseazn@artanis>
In-Reply-To: <20220804121851.7e4zoqxaaolseazn@artanis>
From: Pavol Rusnak <stick@satoshilabs.com>
Date: Fri, 5 Aug 2022 11:12:20 +0200
Message-ID: <CAF90AvmxH-fr1qnL7McdvBs56N5G-q8OYLj+dmBGSVm38F=Urg@mail.gmail.com>
To: Ali Sherief <ali@notatether.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aa1a3305e57addd0"
Cc: luke_bipeditor@dashjr.org
Subject: Re: [bitcoin-dev] BIP-notatether-signedmessage
Precedence: list

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

Hi Ali!

Nice work. Since it seems this is a strict superset of BIP137, why not just
focus on things that you are adding (Taproot) while saying your BIP is an
expansion of BIP137?

Your approach make it unnecessarily hard to figure out whether you are
changing anything in handling of ECDSA signature types or not. If it was
clearly stated you are just expanding BIP137 and removes everything that=E2=
=80=99s
already described in BIP137, it would be much more obvious to everyone.


On Thu 4. 8. 2022 at 17:49, Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I have created a new BIP, called notatether-signedmessage. It can be
> viewed at
> https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmess=
age.mediawiki
> .
>
> For those who want a quick summary, it defines a step-by-step process for
> signing and verifying messages from legacy, native/nested segwit, and
> taproot addresses. It does not define a new signature format itself, exce=
pt
> in the case of Taproot. For those addresses, I have defined a signature
> format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x
> coordinate of a public key. This is required to run the BIP340 Schnorr
> verify algorithm using only the signature - and the header byte is added
> for backwards compatibility. Otherwise, it completely integrates BIP137
> signatures.
>
> I am planning to move that format to its own BIP as soon as possible, in
> lieu that it is unacceptable to define formats in an Informational BIP.
>
> Please leave your comments in this mailing list. CC'ing BIP editors.
>
> - Ali
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--=20
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs

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

<div dir=3D"auto">Hi Ali!</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Nice work. Since it seems this is a strict superset of BIP137, why not ju=
st focus on things that you are adding (Taproot) while saying your BIP is a=
n expansion of BIP137?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Y=
our approach make it unnecessarily hard to figure out whether you are chang=
ing anything in handling of ECDSA signature types or not. If it was clearly=
 stated you are just expanding BIP137 and removes everything that=E2=80=99s=
 already described in BIP137, it would be much more obvious to everyone.=C2=
=A0</div><div dir=3D"auto"><br></div><div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu 4. 8. 2022 at 17:49, Ali Sherief=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204=
,204)">Hi,<br>
<br>
I have created a new BIP, called notatether-signedmessage. It can be viewed=
 at <a href=3D"https://github.com/ZenulAbidin/bips/blob/master/bip-notateth=
er-signedmessage.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawik=
i</a>.<br>
<br>
For those who want a quick summary, it defines a step-by-step process for s=
igning and verifying messages from legacy, native/nested segwit, and taproo=
t addresses. It does not define a new signature format itself, except in th=
e case of Taproot. For those addresses, I have defined a signature format t=
hat has 1 byte header/recID, 64 bytes signature, and 32 bytes x coordinate =
of a public key. This is required to run the BIP340 Schnorr verify algorith=
m using only the signature - and the header byte is added for backwards com=
patibility. Otherwise, it completely integrates BIP137 signatures.<br>
<br>
I am planning to move that format to its own BIP as soon as possible, in li=
eu that it is unacceptable to define formats in an Informational BIP.<br>
<br>
Please leave your comments in this mailing list. CC&#39;ing BIP editors.<br=
>
<br>
- Ali<br>
<br>
_______________________________________________<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></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><=
div></div><div>Best Regards / S pozdravom,</div><div><br></div><div>Pavol &=
quot;stick&quot; Rusnak</div><div>Co-Founder, SatoshiLabs</div></div></div>=
</div></div>

--000000000000aa1a3305e57addd0--