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
144
145
146
147
148
149
150
151
152
153
154
|
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 DAF861025
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 03:01:28 +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 105FD224
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 03:01:27 +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 B3AAD14C0F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 12:01:26 +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; 15 Mar 2018 12:01:26 +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 AAC964C072
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 12:01:26 +0900 (JST)
(envelope-from karljohan-alm@garage.co.jp)
Received: from gw26.oz.hdemail.jp
(ip-10-185-1-211.ap-northeast-1.compute.internal [10.185.1.211])
by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id A575114C0F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 12:01:26 +0900 (JST)
(envelope-from karljohan-alm@garage.co.jp)
X-Received: from mail-qk0-f199.google.com (lb05.oz.hdemail.jp [54.238.57.175])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by gw26.oz.hdemail.jp (Postfix) with ESMTP id 35BBA148C12D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 12:01:26 +0900 (JST)
X-Received: by mail-qk0-f199.google.com with SMTP id u200so3512491qka.21
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Mar 2018 20:01:26 -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:content-transfer-encoding;
bh=CIUc28v/lvmhI2yXAva1xS2ZATFwISGD55Or8mfCU1o=;
b=lXIigM7SoqvNhW06tIwOfNHmwOE4qkHks3aLaicFD7JWWJcTvkgXBcQrs5V1eGOMo7
vaZNaLaYpwWoWn6kZp1GUrlQ9vu9ANkjNned8aAUVrOfw2qS6QI/nO4j2NapzKif9Rl/
cT8ZhN+WbypRn6CIX6xs0Y0Fotocyf6yz8gbY5mx0t3Es3lAk/Tu0SJ/7FagSxUVii8t
ANZEkQw+4TxnJQcZDQR0AJvyqbAdnLR77CRL/Cse098kUzwHRItoOkmYveIT8em5O53+
3rdSz0a+PkpjceMSbqJHTgIyGTdf+6UtlB6XMliZT9zXq6xx4bg94/QXEF7MdIwf+IG2
LUvQ==
X-Gm-Message-State: AElRT7GUqUEUYCLKfktMMdh1xZO5iTpQHGJ2NriqLGnokO0Jc+IP+md+
Ua3AXSuvafVtCHdcWyLpG+t64MZwHiXVIuibPAjjXTNSE/emKdJ90Ox3kv+BRFnhLpujq9zK/Hg
vhspj8v0kOju0UHYHPtpsliEZcQQ4ZjWlbmEzdSdm+Ha5w96/4Vn/MnpM30NRjJOHWPZyvO+JkN
HPMhnZ/VpKVKscm5mPhUp7K5IbpA1IPwDZ2VPysUu4jy8AxuFL+AV6S0bUerz5PSsGCO1z4uks+
aGRmnfRCve2SZBuJb8WjR/wRRcLq2zdPTBH+VrdgQlBcf1+uBSJAzJD3epop0G3KiBaBAojcHiZ
dY8SfAIGP+UMyfBmAW8A8MNVpNM=
X-Received: by 10.200.6.6 with SMTP id d6mr6628885qth.112.1521082884550;
Wed, 14 Mar 2018 20:01:24 -0700 (PDT)
X-Google-Smtp-Source: AG47ELvxvalg2ge55NcMM1l0G28vSbMNFvalwk2LeB6IPcJfbiidyIm4FZ//s7mQRDm3aIbrGCl+tuG8AGydXgcw8Ng=
X-Received: by 10.200.6.6 with SMTP id d6mr6628862qth.112.1521082884220; Wed,
14 Mar 2018 20:01:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.12.176.3 with HTTP; Wed, 14 Mar 2018 20:01:03 -0700 (PDT)
In-Reply-To: <CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
<CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
Date: Wed, 14 Mar 2018 23:01:03 -0400
Message-ID: <CALJw2w719qQnyvaJbe1wc39+4ERDST+zXCOjt0DiJpktD74QCA@mail.gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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-dev <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: Thu, 15 Mar 2018 03:01:29 -0000
On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote=
:
> I can't really see from your proposal if you had thought of this: A soft
> fork can make old nodes accept invalid message signatures as valid. For
> example, a "signer" can use a witness version unknown to the verifier to
> fool the verifier. Witness version is detectable (just reject unknown
> witness versions) but there may be more subtle changes. Segwit was not
> "detectable" in that way, for example.
>
> This is the reason why I withdrew BIP120. If you have thought about the
> above, I'd be very interested.
I'm not sure I see the problem. The scriptPubKey is derived directly
from the address in all cases, which means the unknown witness version
would have to be committed to in the address itself.
So yeah, I can make a P2SH address with a witness version > 0 and a to
me unknown pubkey and then fool you into thinking I own it, but I
don't really see why you'd ultimately care. In other words, if I can
SPEND funds sent to that address today, I can prove that I can spend
today, which is the purpose of the tool, I think.
For the case where the witness version HAS been upgraded, the above
still applies, but I'm not sure it's a big issue. And it doesn't
really require an old node. I just need to set witness version >
current witness version and the problem applies to all nodes.
On Wed, Mar 14, 2018 at 8:36 AM, Luke Dashjr <luke@dashjr.org> wrote:
> I don't see a need for a new RPC interface, just a new signature format.
All right.
> Ideally, it should support not only just "proof I receive at this address=
",
> but also "proof of funds" (as a separate feature) since this is a popular
> misuse of the current message signing (which doesn't actually prove funds=
at
> all). To do this, it needs to be capable of signing for multiple inputs.
I assume by inputs you mean addresses/keys. The address field could
optionally be an array. That'd be enough?
> Preferably, it should also avoid disclosing the public key for existing o=
r
> future UTXOs. But I don't think it's possible to avoid this without somet=
hing
> MAST-like first. Perhaps it can be a MAST upgrade later on, but the new
> signature scheme should probably be designed with it in mind.
I'd love to not have to reveal the public key, but I'm not sure how it
would be done, even with MAST.
On Wed, Mar 14, 2018 at 12:12 PM, Anthony Towns <aj@erisian.com.au> wrote:
> Wouldn't it be sufficient for old nodes to check for standardness of the =
spending script and report non-standard scripts as either invalid outright,=
or at least highly questionable? That should prevent confusion as long as =
soft forks are only making nonstandard behaviours invalid.
That seems sensible to me. A warning would probably be useful, in case
the verifier is running old software.
-Kalle.
|
