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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4680BEBF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Mar 2018 02:00:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EAA85CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 16 Mar 2018 02:00:07 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id h21so331438wmd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Mar 2018 19:00:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=mJYlTLoq+scQ/fzkiXxgJDQTSrIPVNBMn6bstEH9r80=;
b=H69VhV32AK1+/KTW30zxmi29nJ5vbenpAXokXRNPM7H2yoPEiNC9OUJT05bG5BXA5a
I5bUrOGNdhah1dgh6FHHEiea4X1rH+XLdptLSQ1so6KpEtOqGbR71igVR+Gv8CD0GDqi
2Uns8L3E59+1agdmG9igX84FjApywa15OT8o70sj38a9PiRQxCvJQP1bAi5A87L7kBk2
zey8acCDcnDPSvQLgB9c1KYdTXxNadGebND1+Zn1Zc/+yfEI0z8wSD9Uh4FhJ3iGSbu2
4nCewLHApmiT9e/MU082u6EP2MY6YdUwMoBmSWZWuJ7ftaIQPGCnKfBXWcmxkrVpwI0X
ADDg==
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=mJYlTLoq+scQ/fzkiXxgJDQTSrIPVNBMn6bstEH9r80=;
b=XibL2bjApPRjiJPENNekOb95zYCJcA4qu27hmehIHKSQLaoZVtfadyvLfA5ognYwNV
10bCEOLlVnDmh1rFzPrdcTd/4gTvs20e0XA6VhaX35CRRMDTPkRKvbiQ8/Z+IwpudD7i
YuN2ss1jeOvz4keoEsreXTwYLB40uQNjYCjEs+UDPdrjcwnwep1PfMrIe0BofBRMwgNR
5bbPXRLm2/DZwvEscEXyosOk6UvXIapsAB0tQdLkHtWFiZ+FjpBo8yr8RW+quqjFvMJm
hUfmLOO0ZAAhEFmlS/5hpcfrFLtbJwu3q9zUvz5MPbIzZ/jaeGsk1KViIYlcXKr9EG/e
IH3Q==
X-Gm-Message-State: AElRT7HuLT87wpyzA5ehziQfBzOurVLUwR6r/8j0wcpu+tVziaUEm6cK
cRqoY4P1p57pKStf5zsFOGx8GQtwWCGcwH2MI3w=
X-Google-Smtp-Source: AG47ELu1SVC+EWRrJw2DtBHDAHNiX+1I6FArFsYW2D9pnb/FPxRrAAdtifTf6UKRCEOAfxJEktLwcELz9zL33mplZm0=
X-Received: by 10.80.165.143 with SMTP id a15mr468007edc.289.1521165606007;
Thu, 15 Mar 2018 19:00:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.175.228 with HTTP; Thu, 15 Mar 2018 18:59:45 -0700 (PDT)
In-Reply-To: <CALJw2w49bsBNFBj3MvdzNL+Hu3zuq-dmrTv_6wgmO_ZaCXt1nA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
<201803141236.48869.luke@dashjr.org>
<CALJw2w5NQ=WX1Cm4aUXMN=uxn8NLHAfYDLEtqUptce5DCWZXWA@mail.gmail.com>
<201803151414.06301.luke@dashjr.org>
<CALJw2w49bsBNFBj3MvdzNL+Hu3zuq-dmrTv_6wgmO_ZaCXt1nA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 15 Mar 2018 21:59:45 -0400
Message-ID: <CAB3F3Dv=xk68sx5c=9vKL9ynAVJoEY_hnbuZQ0tSe=7cBdWSVA@mail.gmail.com>
To: Karl Johan Alm <karljohan-alm@garage.co.jp>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c24d8973be205677df78f"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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: Fri, 16 Mar 2018 02:00:08 -0000
--f403045c24d8973be205677df78f
Content-Type: text/plain; charset="UTF-8"
Sorry if I missed the rationale earlier, but why not just do a transaction,
with a FORKID specifically for this? Then a node can have a mempool
acceptance test that returns true even if the signature is not valid as per
Bitcoin consensus, but only due to the FORKID?
This way basically any wallet can support this provided generic FORKID
support.
On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr <luke@dashjr.org> wrote:
> > Not necessarily specific UTXOs (that would contradict fungibility, as
> well as
> > be impossible for hot/cold wallet separation), but just to prove funds
> are
> > available. The current sign message cannot be used to prove present
> possession
> > of funds, only that you receive funds.
>
> By saying "not necessarily specific UTXOs", are you saying it may be
> spent outputs? I'm a little confused I think.
>
> On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen <jim.posen@gmail.com> wrote:
> > In this general signing-a-script context, I think a verifier might want
> to
> > see the time conditions under which it may be spent. The proof container
> > could include an optional nLockTime which defaults to 0 and nSequence
> which
> > defaults to 0xFFFF...
>
> Good point!
>
> >> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> >> Is there a good reason to tweak it?
> >
> > I took another look and there should definitely be a byte appended to the
> > end of the sig so that the encoding checks pass, but I think it might as
> > well be a 0x00 byte since it's not actually a sighash flag.
>
> I think the sighash flag affects the outcome of the actual
> verification, but I could be mistaken.
>
> -Kalle.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--f403045c24d8973be205677df78f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry if I missed the rationale earlier, but why not just =
do a transaction, with a FORKID specifically for this? Then a node can have=
a mempool acceptance test that returns true even if the signature is not v=
alid as per Bitcoin consensus, but only due to the FORKID?<div><br></div><d=
iv>This way basically any wallet can support this provided generic FORKID s=
upport.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On Thu, Mar 15, 2018 at 2:=
14 PM, Luke Dashjr <<a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</=
a>> wrote:<br>
> Not necessarily specific UTXOs (that would contradict fungibility, as =
well as<br>
> be impossible for hot/cold wallet separation), but just to prove funds=
are<br>
> available. The current sign message cannot be used to prove present po=
ssession<br>
> of funds, only that you receive funds.<br>
<br>
</span>By saying "not necessarily specific UTXOs", are you saying=
it may be<br>
spent outputs? I'm a little confused I think.<br>
<span class=3D""><br>
On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen <<a href=3D"mailto:jim.posen@=
gmail.com">jim.posen@gmail.com</a>> wrote:<br>
> In this general signing-a-script context, I think a verifier might wan=
t to<br>
> see the time conditions under which it may be spent. The proof contain=
er<br>
> could include an optional nLockTime which defaults to 0 and nSequence =
which<br>
> defaults to 0xFFFF...<br>
<br>
</span>Good point!<br>
<span class=3D""><br>
>> I think it would just use the default (SIGHASH_ALL?) for simplicit=
y.<br>
>> Is there a good reason to tweak it?<br>
><br>
> I took another look and there should definitely be a byte appended to =
the<br>
> end of the sig so that the encoding checks pass, but I think it might =
as<br>
> well be a 0x00 byte since it's not actually a sighash flag.<br>
<br>
</span>I think the sighash flag affects the outcome of the actual<br>
verification, but I could be mistaken.<br>
<br>
-Kalle.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--f403045c24d8973be205677df78f--
|
