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
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AACD99F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2017 01:46:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com
[209.85.192.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A1331CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2017 01:46:57 +0000 (UTC)
Received: by mail-pf0-f175.google.com with SMTP id e64so713444pfk.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Oct 2017 18:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=yzqKd7hL0IX/WuEbt8IDCnK/jzqm5Xn1+BJrnwAAnk0=;
b=rR71lkITB+GubnTMLm6NjGbUI5rrOLKMMxw6IhkxWwAtNk1U+DWKrgQCwTBVZ0u2vY
22L7wB7KFJcBYl0ThgVy2IN1AzH1cSPKk3o7NAFeXNIrQhZHQILJOyDBfo+bHfklcPQZ
bJSM5AQdiGV9ioBQ8mGofzVhUQYPRtSXl6jHzzkxBcViFT7vs4eGN0b20sNYimfD+zOe
rbxbkdc4fN8/nABQ72ENV+fSgAgJmOI4KOfa/G8L5LmGTawL+qW/wVIyTJl/oG/1adzu
YkqNkZvNf+KFh4OAYZGoJTOwf1izE7ortAGKrsVOm0Wssr9DcxZrwd0JqHEjITlIvY+3
JAzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=yzqKd7hL0IX/WuEbt8IDCnK/jzqm5Xn1+BJrnwAAnk0=;
b=NjZE7zH+zq8fYLRP9QOb0skYxiiWU/u9eMC9ph+EUhYaETeQ+QVZfIEgqASJg90DAP
o5uBAkXDEVIWxHCuOZTysytTHsf+Q7ImtXE70ExLdr42/hiRNI8GXKsJaJxrD/IEdjjx
s/rTz4yYVL3o7j7rGOKiihUN00BOhpFBqFjJ79m/9Hd1zKcs6bFlQ3Y/Jjv3+xd1cYrZ
r9O9CJ8pzYyAtloHdRwF1q4g6RkLzwQJbBiuSJ/H+vdYK+CqtL+8fnthxAZ6bcMgTLyq
EEdq41djSxDW/gT5v1PLI0q92kP3QFEJbXyjMBIM+/WRARyJ4WwmU+mR/XEiNr6t2cF9
tafw==
X-Gm-Message-State: AMCzsaVAcjy2jnvmteUw//gQiUZq8+pfxFMwiNHZckN/7V1wAfrkfYlD
w+XESg5RDabFB9YiSyZae9Z874EFBqM=
X-Google-Smtp-Source: ABhQp+SWPfnzec0tAAn3mZcgHwv58YRMDD6ivL8TDaBID70gkvSiPipDprJ6X/Gdo+L4R2ADCbPATQ==
X-Received: by 10.98.64.75 with SMTP id n72mr4307123pfa.317.1509500817064;
Tue, 31 Oct 2017 18:46:57 -0700 (PDT)
Received: from ?IPv6:2601:647:4600:9c66:6d98:5b00:7f2d:b007?
([2601:647:4600:9c66:6d98:5b00:7f2d:b007])
by smtp.gmail.com with ESMTPSA id
n72sm4580728pfg.109.2017.10.31.18.46.55
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 31 Oct 2017 18:46:56 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-153FE09F-10A7-4DDA-8DA3-C203951615D5
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <CAMZUoKmNEaTEoHV6cWOdLR=G9XiqTQ9AmHhyxegVEEmXVhU+7w@mail.gmail.com>
Date: Tue, 31 Oct 2017 18:46:54 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <5E7A6643-C478-44EC-BC54-404D86D1D151@friedenbach.org>
References: <CAMZUoK=VNRMda8oRCtxniE6-vLwG-b=je2Hx+sD9sCzS--v9kQ@mail.gmail.com>
<E63C347E-5321-4F7F-B69C-75747E88AC06@mattcorallo.com>
<CAMZUoKmos5BMkFNsmNnTJhryfho_0fGhSKDQ82D6SPjPBhvd0A@mail.gmail.com>
<CAOG=w-vsTCTNW9x5TCHChN6_13pAabWjDQ30Eoo4xQduJ01fdQ@mail.gmail.com>
<CAMZUoKmNEaTEoHV6cWOdLR=G9XiqTQ9AmHhyxegVEEmXVhU+7w@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Simplicity: An alternative to Script
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: Wed, 01 Nov 2017 01:46:59 -0000
--Apple-Mail-153FE09F-10A7-4DDA-8DA3-C203951615D5
Content-Type: text/plain;
charset=gb2312
Content-Transfer-Encoding: quoted-printable
I don=A1=AFt think you need to set an order of operations, just treat the je=
t as TRUE, but don=A1=AFt stop validation. Order of operations doesn=A1=AFt m=
atter. Either way it=A1=AFll execute both branches and terminate of the unde=
rstood conditions don=A1=AFt hold.
But maybe I=A1=AFm missing something here.=20
> On Oct 31, 2017, at 2:01 PM, Russell O'Connor <roconnor@blockstream.io> wr=
ote:
>=20
> That approach is worth considering. However there is a wrinkle that Simpl=
icity's denotational semantics doesn't imply an order of operations. For ex=
ample, if one half of a pair contains a assertion failure (fail-closed), and=
the other half contains a unknown jet (fail-open), then does the program su=
cceed or fail?
>=20
> This could be solved by providing an order of operations; however I fear t=
hat will complicate formal reasoning about Simplicity expressions. Formal r=
easoning is hard enough as is and I hesitate to complicate the semantics in w=
ays that make formal reasoning harder still.
>=20
>=20
> On Oct 31, 2017 15:47, "Mark Friedenbach" <mark@friedenbach.org> wrote:
> Nit, but if you go down that specific path I would suggest making just
> the jet itself fail-open. That way you are not so limited in requiring
> validation of the full contract -- one party can verify simply that
> whatever condition they care about holds on reaching that part of the
> contract. E.g. maybe their signature is needed at the top level, and
> then they don't care what further restrictions are placed.
>=20
> On Tue, Oct 31, 2017 at 1:38 PM, Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > (sorry, I forgot to reply-all earlier)
> >
> > The very short answer to this question is that I plan on using Luke's
> > fail-success-on-unknown-operation in Simplicity. This is something that=
> > isn't detailed at all in the paper.
> >
> > The plan is that discounted jets will be explicitly labeled as jets in t=
he
> > commitment. If you can provide a Merkle path from the root to a node th=
at
> > is an explicit jet, but that jet isn't among the finite number of known
> > discounted jets, then the script is automatically successful (making it
> > anyone-can-spend). When new jets are wanted they can be soft-forked int=
o
> > the protocol (for example if we get a suitable quantum-resistant digital=
> > signature scheme) and the list of known discounted jets grows. Old node=
s
> > get a merkle path to the new jet, which they view as an unknown jet, and=
> > allow the transaction as a anyone-can-spend transaction. New nodes see a=
> > regular Simplicity redemption. (I haven't worked out the details of how=
the
> > P2P protocol will negotiate with old nodes, but I don't forsee any
> > problems.)
> >
> > Note that this implies that you should never participate in any Simplici=
ty
> > contract where you don't get access to the entire source code of all
> > branches to check that it doesn't have an unknown jet.
> >
> > On Mon, Oct 30, 2017 at 5:42 PM, Matt Corallo <lf-lists@mattcorallo.com>=
> > wrote:
> >>
> >> I admittedly haven't had a chance to read the paper in full details, bu=
t I
> >> was curious how you propose dealing with "jets" in something like Bitco=
in.
> >> AFAIU, other similar systems are left doing hard-forks to reduce the
> >> sigops/weight/fee-cost of transactions every time they want to add usef=
ul
> >> optimized drop-ins. For obvious reasons, this seems rather impractical a=
nd a
> >> potentially critical barrier to adoption of such optimized drop-ins, wh=
ich I
> >> imagine would be required to do any new cryptographic algorithms due to=
the
> >> significant fee cost of interpreting such things.
> >>
> >> Is there some insight I'm missing here?
> >>
> >> Matt
> >>
> >>
> >> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>
> >>> I've been working on the design and implementation of an alternative t=
o
> >>> Bitcoin Script, which I call Simplicity. Today, I am presenting my de=
sign
> >>> at the PLAS 2017 Workshop on Programming Languages and Analysis for
> >>> Security. You find a copy of my Simplicity paper at
> >>> https://blockstream.com/simplicity.pdf
> >>>
> >>> Simplicity is a low-level, typed, functional, native MAST language whe=
re
> >>> programs are built from basic combinators. Like Bitcoin Script, Simpl=
icity
> >>> is designed to operate at the consensus layer. While one can write
> >>> Simplicity by hand, it is expected to be the target of one, or multipl=
e,
> >>> front-end languages.
> >>>
> >>> Simplicity comes with formal denotational semantics (i.e. semantics of=
> >>> what programs compute) and formal operational semantics (i.e. semantic=
s of
> >>> how programs compute). These are both formalized in the Coq proof assi=
stant
> >>> and proven equivalent.
> >>>
> >>> Formal denotational semantics are of limited value unless one can use
> >>> them in practice to reason about programs. I've used Simplicity's form=
al
> >>> semantics to prove correct an implementation of the SHA-256 compressio=
n
> >>> function written in Simplicity. I have also implemented a variant of E=
CDSA
> >>> signature verification in Simplicity, and plan to formally validate it=
s
> >>> correctness along with the associated elliptic curve operations.
> >>>
> >>> Simplicity comes with easy to compute static analyses that can compute=
> >>> bounds on the space and time resources needed for evaluation. This is=
> >>> important for both node operators, so that the costs are knows before
> >>> evaluation, and for designing Simplicity programs, so that smart-contr=
act
> >>> participants can know the costs of their contract before committing to=
it.
> >>>
> >>> As a native MAST language, unused branches of Simplicity programs are
> >>> pruned at redemption time. This enhances privacy, reduces the block w=
eight
> >>> used, and can reduce space and time resource costs needed for evaluati=
on.
> >>>
> >>> To make Simplicity practical, jets replace common Simplicity expressio=
ns
> >>> (identified by their MAST root) and directly implement them with C cod=
e. I
> >>> anticipate developing a broad set of useful jets covering arithmetic
> >>> operations, elliptic curve operations, and cryptographic operations
> >>> including hashing and digital signature validation.
> >>>
> >>> The paper I am presenting at PLAS describes only the foundation of the=
> >>> Simplicity language. The final design includes extensions not covered=
in
> >>> the paper, including
> >>>
> >>> - full convent support, allowing access to all transaction data.
> >>> - support for signature aggregation.
> >>> - support for delegation.
> >>>
> >>> Simplicity is still in a research and development phase. I'm working t=
o
> >>> produce a bare-bones SDK that will include
> >>>
> >>> - the formal semantics and correctness proofs in Coq
> >>> - a Haskell implementation for constructing Simplicity programs
> >>> - and a C interpreter for Simplicity.
> >>>
> >>> After an SDK is complete the next step will be making Simplicity
> >>> available in the Elements project so that anyone can start experimenti=
ng
> >>> with Simplicity in sidechains. Only after extensive vetting would it b=
e
> >>> suitable to consider Simplicity for inclusion in Bitcoin.
> >>>
> >>> Simplicity has a long ways to go still, and this work is not intended t=
o
> >>> delay consideration of the various Merkelized Script proposals that ar=
e
> >>> currently ongoing.
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>=20
--Apple-Mail-153FE09F-10A7-4DDA-8DA3-C203951615D5
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">I don=E2=80=99t think you need to set an or=
der of operations, just treat the jet as TRUE, but don=E2=80=99t stop valida=
tion. Order of operations doesn=E2=80=99t matter. Either way it=E2=80=99ll e=
xecute both branches and terminate of the understood conditions don=E2=80=99=
t hold.<br><br><div>But maybe I=E2=80=99m missing something here. </div=
><div><br>On Oct 31, 2017, at 2:01 PM, Russell O'Connor <<a href=3D"mailt=
o:roconnor@blockstream.io">roconnor@blockstream.io</a>> wrote:<br><br></d=
iv><blockquote type=3D"cite"><div><div dir=3D"auto"><div>That approach is wo=
rth considering. However there is a wrinkle that Simplicity's denotati=
onal semantics doesn't imply an order of operations. For example, if o=
ne half of a pair contains a assertion failure (fail-closed), and the other h=
alf contains a unknown jet (fail-open), then does the program succeed or fai=
l?<div dir=3D"auto"><br></div><div dir=3D"auto">This could be solved by prov=
iding an order of operations; however I fear that will complicate formal rea=
soning about Simplicity expressions. Formal reasoning is hard enough a=
s is and I hesitate to complicate the semantics in ways that make formal rea=
soning harder still.</div><br><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Oct 31, 2017 15:47, "Mark Friedenbach" <<a href=3D"mailto:=
mark@friedenbach.org">mark@friedenbach.org</a>> wrote:<br type=3D"attribu=
tion"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">Nit, but if you go down that specific path I w=
ould suggest making just<br>
the jet itself fail-open. That way you are not so limited in requiring<br>
validation of the full contract -- one party can verify simply that<br>
whatever condition they care about holds on reaching that part of the<br>
contract. E.g. maybe their signature is needed at the top level, and<br>
then they don't care what further restrictions are placed.<br>
<br>
On Tue, Oct 31, 2017 at 1:38 PM, Russell O'Connor via bitcoin-dev<br>
<div class=3D"elided-text"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
> (sorry, I forgot to reply-all earlier)<br>
><br>
> The very short answer to this question is that I plan on using Luke's<b=
r>
> fail-success-on-unknown-<wbr>operation in Simplicity. This is som=
ething that<br>
> isn't detailed at all in the paper.<br>
><br>
> The plan is that discounted jets will be explicitly labeled as jets in t=
he<br>
> commitment. If you can provide a Merkle path from the root to a n=
ode that<br>
> is an explicit jet, but that jet isn't among the finite number of known=
<br>
> discounted jets, then the script is automatically successful (making it=
<br>
> anyone-can-spend). When new jets are wanted they can be soft-fork=
ed into<br>
> the protocol (for example if we get a suitable quantum-resistant digita=
l<br>
> signature scheme) and the list of known discounted jets grows. Ol=
d nodes<br>
> get a merkle path to the new jet, which they view as an unknown jet, an=
d<br>
> allow the transaction as a anyone-can-spend transaction. New node=
s see a<br>
> regular Simplicity redemption. (I haven't worked out the details o=
f how the<br>
> P2P protocol will negotiate with old nodes, but I don't forsee any<br>
> problems.)<br>
><br>
> Note that this implies that you should never participate in any Simplic=
ity<br>
> contract where you don't get access to the entire source code of all<br=
>
> branches to check that it doesn't have an unknown jet.<br>
><br>
> On Mon, Oct 30, 2017 at 5:42 PM, Matt Corallo <<a href=3D"mailto:lf-=
lists@mattcorallo.com">lf-lists@mattcorallo.com</a>><br>
> wrote:<br>
>><br>
>> I admittedly haven't had a chance to read the paper in full details=
, but I<br>
>> was curious how you propose dealing with "jets" in something like B=
itcoin.<br>
>> AFAIU, other similar systems are left doing hard-forks to reduce th=
e<br>
>> sigops/weight/fee-cost of transactions every time they want to add u=
seful<br>
>> optimized drop-ins. For obvious reasons, this seems rather impracti=
cal and a<br>
>> potentially critical barrier to adoption of such optimized drop-ins=
, which I<br>
>> imagine would be required to do any new cryptographic algorithms du=
e to the<br>
>> significant fee cost of interpreting such things.<br>
>><br>
>> Is there some insight I'm missing here?<br>
>><br>
>> Matt<br>
>><br>
>><br>
>> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-d=
ev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>><br>
>>> I've been working on the design and implementation of an altern=
ative to<br>
>>> Bitcoin Script, which I call Simplicity. Today, I am pres=
enting my design<br>
>>> at the PLAS 2017 Workshop on Programming Languages and Analysis=
for<br>
>>> Security. You find a copy of my Simplicity paper at<br>
>>> <a href=3D"https://blockstream.com/simplicity.pdf" rel=3D"noref=
errer" target=3D"_blank">https://blockstream.com/<wbr>simplicity.pdf</a><br>=
>>><br>
>>> Simplicity is a low-level, typed, functional, native MAST langu=
age where<br>
>>> programs are built from basic combinators. Like Bitcoin S=
cript, Simplicity<br>
>>> is designed to operate at the consensus layer. While one c=
an write<br>
>>> Simplicity by hand, it is expected to be the target of one, or m=
ultiple,<br>
>>> front-end languages.<br>
>>><br>
>>> Simplicity comes with formal denotational semantics (i.e. seman=
tics of<br>
>>> what programs compute) and formal operational semantics (i.e. s=
emantics of<br>
>>> how programs compute). These are both formalized in the Coq pro=
of assistant<br>
>>> and proven equivalent.<br>
>>><br>
>>> Formal denotational semantics are of limited value unless one c=
an use<br>
>>> them in practice to reason about programs. I've used Simplicity=
's formal<br>
>>> semantics to prove correct an implementation of the SHA-256 com=
pression<br>
>>> function written in Simplicity. I have also implemented a=
variant of ECDSA<br>
>>> signature verification in Simplicity, and plan to formally vali=
date its<br>
>>> correctness along with the associated elliptic curve operations=
.<br>
>>><br>
>>> Simplicity comes with easy to compute static analyses that can c=
ompute<br>
>>> bounds on the space and time resources needed for evaluation.&n=
bsp; This is<br>
>>> important for both node operators, so that the costs are knows b=
efore<br>
>>> evaluation, and for designing Simplicity programs, so that smar=
t-contract<br>
>>> participants can know the costs of their contract before commit=
ting to it.<br>
>>><br>
>>> As a native MAST language, unused branches of Simplicity progra=
ms are<br>
>>> pruned at redemption time. This enhances privacy, reduces=
the block weight<br>
>>> used, and can reduce space and time resource costs needed for e=
valuation.<br>
>>><br>
>>> To make Simplicity practical, jets replace common Simplicity ex=
pressions<br>
>>> (identified by their MAST root) and directly implement them wit=
h C code. I<br>
>>> anticipate developing a broad set of useful jets covering arith=
metic<br>
>>> operations, elliptic curve operations, and cryptographic operat=
ions<br>
>>> including hashing and digital signature validation.<br>
>>><br>
>>> The paper I am presenting at PLAS describes only the foundation=
of the<br>
>>> Simplicity language. The final design includes extensions=
not covered in<br>
>>> the paper, including<br>
>>><br>
>>> - full convent support, allowing access to all transaction data=
.<br>
>>> - support for signature aggregation.<br>
>>> - support for delegation.<br>
>>><br>
>>> Simplicity is still in a research and development phase. I=
'm working to<br>
>>> produce a bare-bones SDK that will include<br>
>>><br>
>>> - the formal semantics and correctness proofs in Coq<br>
>>> - a Haskell implementation for constructing Simplicity programs=
<br>
>>> - and a C interpreter for Simplicity.<br>
>>><br>
>>> After an SDK is complete the next step will be making Simplicit=
y<br>
>>> available in the Elements project so that anyone can start expe=
rimenting<br>
>>> with Simplicity in sidechains. Only after extensive vetting wou=
ld it be<br>
>>> suitable to consider Simplicity for inclusion in Bitcoin.<br>
>>><br>
>>> Simplicity has a long ways to go still, and this work is not in=
tended to<br>
>>> delay consideration of the various Merkelized Script proposals t=
hat are<br>
>>> currently ongoing.<br>
><br>
><br>
><br>
</div><div class=3D"elided-text">> ______________________________<wbr>___=
______________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>=
org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
><br>
</div></blockquote></div><br></div></div></div>
</div></blockquote></body></html>=
--Apple-Mail-153FE09F-10A7-4DDA-8DA3-C203951615D5--
|