From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9F734C002D for ; 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 ; 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 ; 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 ; 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 From: Ali Sherief Reply-To: Ali Sherief Message-ID: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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