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 <l...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
