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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1WdmKe-0000gv-Vb
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 20:02:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.46 as permitted sender)
client-ip=209.85.216.46; envelope-from=tier.nolan@gmail.com;
helo=mail-qa0-f46.google.com;
Received: from mail-qa0-f46.google.com ([209.85.216.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdmKd-0004Hj-1p
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 20:02:48 +0000
Received: by mail-qa0-f46.google.com with SMTP id i13so3968831qae.5
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 Apr 2014 13:02:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.112.5 with SMTP id u5mr14703387qcp.3.1398456161456; Fri,
25 Apr 2014 13:02:41 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Fri, 25 Apr 2014 13:02:41 -0700 (PDT)
In-Reply-To: <201404251917.49826.luke@dashjr.org>
References: <CAE-z3OXe4fG2S274qcgpGsXA=ZhhJQneEDqLYvNWZT8U9y_NLA@mail.gmail.com>
<201404251917.49826.luke@dashjr.org>
Date: Fri, 25 Apr 2014 21:02:41 +0100
Message-ID: <CAE-z3OX5_POg9kFoz-LsGhuLRA6qFPcNXoECLhewe+o-+Pw2gA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11330a74bcdb5304f7e37226
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WdmKd-0004Hj-1p
Subject: Re: [Bitcoin-development] BIP - Selector Script
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: Fri, 25 Apr 2014 20:02:49 -0000
--001a11330a74bcdb5304f7e37226
Content-Type: text/plain; charset=UTF-8
On Fri, Apr 25, 2014 at 8:17 PM, Luke-Jr <luke@dashjr.org> wrote:
> I believe you meant to link here instead?
> https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
>
> Yeah, sorry.
> This looks reasonable from a brief skim over, but does not define any use
> cases (it mentions "necessary for atomic cross chain transfers", but does
> not
> explain how it is useful for that - perhaps that belongs in another BIP you
> haven't written yet, though).
One use case should be enough. The atomic cross chain proposal has been
discussed for a while. It feels like bitcoin works on an "ask permission
first" basis.
It always stalls at the fact that non-standard transactions are hard to get
confirmed on other coins. It is hard to find pools on other coins which
have weaker isStandard() checks. The timeouts have to be set so that they
are long enough to guarantee that transactions are accepted before they
expire.
A testnet to testnet transfer is the best that would be possible at the
moment.
I don't think the cross chain system needs a BIP (except to justify this
one).
If cross chain transfer become popular, then it would be useful to ensure
that clients are interoperable, but first things first. If the
transactions aren't accepted in any chains, then everything stalls.
Secure transfers require that the malleability issue is fixed, but that is
a separate issue. I am assuming that will be fixed at some point in the
future, since micro-payment channels also requires that it is fixed.
> IMO, it should also require P2SH.
>
It could be restricted to only P2SH, I don't think there would be a loss in
doing that.
Personally, I would make it so that P2SH is mandatory after a certain
time. It makes distributed verification of the block chain easier.
Everything needed to verify a script is present in the transaction (except
that the output actually exists).
A soft fork that expands P2SH functionality would be even better, but I
would rather not let the best be the enemy of the good.
>
>
> Luke
>
>
> On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote:
> > This is a BIP to allow the spender to choose one of multiple standard
> > scripts to use for spending the output.
> >
> > https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
> >
> > This is required as part of the atomic cross chain transfer protocol. It
> > is required so that outputs can be retrieved, if the process ends before
> > being committed.
> >
> > https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
> >
> > The script allows multiple standard scripts to be included in the
> > scriptPubKey.
> >
> > When redeeming the script the spender indicates which of the standard
> > scripts to use.
> >
> > Only one standard script is actually executed, so the only cost is the
> > extra storage required.
> >
> > A more ambitious change would be a soft fork like P2SH, except the
> spender
> > is allowed to select from multiple hashes. Effectively, it would be
> > "Multi-P2SH".
> >
> > This gets much of the benefits of MAST, but it requires a formal soft
> fork
> > to implement.
> >
> > If there is agreement, I can code up the reference implementation as a
> PR.
> > The multi-P2SH might actually be easier.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11330a74bcdb5304f7e37226
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 F=
ri, Apr 25, 2014 at 8:17 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailt=
o:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
I believe you meant to link here instead?<br>
=C2=A0 =C2=A0 <a href=3D"https://github.com/TierNolan/bips/blob/bip4x/bip-0=
046.mediawiki" target=3D"_blank">https://github.com/TierNolan/bips/blob/bip=
4x/bip-0046.mediawiki</a><br>
<br></blockquote><div>Yeah, sorry.<br>=C2=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
This looks reasonable from a brief skim over, but does not define any use<b=
r>
cases (it mentions "necessary for atomic cross chain transfers", =
but does not<br>
explain how it is useful for that - perhaps that belongs in another BIP you=
<br>
haven't written yet, though). </blockquote><div><br></div><div>One use =
case should be enough.=C2=A0 The atomic cross chain proposal has been discu=
ssed for a while.=C2=A0 It feels like bitcoin works on an "ask permiss=
ion first" basis.=C2=A0 <br>
<br></div><div>It always stalls at the fact that non-standard transactions =
are hard to get confirmed on other coins.=C2=A0 It is hard to find pools on=
other coins which have weaker isStandard() checks.=C2=A0 The timeouts have=
to be set so that they are long enough to guarantee that transactions are =
accepted before they expire.<br>
<br>A testnet to testnet transfer is the best that would be possible at the=
moment.<br></div><div><br></div><div>I don't think the cross chain sys=
tem needs a BIP (except to justify this one).=C2=A0 <br><br></div><div>If c=
ross chain transfer become popular, then it would be useful to ensure that =
clients are interoperable, but first things first.=C2=A0 If the transaction=
s aren't accepted in any chains, then everything stalls.<br>
<br> Secure transfers require that the malleability issue is fixed, but tha=
t is a separate issue.=C2=A0 I am assuming that will be fixed at some point=
in the future, since micro-payment channels also requires that it is fixed=
.<br>
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">IM=
O, it should also require P2SH.<br></blockquote><div><br></div><div>It coul=
d be restricted to only P2SH, I don't think there would be a loss in do=
ing that.<br>
<br></div><div>Personally, I would make it so that P2SH is mandatory after =
a certain time.=C2=A0 It makes distributed verification of the block chain =
easier.=C2=A0 Everything needed to verify a script is present in the transa=
ction (except that the output actually exists).<br>
</div><div><br></div><div>A soft fork that expands P2SH functionality would=
be even better, but I would rather not let the best be the enemy of the go=
od. <br></div>=C2=A0<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Luke<br>
<div><div class=3D"h5"><br>
<br>
On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote:<br>
> This is a BIP to allow the spender to choose one of multiple standard<=
br>
> scripts to use for spending the output.<br>
><br>
> <a href=3D"https://github.com/TierNolan/bips/blob/bip4x/bip-0045.media=
wiki" target=3D"_blank">https://github.com/TierNolan/bips/blob/bip4x/bip-00=
45.mediawiki</a><br>
><br>
> This is required as part of the atomic cross chain transfer protocol. =
=C2=A0It<br>
> is required so that outputs can be retrieved, if the process ends befo=
re<br>
> being committed.<br>
><br>
> <a href=3D"https://bitcointalk.org/index.php?topic=3D193281.msg2224949=
#msg2224949" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D19=
3281.msg2224949#msg2224949</a><br>
><br>
> The script allows multiple standard scripts to be included in the<br>
> scriptPubKey.<br>
><br>
> When redeeming the script the spender indicates which of the standard<=
br>
> scripts to use.<br>
><br>
> Only one standard script is actually executed, so the only cost is the=
<br>
> extra storage required.<br>
><br>
> A more ambitious change would be a soft fork like P2SH, except the spe=
nder<br>
> is allowed to select from multiple hashes. =C2=A0Effectively, it would=
be<br>
> "Multi-P2SH".<br>
><br>
> This gets much of the benefits of MAST, but it requires a formal soft =
fork<br>
> to implement.<br>
><br>
> If there is agreement, I can code up the reference implementation as a=
PR.<br>
> The multi-P2SH might actually be easier.<br>
<br>
</div></div>---------------------------------------------------------------=
---------------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>
--001a11330a74bcdb5304f7e37226--
|
