diff options
| author | Peter (Coinkite Inc) <peter@coinkite.com> | 2022-07-20 09:31:21 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-20 13:36:45 +0000 |
| commit | 5fdf509aefc66021d6e2207f7eac23268bfc8d30 (patch) | |
| tree | f95bfc030bc971c5a68381070ecd3e56a97a4aae | |
| parent | 8213368cbc4d5374ca56823bd7cf5ce06c9c12aa (diff) | |
| download | pi-bitcoindev-5fdf509aefc66021d6e2207f7eac23268bfc8d30.tar.gz pi-bitcoindev-5fdf509aefc66021d6e2207f7eac23268bfc8d30.zip | |
Re: [bitcoin-dev] Trying all address types in message signing verification (BIP)
| -rw-r--r-- | 44/c23d3f4e2018a87c9b4dfb6bfd0b9327032dc5 | 197 |
1 files changed, 197 insertions, 0 deletions
diff --git a/44/c23d3f4e2018a87c9b4dfb6bfd0b9327032dc5 b/44/c23d3f4e2018a87c9b4dfb6bfd0b9327032dc5 new file mode 100644 index 000000000..3516af815 --- /dev/null +++ b/44/c23d3f4e2018a87c9b4dfb6bfd0b9327032dc5 @@ -0,0 +1,197 @@ +Return-Path: <peter@coinkite.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 78914C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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)" <peter@coinkite.com> +To: Ali Sherief <ali@notatether.com> +Message-ID: <YtgDqWSIbX8EJc3B@coinkite.com> +Reply-To: Peter <peter@coinkite.com> +References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid> + <mailman.84940.1658205911.8511.bitcoin-dev@lists.linuxfoundation.org> + <20220719104725.ppic7jy4ghfieeap@artanis> + <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="xUUxadUa803MdFgj" +Content-Disposition: inline +In-Reply-To: <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com> +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" + <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 <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: 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 <https://www.ietf.org/rfc/rfc2440.txt> 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-- + |