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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BE7CF9D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 20:32:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com
[209.85.215.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B1FCB87
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 20:32:39 +0000 (UTC)
Received: by lfs39 with SMTP id 39so34365312lfs.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 12:32:37 -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
:cc:content-type;
bh=5Yf4BaiZl5BXxoKK9GB6beJoecjxMo3dSdDiEBo3RIc=;
b=x+yo97u4L+UUh3WJKROoY05F7BraTjb68xYMTPRjF1VzsjhgsOhmuRjBVZ346HKJ+b
CNY2Ki/RaavLcDPXbyoHWzLCZ+b3qf7TTZRLfzfzh8lw0IHyoRRc7UwDFVtV8hzxPzKV
YQh15LAkXF6PECgz+gFTFULVym1eFXQGa52cJOSQV9HQY5eE8BZL9OUKtuOeiQfyG7Ql
P5cpftxLLjyGd5prQRmQ7ArXnOsS0f6Os1j73QKoeWaqIM+LMx7UNGVLz4yaJCT4fAeO
eUKAmIErwK5eMNLHlGFvSyEC9/6yI7/BEfZYhGqdG6LyD2eUdCBwL4tK2IQ38Zaw6R+8
y+rA==
MIME-Version: 1.0
X-Received: by 10.112.172.138 with SMTP id bc10mr13581806lbc.74.1448397157398;
Tue, 24 Nov 2015 12:32:37 -0800 (PST)
Received: by 10.25.22.95 with HTTP; Tue, 24 Nov 2015 12:32:37 -0800 (PST)
In-Reply-To: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
References: <CAAcC9yuM+dG+mJn_0vPqZuig5cHqeF-xgszw-zzD3D9UKRsyrQ@mail.gmail.com>
Date: Tue, 24 Nov 2015 15:32:37 -0500
Message-ID: <CABsx9T0A8EczcsE8f3D4WGk-0xsPadupBVgH5_kTs=GEhOq_9g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Chris Priest <cp368202@ohiou.edu>
Content-Type: multipart/alternative; boundary=001a11c267140f7f0c05254f3e3c
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 24 Nov 2015 20:32:40 -0000
--001a11c267140f7f0c05254f3e3c
Content-Type: text/plain; charset=UTF-8
On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The technical reason for this is that you have to explicitly list each
> UTXO individually when making bitcoin transactions. There is no way to
> say "all the utxos". This post describes a way to achieve this. I'm
> not yet a bitcoin master, so there are parts of this proposal that I
> have not yet figured out entirely, but I'm sure other people who know
> more could help out.
>
So every input has:
32-byte hash (transaction being spent)
4-byte output (output being spent)
4-byte sequence number
... plus the scriptSig. Which is as small as about 73 bytes if you're
spending a raw OP_CHECKSIG (which you can't do as a bitcoin address, but
could via the BIP70 payment protocol), and which is at least two serialized
bytes.
Best case for any scheme to coalesce scriptSigs would to somehow make
all-but-the-first scriptSig zero-length, so the inputs would be 42 bytes
instead of 40+73 bytes -- the coalesce transaction would be about one-third
the size, so instead of paying (say) $1 in transaction fees you'd pay 37
cents.
That's in the gray are of the "worth doing" threshold-- if it was a 10x
improvement (pay 10 cents instead of $1) it'd be in my personal "definitely
worth the trouble of doing" category.
RE: the scheme: an OP_RINGSIGVERIFY is probably the right way to do this:
https://en.wikipedia.org/wiki/Ring_signature
The funding transactions would be: <public key> OP_RINGSIGVERIFY
... which might could be redeemed with <ring signature> for one input and
then... uhh... maybe just <index_to_input_with_signature> for the other
inputs that are part of the same ring signature group (OP_0 if the first
input has the signature that is good for all the other public keys, which
would be the common case).
--
--
Gavin Andresen
--001a11c267140f7f0c05254f3e3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div id=3D":846" class=3D"" style=3D"overflow:hidden">The techni=
cal reason for this is that you have to explicitly list each<br>
UTXO individually when making bitcoin transactions. There is no way to<br>
say "all the utxos". This post describes a way to achieve this. I=
'm<br>
not yet a bitcoin master, so there are parts of this proposal that I<br>
have not yet figured out entirely, but I'm sure other people who know<b=
r>
more could help out.<br></div></blockquote></div><br>So every input has:</d=
iv><div class=3D"gmail_extra">=C2=A032-byte hash (transaction being spent)<=
/div><div class=3D"gmail_extra">=C2=A04-byte output (output being spent)<br=
>=C2=A04-byte sequence number</div><div class=3D"gmail_extra">... plus the =
scriptSig. Which is as small as about 73 bytes if you're spending a raw=
OP_CHECKSIG (which you can't do as a bitcoin address, but could via th=
e BIP70 payment protocol), and which is at least two serialized bytes.<br c=
lear=3D"all"><div><br></div><div>Best case for any scheme to coalesce scrip=
tSigs would to somehow make all-but-the-first scriptSig zero-length, so the=
inputs would be 42 bytes instead of 40+73 bytes -- the coalesce transactio=
n would be about one-third the size, so instead of paying (say) $1 in trans=
action fees you'd pay 37 cents.</div><div><br></div><div>That's in =
the gray are of the "worth doing" threshold-- if it was a 10x imp=
rovement (pay 10 cents instead of $1) it'd be in my personal "defi=
nitely worth the trouble of doing" category.</div><div><br></div><div>=
RE: the scheme: =C2=A0an OP_RINGSIGVERIFY is probably the right way to do t=
his:</div><div>=C2=A0=C2=A0<a href=3D"https://en.wikipedia.org/wiki/Ring_si=
gnature">https://en.wikipedia.org/wiki/Ring_signature</a></div><div><br></d=
iv><div>The funding transactions would be: =C2=A0<public key> OP_RING=
SIGVERIFY</div><div>... which might could be redeemed with <ring signatu=
re> for one input and then... uhh... maybe just <index_to_input_with_=
signature> for the other inputs that are part of the same ring signature=
group (OP_0 if the first input has the signature that is good for all the =
other public keys, which would be the common case).</div><div><br></div>-- =
<br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a11c267140f7f0c05254f3e3c--
|
