[bitcoin-dev] BIP-notatether-signedmessage

[bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief]

Hi,

I have created a new BIP, called notatether-signedmessage. It can be viewed at https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.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, except 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

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief]

My sincere apologies, the link returns a 404 (trailing dot). The correct link to the BIP is https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki

-Ali

------- Original Message -------
On Thursday, August 4th, 2022 at 3:18 PM, Ali Sherief <ali@notatether.com> 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-signedmessage.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, except 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

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Peter (Coinkite Inc)]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Thanks for doing this, it looks great Ali!

COLDCARD and other Coinkite products will conform to this spec, if we don't already.

On Thu, Aug 04, 2022 at 12:18:56PM +0000, Ali Sherief 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-signedmessage.mediawiki.
> 
...

---
@DocHEX  ||  Coinkite  ||  PGP: A3A31BAD 5A2A5B10


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief]

Yeah, I have a specific reason to advance this first (emphasis on the word first).

I briefly mentioned in the BIP that BIP322 has superior message verification capabilities. This is true, but it suffers from the drawback that wallets are not using it. What they are using right now is a chaotic mixture of legacy address sign/verify and nonstandard segwit sign/verify. Attempting to enforce BIP322 on them in this stage will just create an N+1 problem, so an effort has to be made first to transfer these N signing implementations to a common ground, with as little as possible developer effort - it takes much less time to code the point-by-point steps than designing a class for BIP322 signatures, since the teams behind these wallets have to *agree* on how to code such a change. This ultimately decides whether or not the wallets implement such features as BIP322 or this BIP. [this paragraph is the meat of the reasoning.]

That is to say, BIP322 is more complex than this BIP (which in no way replaces BIP322), hence it requires a larger design effort on the part of wallet developers to implement. Considering that the vast majority of them already sign messages using the current format, it makes complete sense to make them all conform to this BIP first, then we finish BIP322, and then make wallets use that.

Message signatures are highly relied upon in some places (just to name a few, at many mining pools e.g. Slushpool, and the Bitcointalk forum), and it is unreasonable to expect users to cling on to an old address format, or use a specific wallet (Electrum) that provides nonstandard signature verification (it does *not* follow BIP137 despite supporting segwit messages, so their signatures are non-portable).

That is why it is necessary at the present moment to ensure as many wallets are possible are not only using the specification in my BIP to perform message signing and verification, but also implement, at a bare minimum, the legacy and segwit address parts. And the reason I did not mandate this requirement is the BIP is that wallets do not provide legacy addresses, then it makes no sense for them to add the sign/verify code for legacy addresses as well.

This BIP is kind of like a "bumper car", in that it forces compliance with previous BIPs that extend the message signing format, in particular BIP137. I admit that the Taproot signature format should not be located inside this BIP - I want to keep it strictly Informational, but rather, it should be contained in a newer Standards Track BIP that supersedes BIP137 - it's only task is to define everything BIP137 already defines, and  also add the Taproot signing format.

Like I said in the BIP, just making a proposal will not solve all these problems. It will only solve half of them, and the other half has to be solved by getting the other wallet implementations (Armory, Wasabi, BitcoinJ, Samourai, Mycelium, Electrum, and Trezor/Ledger among others) to implement this standard. It is not a difficult task but it's a non-trivial one, and we ought to be at least half-way to the finish line by assigning a number to this.

- Ali

------- Original Message -------
On Thursday, August 4th, 2022 at 10:26 PM, Luke Dashjr <luke@dashjr.org> wrote:


> Any reason not to just help Kalle out with BIP 322?
>
> https://github.com/bitcoin/bips/pull/1347
>
>
> On Thursday 04 August 2022 12:18:56 Ali Sherief via bitcoin-dev 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-signedmessag
> > e.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, except
> > 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

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Luke Dashjr]

On Friday 05 August 2022 04:05:56 Ali Sherief wrote:
> Yeah, I have a specific reason to advance this first (emphasis on the word
> first).
>
> I briefly mentioned in the BIP that BIP322 has superior message
> verification capabilities. This is true, but it suffers from the drawback
> that wallets are not using it.

Likely because it is a draft and incomplete.

> Message signatures are highly relied upon in some places (just to name a
> few, at many mining pools e.g. Slushpool, and the Bitcointalk forum), 

I'm not aware of any using the current message signatures _correctly_.
Note they are not useful for proving that you sent a transaction, nor have the 
ability to send a transaction or access to bitcoins.

> This BIP is kind of like a "bumper car", in that it forces compliance with
> previous BIPs that extend the message signing format, in particular BIP137.

BIPs can't force anything, they're just documentation.

IMO, there is no benefit to an additional message signing standard, especially 
one that doesn't address the problems with the current standard or (at 
present) BIP322.

Luke

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

> IMO, there is no benefit to an additional message signing standard, especially
> one that doesn't address the problems with the current standard or (at
> present) BIP322.

In that case, I propose the following:

- I scrap the Taproot/Schorr and the two extensions inside the BIP, which will leave it with only parts and formats which have already been standardized (effectively, the legacy and segwit addresses).

Because here's the thing: The reason why wallets are not implementing sign/verify correctly is because there is no reference manual for doing so. This informational BIP is supposed to solve that problem by providing only a list of instructions for computing ECSDA sign/verify correctly.

Also, it is not visible right now, but there will also be a reference implementation so that wallet developers can actually code them correctly, as you've stated.

- Ali

On Fri, Aug 5, 2022 at 9:51 AM, Luke Dashjr <luke@dashjr.org> wrote:

> On Friday 05 August 2022 04:05:56 Ali Sherief wrote:
>> Yeah, I have a specific reason to advance this first (emphasis on the word
>> first).
>>
>> I briefly mentioned in the BIP that BIP322 has superior message
>> verification capabilities. This is true, but it suffers from the drawback
>> that wallets are not using it.
>
> Likely because it is a draft and incomplete.
>
>> Message signatures are highly relied upon in some places (just to name a
>> few, at many mining pools e.g. Slushpool, and the Bitcointalk forum),
>
> I'm not aware of any using the current message signatures _correctly_.
> Note they are not useful for proving that you sent a transaction, nor have the
> ability to send a transaction or access to bitcoins.
>
>> This BIP is kind of like a "bumper car", in that it forces compliance with
>> previous BIPs that extend the message signing format, in particular BIP137.
>
> BIPs can't force anything, they're just documentation.
>
> IMO, there is no benefit to an additional message signing standard, especially
> one that doesn't address the problems with the current standard or (at
> present) BIP322.
>
> Luke

[-- Attachment #2: Type: text/html, Size: 2581 bytes --]

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Pavol Rusnak]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

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’s
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-signedmessage.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, except
> 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
>
-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs

[-- Attachment #2: Type: text/html, Size: 2893 bytes --]

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

That's actually a good idea. Perhaps I can move the algorithms (of BIP137) and stuff to Bitcoin Wiki, and then convert the BIP to strictly a "Taproot message signing BIP".

Even though I already know the chances of such a BIP being numbered is low, at least the most important part will be accomplished already (get everybody to use BIP137, and later once BIP322 is finished make people use that).

I ultimately prefer that everyone should use BIP322 eventually, though it should have some kind of RFC2440-like format for maximum user-friendliness. Perhaps bit by bit, the message sanitization can be introduced as well.

- Ali

On Fri, Aug 5, 2022 at 12:12 PM, Pavol Rusnak <stick@satoshilabs.com> wrote:

> 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’s 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-signedmessage.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, except 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
>
> --
>
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> Co-Founder, SatoshiLabs

[-- Attachment #2: Type: text/html, Size: 3861 bytes --]