Date: Fri, 05 Aug 2022 04:05:56 +0000
To: Luke Dashjr <luke@dashjr.org>
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <oqwpWAHa9lo-RuyC8iwnUDDMmMmQjM3i3a2wuXkN0t3GeoGdTnHoHPH90_KkaVsogyrn2hTFbUN6XKR364K3jOnplsBoKW2AaWJZfBKBqz4=@notatether.com>
In-Reply-To: <202208041926.37309.luke@dashjr.org>
References: <4Lz70s3l79z4x2h7@mail-41103.protonmail.ch>
 <20220804121851.7e4zoqxaaolseazn@artanis>
 <202208041926.37309.luke@dashjr.org>
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] BIP-notatether-signedmessage
Precedence: list

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 verificatio=
n 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 le=
gacy 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 mu=
ch less time to code the point-by-point steps than designing a class for BI=
P322 signatures, since the teams behind these wallets have to *agree* on ho=
w 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 repla=
ces BIP322), hence it requires a larger design effort on the part of wallet=
 developers to implement. Considering that the vast majority of them alread=
y sign messages using the current format, it makes complete sense to make t=
hem all conform to this BIP first, then we finish BIP322, and then make wal=
lets use that.

Message signatures are highly relied upon in some places (just to name a fe=
w, 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 us=
e a specific wallet (Electrum) that provides nonstandard signature verifica=
tion (it does *not* follow BIP137 despite supporting segwit messages, so th=
eir 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 mes=
sage signing and verification, but also implement, at a bare minimum, the l=
egacy and segwit address parts. And the reason I did not mandate this requi=
rement 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 thi=
s 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 Tap=
root signing format.

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

- Ali

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


> 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 vi=
ewed
> > at
> > https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedme=
ssag
> > e.mediawiki.
> >
> > For those who want a quick summary, it defines a step-by-step process f=
or
> > signing and verifying messages from legacy, native/nested segwit, and
> > taproot addresses. It does not define a new signature format itself, ex=
cept
> > 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 adde=
d
> > for backwards compatibility. Otherwise, it completely integrates BIP137
> > signatures.
> >
> > I am planning to move that format to its own BIP as soon as possible, i=
n
> > 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