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
137
138
139
140
141
142
143
|
Return-Path: <karljohan-alm@garage.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3237316A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 08:10:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D33F575
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 08:10:10 +0000 (UTC)
Received: from ip-10-217-1-36.ap-northeast-1.compute.internal
(localhost.localdomain [127.0.0.1])
by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 3CC0314C0D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 17:10:09 +0900 (JST)
(envelope-from karljohan-alm@garage.co.jp)
X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1)
by 0 with SMTP; 27 Mar 2018 17:10:09 +0900
X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1])
by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 5484C4C079
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 17:10:06 +0900 (JST)
(envelope-from karljohan-alm@garage.co.jp)
Received: from gw24.oz.hdemail.jp
(ip-10-185-138-250.ap-northeast-1.compute.internal [10.185.138.250])
by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 72AF414C0B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 17:10:04 +0900 (JST)
(envelope-from karljohan-alm@garage.co.jp)
X-Received: from mail-qt0-f198.google.com (lb05.oz.hdemail.jp [54.238.57.175])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by gw24.oz.hdemail.jp (Postfix) with ESMTP id F2FF2148C10A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 17:10:03 +0900 (JST)
X-Received: by mail-qt0-f198.google.com with SMTP id m3so8279505qte.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Mar 2018 01:10:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=wTx8YqVZcScYPng4lHk8tuPWqiLojR3gsPd3tu/imgc=;
b=UaLClPccUf/AEyFzJJ9kUXHnj7hFoDCH1yu4it/Vz+OXI+AsZxG8W/itLTxMrTXwUf
8CG2taseKB+ygR+FRp17RF+InWlBthfI2pxFhxgmcQb97QIbEHFBZPbHccjL1ioP2KYd
Yty7ykkG2yKbmIzKNLzFQHfRsEdNcVIFP3e+zLXeCaMf2nF3+XCo2UAWNeRcwGy0P5oe
uBISpo51u4O9UghMUMsAIzMZ0poKrySrjJ8zvBNedR4H/vsnRPLBXXWwakhNgeJjLn9J
CBlui6eLuJ1wZqHuQmUaa1R7nWyOgvReJJFK/WK75uyO9jj4UCfWmOSA22mgl1jUVWEH
OHuQ==
X-Gm-Message-State: AElRT7G0usrt973u2e9yb/cMiYw1yU8ehpPFH2pGTTCysq7+ZMBPMuzI
dB1l+54iJE3bo/PgAnFkAN7zpUKtt8P/CciJr6TMncvoM45VxwZBxpEFRD95APvkb+8VJy0U2RW
3i4xin/n1gZOLzz1k3dwwo0xrlzYL3oyXT67K+0hBD1ZUA5VtjfhM2Jl6oyzJg6OzIoLtnLBEIz
59TK/aDiYb+pOcMWFOIYADn9o8qXETy7kiMZjyWSkR7T3VbcwBBHdA/RE33e2dX4w9ptwUiIjJP
siecvLOaoueEkkS+91L4/wzSycZMdbJO87Ska23DDhXWWmLrn50rjom4cw96CionLeLmS0fsCCP
mtxxG8N7iAjeRjP7y6wB4mJbQ8M=
X-Received: by 10.237.42.67 with SMTP id k3mr61638439qtf.24.1522138202578;
Tue, 27 Mar 2018 01:10:02 -0700 (PDT)
X-Google-Smtp-Source: AG47ELv5MzLt/sdEvS0GdDqfcVf1q920D/bnvXHb+PqMLncav7rwhrc8ozJBIGZ1WxNs1T0j/qo7UKNXPNtHUUNHXtQ=
X-Received: by 10.237.42.67 with SMTP id k3mr61638391qtf.24.1522138202212;
Tue, 27 Mar 2018 01:10:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.12.208.26 with HTTP; Tue, 27 Mar 2018 01:09:41 -0700 (PDT)
In-Reply-To: <CAPg+sBhAaw7uqdz6ZoMCkut2GM=3=F22FiHw6J_aLwTMEcqt1g@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
<CAPg+sBhAaw7uqdz6ZoMCkut2GM=3=F22FiHw6J_aLwTMEcqt1g@mail.gmail.com>
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
Date: Tue, 27 Mar 2018 17:09:41 +0900
Message-ID: <CALJw2w7UJ6JT9jpuV9c9OtOMrqNNGR0OJauwnMo7DJfWG=L_SQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 27 Mar 2018 08:10:11 -0000
Pieter,
Thanks for the feedback. Comments below:
On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> One solution is to include a version number in the signature, which
> explicitly corresponds to a set of validation flags. When the version number
> is something a verifier doesn't know, it can be reported as inconclusive
> (it's relying on features you don't know about).
>
> An solution is to verify twice; once with all consensus rules you know
> about, and once with standardness rules. If they're both valid, the
> signature is valid. If they're both invalid, the signature is invalid. If
> they're different (consensus valid but standardness invalid), you report the
> signature validation as inconclusive (it's relying on features you don't
> know about). This approach works as long as new features only use previous
> standardness-invalid scripts, but perhaps a version number is still needed
> to indicate the standardness flags.
I think the double verify approach seems promising. I assume old nodes
consider new consensus rule enforcing transactions as non-standard but
valid. If this is always the case, it may be an idea to simply fail
verification with a message indicating the node is unable to verify
due to unknown consensus rules.
>> RPC commands:
>>
>> sign <address> <message> [<prehashed>=false]
>
> Why not extend the existing signmessage/verifymessage RPC? For legacy
> addresses it can fall back to the existing signature algorithm, while using
> the script-based approach for all others.
Yes, I initially thought it would be better to not use it as the
legacy behavior could be depended on god knows where, but I think
adding a legacy mode or simply doing the old way for 1xx is
sufficient.
>> (**) If <prehashed> is true, <message> is the sighash, otherwise
>> sighash=sha256d(message).
>
>
> That's very dangerous I'm afraid. It could be used to trick someone into
> signing off on an actual transaction, if you get them to sign a "random
> looking" prehashed message. Even if you have a prehashed message, there is
> no problem with treating it as hex input to a second hashing step, so I
> think the prehashed option isn't needed. It's why the existing message
> signing functionality always forcibly prefixes "Bitcoin signed message:", to
> avoid signing something that unintentionally corresponds to a message
> intended for another goal.
Eek.. good point...
|
