path: root/af/173a40aa67785012359d72040239bcad028a5d

Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9F734C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Aug 2022 04:06:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 6339C41CCE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Aug 2022 04:06:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6339C41CCE
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=notatether.com header.i=@notatether.com
 header.a=rsa-sha256 header.s=protonmail header.b=I/g7uVgw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7jNxjkZ-Aijl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Aug 2022 04:06:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1989241CCA
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 1989241CCA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Aug 2022 04:06:09 +0000 (UTC)
Date: Fri, 05 Aug 2022 04:05:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
 s=protonmail; t=1659672366; x=1659931566;
 bh=E6jd5P8jSL50HVdryzCwuzST5rDgROBhqHcL77YuTcM=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
 Feedback-ID:Message-ID;
 b=I/g7uVgwm40oXoAXQ2zD24Rl+jPjkSBfuEyxLDCBHw7V58iV30izhfKXfLictbrH/
 8oGnyDlfGzzBL7uc4cuojeb2YK7ox4F/JPj4mSdnQT/SA9atG0DUJnh/eBj41KZOZn
 qsPqJF0zia4RINyRNp8DksAEO+mY7uWSU/Rufl7verMCssPZ/SSd9qCoAoaOZ275aL
 QBi7BrjXNh5hpjq3bYYBXJ/OY2ZGqkELQEsnlWlYUU1wziPJNOx5uAvrly2DoWDn1j
 NtgFFY6VQ9Woe+f/JhI9z3Vo2qeQuorS2keiKFjDy/Lqek6DNuyCMJDTcayT4yBXt2
 XNj4HTKocxWBw==
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
X-Mailman-Approved-At: Fri, 05 Aug 2022 08:51:31 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP-notatether-signedmessage
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 04:06:13 -0000

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