Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98F70C002D for ; Wed, 20 Jul 2022 21:51:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 6850761109 for ; Wed, 20 Jul 2022 21:51:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6850761109 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=iGPFNwsk X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Fi763Q7sWl0N for ; Wed, 20 Jul 2022 21:51:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1C30160B4E Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1C30160B4E for ; Wed, 20 Jul 2022 21:51:05 +0000 (UTC) Received: by mail-pj1-x1029.google.com with SMTP id gq7so2787517pjb.1 for ; Wed, 20 Jul 2022 14:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oNrmBjh3+ExIS3Qq7UzwDDHzBLnFWHH/gILRqqqp4sM=; b=iGPFNwsk7sCUyNeczR10nntzMPq+QDc6S2fSu9Awo1v0GW/70Sfi0dXi7Mgg/VgoSZ 0eKnF1Pjau35xZiH2aC7MypY2tpoMQPqV2k/nbY39jYPhN/ntb3XxTqmMaqePo+7TG1j 6hheZa6r1mqS5iLWJ2e24YD/CB3q2FD1naM7kdpA7n7cQbs0NiO7IEJ6EVXgETJWVlRB TJf/OeKwMfREpMQvsTTnLvcketrQRPDZhfEFo3/TVSlCVQmdQ8SWqEkwij9x+k+s++Fw zw5B1Xv7yO20d5dEmr6TDc0HmoTMnPU0D8oFpEjtwjvVqA3whFuNg9P4UZRW6CFC+ZlH BOPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oNrmBjh3+ExIS3Qq7UzwDDHzBLnFWHH/gILRqqqp4sM=; b=OfMimp4+4dZhlyX3eW2gMpTPW6QOCtaVwuVUHQgA1w5whW/vAI77p7Nc/R1l8kWk0B D737kTxiSC4iiJGV4ZK20s9vXzGUZxTWJX6kubLeQFNjCqpVKkniCG+wj23R3SVgd9o5 7981f5bSQqfw9nMu1SPqQpZXselOzxthHWMZAQFLYzpD+lrkWqIzzn6xCefbUsWqzQSZ YExIoTNgNZin3zpzKvPH17k3JhKSS5Ac3llJ9H3EE+RyoXYftn/A3myHIY/af0z+hyIH YX7X+xWBgeI+5g35cv767BP90PRldvgLtmvzkgFunugDsS1eQK4BaXI27oYYqJym11Hd e9aQ== X-Gm-Message-State: AJIora8xtpMP6YjjkLl0eBk4inojUxy3pKVOdWE0RD+pFciMSUJbpJra iTws+UNOMfeJbgSPZ1txAw6cll5ncFkNUaoTGr8= X-Google-Smtp-Source: AGRyM1tiaxrHxtEyW6wC3bDph6aVpZYFDFxB8Hyl9i2y7778OVHRLuN+MWaMym0An5E7zHGlou0h6fTv5M1HzrImw54= X-Received: by 2002:a17:903:2ce:b0:16c:f66b:50fa with SMTP id s14-20020a17090302ce00b0016cf66b50famr16178545plk.109.1658353864215; Wed, 20 Jul 2022 14:51:04 -0700 (PDT) MIME-Version: 1.0 References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid> <20220719104725.ppic7jy4ghfieeap@artanis> In-Reply-To: From: Greg Sanders Date: Wed, 20 Jul 2022 17:50:53 -0400 Message-ID: To: Peter , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000fd142e05e44398de" Cc: Ali Sherief 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 21:51:06 -0000 --000000000000fd142e05e44398de Content-Type: text/plain; charset="UTF-8" Please see BIP322 https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Ali. > > > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My > proposal is simply going to standardize the practice of placing the segwit > address into the address field, and does not require alterations to the > message signing format like those BIPs. > > COLDCARD makes signatures exacly like that, when told to sign with a > segwit address: > > % ckcc msg -s Hello > Hello > bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5 > > HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc= > > 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 > makes it look possible. In effect segwit features never got implemented to > that depth in Core. It's sad because the community is not maintaining core > (Core?) features to the same depth as Satoshi did when he was active in the > project. > > > 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 > himself when the original client was written. It has never been codified in > a BIP 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 experience. > > So in summary... yes a "defacto" BIP is needed and useful to do, in my > opinion. 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 > managed to send this at the second try with the correct SMTP, From, To and > all, but maybe it was caught in GreyListing (protonmail).] > > > > I was thinking about creating a BIP to address the lack of > standardization for Segwit message signatures, but I want some advice > before proceeding. > > > > 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 > technically possible to sign and verify segwit addresses, since ECDSA only > depends on the public key (hence why you need a private key to sign > messages). > > > > However, because there is no generally-accepted standard for signing > segwit messages, the wallets that do support this feature simply insert the > segwit address into the address field. Verification also only works using > the procedure on that specific wallet software, if only because the > conventional tools for verifying messages attempt to reconstruct a legacy > address only. > > > > This BIP is not going to enforce anything, it's just going to set > guidelines for writing a message signing and verification procedure. > > > > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My > proposal is simply going to standardize the practice of placing the segwit > address into the address field, and does not require alterations to the > message signing format like those BIPs. > > > > In summary, in the verification part, the following address hashing > algorithms 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 > Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness > version by the bech32 encoding. > > > > 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 address in the signed message. > > > > In the signing procedure, the only modification is the insertion of the > segwit address in place of the legacy address in the signed message. > > > > If this BIP is approved, it does not require any changes to existing > signed messages, and the original sign/verify algorithms will continue to > interoperate with this improved sign/verify algorithm, without any action > necessary from the developers. > > > > So as you can see, this is the entire framework of the BIP I plan to > draft. There is no need for any auxilliary feature additions into this BIP. > I just want to hear the mailing list's advice about how I should draft such > a BIP. > > > > - Ali > > > > PS. I am pretty sure that there is a BIP for the original signing method > - what is its number? > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000fd142e05e44398de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 20, 2022, 5:46 PM Peter (Coinki= te Inc) via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Ali.

> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My = proposal is simply going to standardize the practice of placing the segwit = address into the address field, and does not require alterations to the mes= sage signing format like those BIPs.

COLDCARD makes signatures exacly like that, when told to sign with a segwit= address:

=C2=A0 =C2=A0 % ckcc msg -s Hello
=C2=A0 =C2=A0 Hello=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
=C2=A0 =C2=A0 HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYb= bmqSRXqI5mNTWH9qkDoqZTpnPc=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 cor= e (Core?) features to the same depth as Satoshi did when he was active in t= he project.

> PS. I am pretty sure that there is a BIP for the original signing meth= od - 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&= #39;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 experience.

So in summary... yes a "defacto" BIP is needed and useful to do, = in my opinion. Then Core should be updated to support it as well.

---
@DocHEX=C2=A0 ||=C2=A0 Coinkite=C2=A0 ||=C2=A0 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 man= aged to send this at the second try with the correct SMTP, From, To and all= , but maybe it was caught in GreyListing (protonmail).]
>
> I was thinking about creating a BIP to address the lack of standardiza= tion for Segwit message signatures, but I want some advice before proceedin= g.
>
> The current state of affairs is that the wallets that do support signi= ng and verifying a bitcoin message can only sign legacy addresses. It is te= chnically possible to sign and verify segwit addresses, since ECDSA only de= pends on the public key (hence why you need a private key to sign messages)= .
>
> However, because there is no generally-accepted standard for signing s= egwit messages, the wallets that do support this feature simply insert the = segwit address into the address field. Verification also only works using t= he procedure on that specific wallet software, if only because the conventi= onal tools for verifying messages attempt to reconstruct a legacy address o= nly.
>
> This BIP is not going to enforce anything, it's just going to set = guidelines for writing a message signing and verification procedure.
>
> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My = proposal is simply going to standardize the practice of placing the segwit = address into the address field, and does not require alterations to the mes= sage signing format like those BIPs.
>
> In summary, in the verification part, the following address hashing al= gorithms 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 seg= wit with version 0 as well as future native segwit address types such as Ta= proot) - where MAX_WITNESS_VERSION is the maximum supported witness version= by the bech32 encoding.
>
> The verification procedure stops if any of these hashes yield the corr= ect address, and fails if all of the above methods fail to reproduce the ad= dress in the signed message.
>
> In the signing procedure, the only modification is the insertion of th= e segwit address in place of the legacy address in the signed message.
>
> If this BIP is approved, it does not require any changes to existing s= igned messages, and the original sign/verify algorithms will continue to in= teroperate with this improved sign/verify algorithm, without any action nec= essary from the developers.
>
> So as you can see, this is the entire framework of the BIP I plan to d= raft. There is no need for any auxilliary feature additions into this BIP. = I just want to hear the mailing list's advice about how I should draft = such a BIP.
>
> - Ali
>
> PS. I am pretty sure that there is a BIP for the original signing meth= od - what is its number?
>


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000fd142e05e44398de--