From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 78914C002D for ; Wed, 20 Jul 2022 13:36:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5332660AD4 for ; Wed, 20 Jul 2022 13:36:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5332660AD4 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlJWLad4_AYz for ; Wed, 20 Jul 2022 13:36:44 +0000 (UTC) X-Greylist: delayed 00:05:20 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5251E607D1 Received: from smtp72.ord1c.emailsrvr.com (smtp72.ord1c.emailsrvr.com [108.166.43.72]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5251E607D1 for ; Wed, 20 Jul 2022 13:36:44 +0000 (UTC) X-Auth-ID: peter@coinkite.com Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: peter-AT-coinkite.com) with ESMTPSA id A7EE3C00C4; Wed, 20 Jul 2022 09:31:22 -0400 (EDT) Date: Wed, 20 Jul 2022 09:31:21 -0400 From: "Peter (Coinkite Inc)" To: Ali Sherief Message-ID: Reply-To: Peter References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid> <20220719104725.ppic7jy4ghfieeap@artanis> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xUUxadUa803MdFgj" Content-Disposition: inline In-Reply-To: Organization: Coinkite Inc. (coinkite.com) X-Classification-ID: 37f91285-488c-4b44-a3f6-b01754f86508-1-1 X-Mailman-Approved-At: Wed, 20 Jul 2022 21:46:02 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Trying all address types in message signing verification (BIP) 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: Wed, 20 Jul 2022 13:36:46 -0000 --xUUxadUa803MdFgj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ali. > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My pro= posal is simply going to standardize the practice of placing the segwit add= ress into the address field, and does not require alterations to the messag= e signing format like those BIPs. COLDCARD makes signatures exacly like that, when told to sign with a segwit= address: % ckcc msg -s Hello Hello =20 bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5 HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5m= NTWH9qkDoqZTpnPc=3D Unfortunately, I do not know of any "verifiers" that will accept the above = signature, but there is no alternative since the various BIP-322 proposals = never gained wide acceptance. Bitcoin Core does not support verifying that message, even though the UX ma= kes it look possible. In effect segwit features never got implemented to th= at depth in Core. It's sad because the community is not maintaining core (C= ore?) features to the same depth as Satoshi did when he was active in the p= roject. > PS. I am pretty sure that there is a BIP for the original signing method = - what is its number? My understanding that the original approach was directly from Satoshi himse= lf when the original client was written. It has never been codified in a BI= P as far as I know. A related issue the the "ascii armor" that is sometimes used. It's a little= like RFC2440 but newline-treatment = isn't defined well enough for good interoperability, in my personal experie= nce. So in summary... yes a "defacto" BIP is needed and useful to do, in my opin= ion. Then Core should be updated to support it as well. --- @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10 On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote: > [my third attempt at getting this message through. Surprisingly, I manage= d to send this at the second try with the correct SMTP, From, To and all, b= ut maybe it was caught in GreyListing (protonmail).] >=20 > I was thinking about creating a BIP to address the lack of standardizatio= n for Segwit message signatures, but I want some advice before proceeding. >=20 > The current state of affairs is that the wallets that do support signing = and verifying a bitcoin message can only sign legacy addresses. It is techn= ically possible to sign and verify segwit addresses, since ECDSA only depen= ds on the public key (hence why you need a private key to sign messages). >=20 > However, because there is no generally-accepted standard for signing segw= it messages, the wallets that do support this feature simply insert the seg= wit address into the address field. Verification also only works using the = procedure on that specific wallet software, if only because the conventiona= l tools for verifying messages attempt to reconstruct a legacy address only. >=20 > This BIP is not going to enforce anything, it's just going to set guideli= nes for writing a message signing and verification procedure. >=20 > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My pro= posal is simply going to standardize the practice of placing the segwit add= ress into the address field, and does not require alterations to the messag= e signing format like those BIPs. >=20 > In summary, in the verification part, the following address hashing algor= ithms will be tried in sequence in an attempt to reconstruct the address in= the signed message: > - P2PKH (legacy address) > - P2WPKH-P2SH (nested segwit) > - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit= with version 0 as well as future native segwit address types such as Tapro= ot) - where MAX_WITNESS_VERSION is the maximum supported witness version by= the bech32 encoding. >=20 > The verification procedure stops if any of these hashes yield the correct= address, and fails if all of the above methods fail to reproduce the addre= ss in the signed message. >=20 > In the signing procedure, the only modification is the insertion of the s= egwit address in place of the legacy address in the signed message. >=20 > If this BIP is approved, it does not require any changes to existing sign= ed messages, and the original sign/verify algorithms will continue to inter= operate with this improved sign/verify algorithm, without any action necess= ary from the developers. >=20 > So as you can see, this is the entire framework of the BIP I plan to draf= t. There is no need for any auxilliary feature additions into this BIP. I j= ust want to hear the mailing list's advice about how I should draft such a = BIP. >=20 > - Ali >=20 > PS. I am pretty sure that there is a BIP for the original signing method = - what is its number? >=20 --xUUxadUa803MdFgj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEERYl3mt/BTzMnU06oo6MbrVoqWxAFAmLYA6kACgkQo6MbrVoq WxAyhwgAsfRD0zjiuEtwA7tDg+rCrOzzljl3bXJD1sJ9PmgZbTYt5v8bc+4chD/t Q3KhFyNdWEoNVPPtgI2ExqmPFTFeYXoMbXWU6mth5LE6npc+468cUiutP3jIHM6E hSQ0bQm/dUAxNrN2G3cLKwkxMspQVxp4Ure+EvjM9be4QTBpM4Z/CMZXjugeaZ+O HOuSVdaYaWAO7ENJqhsWsRV8DL7IzNc/ho/p4OM63/zLA6DRqnffKG86Kirdvlhf rBiSrgx1g1NMhUgs3AOJCpzn9Mo1QcwWKYOjx1eXKXlrsh6jJtfL1VhS6/kyHjMl MeJnvoBCDo6a8pYD9B4mgaBXUnHMYQ== =Ly4+ -----END PGP SIGNATURE----- --xUUxadUa803MdFgj--