📅 Original date posted:2022-08-05
📝 Original message: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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Ali Sherief [ARCHIVE] /
npub1xq…q2u5f
2023-06-07 23:12:29
in reply to nevent1q…dw2d
Author Public Key
npub1xq96jnxfzrdq4zgre20yqjrjsd29vcw8ymypl4v59cg6q6p66cts8q2u5fPublished at
2023-06-07 23:12:29Event JSON
{
"id": "800c56de08676c578e5263293411980b550df949e898a9485d8e9e294b3fc745",
"pubkey": "300ba94cc910da0a8903ca9e40487283545661c726c81fd5942e11a0683ad617",
"created_at": 1686179549,
"kind": 1,
"tags": [
[
"e",
"fb0c51c47fb0dc7c36668ecc3d86fd399320d3c6e12d870c36c10551b62e25cc",
"",
"root"
],
[
"e",
"879185899d95a4d755d0d1b896bf3044840ef96bf143787596dca31284023353",
"",
"reply"
],
[
"p",
"82ecdad91df577efea826941d0036ef3c9e1f9734527aa6987b3a1a3676465d5"
]
],
"content": "📅 Original date posted:2022-08-05\n📝 Original message:Yeah, I have a specific reason to advance this first (emphasis on the word first).\n\nI 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.]\n\nThat 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.\n\nMessage 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).\n\nThat 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.\n\nThis 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.\n\nLike 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.\n\n- Ali\n\n------- Original Message -------\nOn Thursday, August 4th, 2022 at 10:26 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\n\u003e Any reason not to just help Kalle out with BIP 322?\n\u003e\n\u003e https://github.com/bitcoin/bips/pull/1347\n\u003e\n\u003e\n\u003e On Thursday 04 August 2022 12:18:56 Ali Sherief via bitcoin-dev wrote:\n\u003e\n\u003e \u003e Hi,\n\u003e \u003e\n\u003e \u003e I have created a new BIP, called notatether-signedmessage. It can be viewed\n\u003e \u003e at\n\u003e \u003e https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessag\n\u003e \u003e e.mediawiki.\n\u003e \u003e\n\u003e \u003e For those who want a quick summary, it defines a step-by-step process for\n\u003e \u003e signing and verifying messages from legacy, native/nested segwit, and\n\u003e \u003e taproot addresses. It does not define a new signature format itself, except\n\u003e \u003e in the case of Taproot. For those addresses, I have defined a signature\n\u003e \u003e format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x\n\u003e \u003e coordinate of a public key. This is required to run the BIP340 Schnorr\n\u003e \u003e verify algorithm using only the signature - and the header byte is added\n\u003e \u003e for backwards compatibility. Otherwise, it completely integrates BIP137\n\u003e \u003e signatures.\n\u003e \u003e\n\u003e \u003e I am planning to move that format to its own BIP as soon as possible, in\n\u003e \u003e lieu that it is unacceptable to define formats in an Informational BIP.\n\u003e \u003e\n\u003e \u003e Please leave your comments in this mailing list. CC'ing BIP editors.\n\u003e \u003e\n\u003e \u003e - Ali\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "51cc7f4bb704039ab3d2830434504a9ac119e7247f848a66e6a5ca4a977a753cf18367f202141cff7a9608025cd2247d73e07e165b75a38cbe6c10907ac2d426"
}