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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
|
Return-Path: <jannes.faber@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AADA4273
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Nov 2015 00:38:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com
[209.85.215.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D528159
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Nov 2015 00:38:05 +0000 (UTC)
Received: by lfaz4 with SMTP id z4so42094745lfa.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 16:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=3LV8FzdfCTpPGEOOP4ub+G9HGRd12pgOYlajCFXAI64=;
b=ouYDOf53HKSKKh0/P3aXJAJ0YtxaHeNxCUb5s1H0691zQBPSL2M8jTXZYAHVmCG32w
XZmCJuN369hKXkmKYUD/oUoIY9iT9s8jmPow6ayyzRlbh67YN6QmH2oKloq3vV76oUPM
0ZrpciIcuqNuNguUeEgb2ZBAvqzT70OLAyfUzvz9tjH40UrYt6wY5RvdfWI2b7oRm7Mt
dmWcoHTR79N6terDE9/XbQqFh1FKZPbKE6CUbAIN/+PblTJ0yn6ASy9AMGWZRQ2IIFhY
ode8oZwjClnN+q5LGa05dovQjFxTdg9uka/qtldG1b1GzXvo+NW0mt/CKhV7AbLbJZB9
MwuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=3LV8FzdfCTpPGEOOP4ub+G9HGRd12pgOYlajCFXAI64=;
b=ZQhEGNDaeDT24r/r8NwQfQelWoLjw8T2NIo26u6DzRlu5FoQAX6KENs6kmErHie0ld
H21f3rV0W4ENE4mHT3q8iLm8tC+XAS04agt2pqZP1ThcFft/e/cWg4fQB+etf+HIb8qo
65UMVPU4Eg1txTbo94eeKQtSlIAMLogmDkcRf2+cqRoSLJzjK5XANtHvCdAovFbbBTj4
HOPqjakFdJt9qQbdiRI7QCVs5K39z3U/e8rkda0Vwle/YEOfWY8+uSMLSIL2x1MEjaLe
at24L9EwpfDEjOTDk9rZ1sSVyT6P7bEC5XCyEKekA6W7OrOlRYPagNvrPaBG2lugQWwj
9ECg==
X-Received: by 10.112.138.10 with SMTP id qm10mr11976978lbb.139.1448411883622;
Tue, 24 Nov 2015 16:38:03 -0800 (PST)
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com.
[209.85.215.48]) by smtp.gmail.com with ESMTPSA id
vz2sm2937219lbb.35.2015.11.24.16.38.02
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 24 Nov 2015 16:38:02 -0800 (PST)
Received: by lffu14 with SMTP id u14so42133794lff.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 16:38:02 -0800 (PST)
X-Gm-Message-State: ALoCoQkyVlVOzflrkIL25K0Hfl63JClzxf0ZLm7irFHE405EaNQtc5/vB7jD67af39Ti5ujFtcEJ
MIME-Version: 1.0
X-Received: by 10.112.119.133 with SMTP id ku5mr13954750lbb.1.1448411882359;
Tue, 24 Nov 2015 16:38:02 -0800 (PST)
Received: by 10.112.157.199 with HTTP; Tue, 24 Nov 2015 16:38:02 -0800 (PST)
Received: by 10.112.157.199 with HTTP; Tue, 24 Nov 2015 16:38:02 -0800 (PST)
In-Reply-To: <CAAcC9yubb-Ajig+ZLrGVe3a7ON5MTzuLARP1_HCj2ngStJAGGg@mail.gmail.com>
References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
<CABaSBaxKJjEd2e9hrnzyS57-YHspqCv9PiSH4XccqSZJMQG6qg@mail.gmail.com>
<CAGLBAhd-6NbxppFdqNVSQ5ot_GX12eL8P2-qVe7_dZcUfHYv6w@mail.gmail.com>
<CAAcC9yubb-Ajig+ZLrGVe3a7ON5MTzuLARP1_HCj2ngStJAGGg@mail.gmail.com>
Date: Wed, 25 Nov 2015 01:38:02 +0100
X-Gmail-Original-Message-ID: <CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com>
Message-ID: <CABeL=0hm=6S6YRQP45pNVv42b1kHZrH1TFuz3xguN+YNW5o=ww@mail.gmail.com>
From: Jannes Faber <jannes.faber@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7bb040cebcab60052552ab56
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 25 Nov 2015 00:41:45 +0000
Subject: Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or
"Coalescing Transactions"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 25 Nov 2015 00:38:06 -0000
--047d7bb040cebcab60052552ab56
Content-Type: text/plain; charset=UTF-8
Few issues I can think of:
1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.
2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
include a block height which indicates the maximum block that any utxo can
match. With the requirement that the specified block height is at least 100
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must be
in that minimum block).
3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > This idea could be applied by having the wildcard signature apply to all
> > UTXOs that are of a standard form and paid to a particular address, and
> be
> > a signature of some kind of message to that effect.
>
> I think this is true. Not *all* transactions will be able to match the
> wildcard. For instance if someone sent some crazy smart contract tx to
> your address, the script associated with that tx will be such that it
> will not apply to the wildcard. Most "vanilla" utxos that I've seen
> have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
> address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
> apply to the wildcard.
>
> On 11/24/15, Dave Scotese via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > What is required to spend bitcoin is that input be provided to the UTXO
> > script that causes it to return true. What Chris is proposing breaks the
> > programmatic nature of the requirement, replacing it with a requirement
> > that the secret be known. Granted, the secret is the only requirement in
> > most cases, but there is no built-in assumption that the script always
> > requires only that secret.
> >
> > This idea could be applied by having the wildcard signature apply to all
> > UTXOs that are of a standard form and paid to a particular address, and
> be
> > a signature of some kind of message to that effect. I imagine the cost
> of
> > re-scanning the UTXO set to find them all would justify a special extra
> > mining fee for any transaction that used this opcode.
> >
> > Please be blunt about any of my own misunderstandings that this email
> makes
> > clear.
> >
> > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >>> **OP_CHECKWILDCARDSIGVERIFY**
> >>
> >>
> >> Some (minor) discussion of this idea in -wizards earlier today starting
> >> near near "09:50" (apologies for having no anchor links):
> >> http://gnusha.org/bitcoin-wizards/2015-11-24.log
> >>
> >> - Bryan
> >> http://heybryan.org/
> >> 1 512 203 0507
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >
> >
> > --
> > I like to provide some work at no charge to prove my value. Do you need a
> > techie?
> > I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> > <http://www.memeracing.net> (in alpha).
> > I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which
> > now accepts Bitcoin.
> > I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> > "He ought to find it more profitable to play by the rules" - Satoshi
> > Nakamoto
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--047d7bb040cebcab60052552ab56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Few issues I can think of:</p>
<p dir=3D"ltr">1. In its basic form this encourages address reuse. Unless t=
he wildcard can be constructed such that it can match a whole branch of an =
HD=C2=A0 wallet. Although I guess that would tie all those addresses togeth=
er making HD moot to begin with.</p>
<p dir=3D"ltr">2. Sounds pretty dangerous during reorgs. Maybe such a trans=
action should include a block height which indicates the maximum block that=
any utxo can match. With the requirement that the specified block height i=
s at least 100 blocks in the past. Maybe add a minimum block height as well=
to prevent unnecessary scanning (with the requirement that at least one ut=
xo must be in that minimum block).</p>
<p dir=3D"ltr">3. Seems like a nice way to the reduce utxo set. But hard to=
say how effective it would really be.</p>
<div class=3D"gmail_quote">On 25 Nov 2015 12:48 a.m., "Chris Priest vi=
a bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attri=
bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">> This idea could be applied by h=
aving the wildcard signature apply to all<br>
> UTXOs that are of a standard form and paid to a particular address, an=
d be<br>
> a signature of some kind of message to that effect.<br>
<br>
I think this is true. Not *all* transactions will be able to match the<br>
wildcard. For instance if someone sent some crazy smart contract tx to<br>
your address, the script associated with that tx will be such that it<br>
will not apply to the wildcard. Most "vanilla" utxos that I'v=
e seen<br>
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your<br>
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could<br=
>
apply to the wildcard.<br>
<br>
On 11/24/15, Dave Scotese via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> What is required to spend bitcoin is that input be provided to the UTX=
O<br>
> script that causes it to return true.=C2=A0 What Chris is proposing br=
eaks the<br>
> programmatic nature of the requirement, replacing it with a requiremen=
t<br>
> that the secret be known.=C2=A0 Granted, the secret is the only requir=
ement in<br>
> most cases, but there is no built-in assumption that the script always=
<br>
> requires only that secret.<br>
><br>
> This idea could be applied by having the wildcard signature apply to a=
ll<br>
> UTXOs that are of a standard form and paid to a particular address, an=
d be<br>
> a signature of some kind of message to that effect.=C2=A0 I imagine th=
e cost of<br>
> re-scanning the UTXO set to find them all would justify a special extr=
a<br>
> mining fee for any transaction that used this opcode.<br>
><br>
> Please be blunt about any of my own misunderstandings that this email =
makes<br>
> clear.<br>
><br>
> On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>> wrote:<br>
><br>
>> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <=
;<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br>
>><br>
>>> **OP_CHECKWILDCARDSIGVERIFY**<br>
>><br>
>><br>
>> Some (minor) discussion of this idea in -wizards earlier today sta=
rting<br>
>> near near "09:50" (apologies for having no anchor links)=
:<br>
>> <a href=3D"http://gnusha.org/bitcoin-wizards/2015-11-24.log" rel=
=3D"noreferrer" target=3D"_blank">http://gnusha.org/bitcoin-wizards/2015-11=
-24.log</a><br>
>><br>
>> - Bryan<br>
>> <a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_bla=
nk">http://heybryan.org/</a><br>
>> 1 512 203 0507<br>
>><br>
>> _______________________________________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
>><br>
>><br>
><br>
><br>
> --<br>
> I like to provide some work at no charge to prove my value. Do you nee=
d a<br>
> techie?<br>
> I own Litmocracy <<a href=3D"http://www.litmocracy.com" rel=3D"nore=
ferrer" target=3D"_blank">http://www.litmocracy.com</a>> and Meme Racing=
<br>
> <<a href=3D"http://www.memeracing.net" rel=3D"noreferrer" target=3D=
"_blank">http://www.memeracing.net</a>> (in alpha).<br>
> I'm the webmaster for The Voluntaryist <<a href=3D"http://www.v=
oluntaryist.com" rel=3D"noreferrer" target=3D"_blank">http://www.voluntaryi=
st.com</a>> which<br>
> now accepts Bitcoin.<br>
> I also code for The Dollar Vigilante <<a href=3D"http://dollarvigil=
ante.com/" rel=3D"noreferrer" target=3D"_blank">http://dollarvigilante.com/=
</a>>.<br>
> "He ought to find it more profitable to play by the rules" -=
Satoshi<br>
> Nakamoto<br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--047d7bb040cebcab60052552ab56--
|
