1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5B4D0C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 04:16:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 3541041295
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 04:16:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3541041295
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=MXAiPdXs
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-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 m7AN_Wkgzenz
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 04:16:33 +0000 (UTC)
X-Greylist: delayed 00:06:03 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6F4A441296
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
[185.70.41.103])
by smtp4.osuosl.org (Postfix) with ESMTPS id 6F4A441296
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 04:16:32 +0000 (UTC)
Date: Wed, 20 Jul 2022 04:10:09 +0000
Authentication-Results: mail-41103.protonmail.ch;
dkim=pass (2048-bit key) header.d=notatether.com header.i=@notatether.com
header.b="MXAiPdXs"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
s=protonmail; t=1658290214; x=1658549414;
bh=0EL9Dc18+uk0pN3VWyzgeJ4Rje2Mti2N4pjWIJpHnL4=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=MXAiPdXsIOvq9ll88fXZOiTYYQ1ftnS+rkAkXd3LdyCcQJmkaRo7ZvHARw/uSm8Kn
ptF+6WX+WvJ21jVyV8ha92CE7qxyQ4BjbeM4jb5g4XGZhdPPnYMXU92EQilRMiqGzg
2hj+GO7QkmedGUyFqcRNd/WqK8TL8dNeuONAT1Ah+K5vGFz950VV8zBgM9ulMhrnCr
/QsAvBb+5feKbOASLpLNdcQteoQ1QVwndbzltkGKtaGLQQWn6S5Sjk8Zy9XD1ThStL
b6tNNizH61AHXX8LJ2ma6dvhC7qsMWaHUtwPPnzujcgwkXeQ6bS/tPX7lxEOMXMdjd
dn3ZiqQ2Vdhvg==
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com>
In-Reply-To: <20220719104725.ppic7jy4ghfieeap@artanis>
References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid>
<mailman.84940.1658205911.8511.bitcoin-dev@lists.linuxfoundation.org>
<20220719104725.ppic7jy4ghfieeap@artanis>
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: Wed, 20 Jul 2022 10:17:37 +0000
Subject: [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 04:16:35 -0000
[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 an=
d verifying a bitcoin message can only sign legacy addresses. It is technic=
ally 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 segwi=
t address into the address field. Verification also only works using the pr=
ocedure 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 guideline=
s for writing a message signing and verification procedure.
This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My propo=
sal is simply going to standardize the practice of placing the segwit addre=
ss 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 algorit=
hms will be tried in sequence in an attempt to reconstruct the address in t=
he signed message:
- P2PKH (legacy address)
- P2WPKH-P2SH (nested segwit)
- P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit w=
ith version 0 as well as future native segwit address types such as Taproot=
) - where MAX_WITNESS_VERSION is the maximum supported witness version by t=
he bech32 encoding.
The verification procedure stops if any of these hashes yield the correct a=
ddress, 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 seg=
wit 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 interop=
erate with this improved sign/verify algorithm, without any action necessar=
y 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 jus=
t want to hear the mailing list's advice about how I should draft such a BI=
P.
- Ali
PS. I am pretty sure that there is a BIP for the original signing method - =
what is its number?
|
