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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1X7f4z-0002nr-PY
for bitcoin-development@lists.sourceforge.net;
Thu, 17 Jul 2014 06:22:09 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.212.172 as permitted sender)
client-ip=209.85.212.172; envelope-from=jgarzik@bitpay.com;
helo=mail-wi0-f172.google.com;
Received: from mail-wi0-f172.google.com ([209.85.212.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X7f4y-0000LO-DS
for bitcoin-development@lists.sourceforge.net;
Thu, 17 Jul 2014 06:22:09 +0000
Received: by mail-wi0-f172.google.com with SMTP id n3so7304894wiv.11
for <bitcoin-development@lists.sourceforge.net>;
Wed, 16 Jul 2014 23:22:02 -0700 (PDT)
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:from:date
:message-id:subject:to:cc:content-type;
bh=sYUCsA6OB3XW54mS7loGhzO26/WcW+9NmmpZXty4jgA=;
b=RiwxODdSrXwy5iU7LdfWQ09DBKiC7HT3XhS0w7VnvMdyK0FYlYK+FizHt3pG2Y+WJF
ucPyJJv0Nud21bgWiey9hZiu3+ibDaczwU9L288HODWHCPfpGB0U9/YwfbTop140Bxpm
iRZpdNxYyTkqqqgIn4k2pY423Iud6CGne9/wBp+u8IGgBOh877jlpdmxGrtTcT2Vxha0
J/WaAof5TRhIe3xvc294OQXB80mSVomtFxwUOcaCQSiFN9NhIEwEiaYOdaQLi4i5dceK
eJ/Nsz3Zuwl0ISRu6efCrSBmKuSA4ufRJIbiqyAO1RP0SMibGxT6OshQr3wArn+2vMRP
tTRQ==
X-Gm-Message-State: ALoCoQkJT5xQaV4sSRERpOICEKSNMaAUjkhaqDSTEJw34LVR7tv+Bf2J9m8yat6XSLQPkGpYsLtz
X-Received: by 10.181.11.232 with SMTP id el8mr19691957wid.57.1405578122136;
Wed, 16 Jul 2014 23:22:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.5.67 with HTTP; Wed, 16 Jul 2014 23:21:42 -0700 (PDT)
In-Reply-To: <CAD5xwhhwMyL20nAUXz-Vv6m5ucH7UQcGQLyrFadAvqy4QXkbZw@mail.gmail.com>
References: <CAD5xwhgyCOdJwnXw+YchptfXjtshDi_VVEGOjR-hG2qV=u6m2g@mail.gmail.com>
<CAJHLa0OFEDQp5umz=6_LUx5oJJmiKJoF90W7nvJPv0CtML+ftA@mail.gmail.com>
<CAD5xwhhwMyL20nAUXz-Vv6m5ucH7UQcGQLyrFadAvqy4QXkbZw@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 17 Jul 2014 02:21:42 -0400
Message-ID: <CAJHLa0OeetO3P6eBHOwN8SUN3ZpN07yWJ0vsGxupZLgcD1MEVQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1X7f4y-0000LO-DS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Pay to MultiScript hash:
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 17 Jul 2014 06:22:10 -0000
In a system like bitcoin, where the system has to keep running, you
have to consider how to roll out upgrades, and the costs associated
with that.
* the general cost of any network-wide change, versus P2SH which is
already analyzed by devs, rolled out and working
* the cost of P2SH output is predictable, versus less predictable outputs
* the cost of updating everybody to relay this new transaction type,
whereas P2SH Just Works already
* cost of increasing rate of UTXO growth versus P2SH
* "default public", versus P2SH's "default private"
It is true that publishing the script in the txout has the advantage
of being easily audited by third parties scanning the blockchain, but
in the interest of space efficiency you may accomplish the same thing
by offering the script upon request out-of-band. The script is
hash-sealed by the P2SH address, enabling perfect proof.
Don't have a transcript handy, but these things are usually logged and
google-searchable.
In any case, it would be nice to get together and start building a
"cookbook" of useful scripts like the ones you've been describing.
The power of bitcoin scripts is only beginning to be explored. Use
cases and examples are very helpful.
On Thu, Jul 17, 2014 at 1:59 AM, Jeremy <jlrubin@mit.edu> wrote:
> Additional costs would be in terms of A) chance of user error/application
> error -- proposed method is much simpler, as well as extra bytes for control
> flow ( 4 per script if I am counting right).
>
>
> The costs on a normal script do seem slightly more friendly, except this
> method allows for hidden-till-spent permission groups, as well as as smaller
> blockchain bloat overall (if scriptSig script has to store the logic for all
> the potential permission group, it will be a larger script versus only
> needing one permission group's script). An added benefit could also be in
> blockchain analysis -- you can actively monitor the utxo pool for your known
> associated scripts, whereas you couldn't for specialty scripts assembled per
> group. Enables repeated spends with groups as a "cost object" w/o having to
> recall all participants. ie, pay to the same perm groups as the other
> employee did last time, but include me as a root this time.
>
>
> Do you have a transcript of that chat by any chance? An interesting way to
> do that would be to push the sigs onto the stack & have implicit orders,
> then do expressions with their aliases, and then be able to assign "spending
> groups".
> ex:
> code_sep
> push script0
> push script1
> push script2
> push script3
> group_sep
> mkgroup_2, 0,1 ; the id will be 4
> mkgroup_3, 0,2,3 ; the id will be 5
> mkUnionGroup_2, 4,5 ; the id will be 6
> 2_of_3_group 0, 1, 2
> mkIntersectionGroup_2 5, 6
> complement_last ; complements last group, mutation
> del_group 1 ; deletes the group #1, groups then reindex after
> deletion (maybe the group was useful base class).
> etc...
> multisig check perm groups (checks if any groups on stack are valid from
> script)
>
>
> or even something like adding a little SAT scripting language with an eval.
>
> push script0
> push script1
> push script2
> push script3
> push <a=(1 & 2 & 0), b=a-1, a | 3 | b >
> eval
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>>
>> On Wed, Jul 16, 2014 at 1:56 PM, Jeremy <jlrubin@mit.edu> wrote:
>> > Right now, this could be expressed multiple ways (ie, using an op_dup if
>> > then else chain) , but all would incur additional costs in terms of
>> > complicated control flows. Instead, I would propose:
>>
>> Can you quantify "additional costs in terms of complicated control flows"?
>>
>>
>> > There is an implication in terms of increased utxo pool bloat, but also
>> > an
>> > implication in terms of increased txn complexity (each 20 byte hash
>> > allows
>> > for a 500 byte script, only one of the 500 byte scripts has to be
>> > permanently stored on blockchain).
>>
>> When considering these costs, using a normal P2SH output + a script
>> with OP_IF and friends seems more straightforward?
>>
>> Doing boolean logic with multisig groups is quite possible, e.g.
>> "group AND group", "group OR (group AND group)" etc. Definitely a
>> valid use case. I discussed how to do this on IRC with gmaxwell
>> several months ago. I call it "multi-multisig" for lack of a better
>> name.
>
>
>
>
> --
> Jeremy Rubin
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
