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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id BA0DBC0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 01:12:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A2F4283F93
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 01:12:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CfuvmfPSs9LH
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 01:12:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.osuosl.org (Postfix) with ESMTPS id 312B483F90
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 01:12:09 +0000 (UTC)
Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com
[209.85.208.178]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1B81C7vg012592
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 7 Dec 2021 20:12:08 -0500
Received: by mail-lj1-f178.google.com with SMTP id k2so1316390lji.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 07 Dec 2021 17:12:08 -0800 (PST)
X-Gm-Message-State: AOAM531xKqo9/pacaurTeIUlo5uFCom9C8FH/i/hzAkJCX3VaZ7gRFRT
kDZRD7ONqAQvnP/CDAkuVWpBtkZR4cokP+ohE2c=
X-Google-Smtp-Source: ABdhPJxnPISJudU3qDnkB1I2Mx0XwqULRelJQaCvfayjBWW0+aYksE5HALO5IgqY0QVvlWtUXa5lws+6BIEbC1268Uo=
X-Received: by 2002:a05:651c:1696:: with SMTP id
bd22mr45679841ljb.57.1638925926652;
Tue, 07 Dec 2021 17:12:06 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhjSZtm6X9J0w6uVg_ZDO7FuS=OCQ_kncURAcW_DuXq9HQ@mail.gmail.com>
<4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com>
In-Reply-To: <4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 7 Dec 2021 17:11:55 -0800
X-Gmail-Original-Message-ID: <CAD5xwhgxaDzM3T7YiRjOzC7cjD65yyq2_Z=QZ0Ko-d3LGvB9jQ@mail.gmail.com>
Message-ID: <CAD5xwhgxaDzM3T7YiRjOzC7cjD65yyq2_Z=QZ0Ko-d3LGvB9jQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000abe20905d2982d71"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about
Smart Contracts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 08 Dec 2021 01:12:11 -0000
--000000000000abe20905d2982d71
Content-Type: text/plain; charset="UTF-8"
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
Hi!
On Tue, Dec 7, 2021 at 4:33 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Jeremy,
>
> >
> > Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/,
> the topic is why smart contracts (in extended form) may be a critical
> precursor to securing Bitcoin's future rather than something we should do
> after making the base layer more robust.
>
>
> *This* particular post seems to contain more polemic than actual content.
> This is the first post I read of the series, so maybe it is just a
> "breather" post between content posts?
>
The series in general is intended to be a bit more on the approachable side
than hardcore detail.
>
> In any case, given the subject line, it seems a waste not to discuss the
> actual "smart" in "smart" contract...
>
>
Yeah maybe a better title would be "The Case for Enhanced Functionality in
Bitcoin" -- it's not really about smart contracts per se, but the thing
that people are calling smart contracts in the broader community. This gets
down to prescriptive v.s. descriptive lingo and it's not really a debate I
care much for :)
> ## Why would a "Smart" contract be "Smart"?
>
> A "smart" contract is simply one that somehow self-enforces rather than
> requires a third party to enforce it.
> It is "smart" because its execution is done automatically.
>
There are no automatic executing smart contracts on any platform I'm aware
of. Bitcoin requires TX submission, same with Eth.
Enforcement and execution are different subjects.
> Consider the humble HTLC.
> *<snip>*
> This is why the reticence of Bitcoin node operators to change the
> programming model is a welcome feature of the network.
> Any change to the programming model risks the introduction of bugs to the
> underlying virtual machine that the Bitcoin network presents to contract
> makers.
> And without that strong reticence, we risk utterly demolishing the basis
> of the "smart"ness of "smart" contracts --- if a "smart" contract cannot
> reliably be executed, it cannot self-enforce, and if it cannot
> self-enforce, it is no longer particularly "smart".
>
I don't think that anywhere in the post I advocated for playing fast and
loose with the rules to introduce any sort of unreliability.
What I'm saying is more akin to we can actually improve the "hardware" that
Bitcoin runs on to the extent that it actually does give us better ability
to adjudicate the transfers of value, and we should absolutely and
aggressively pursue that rather than keeping Bitcoin running on a set
mechanisms that are insufficient to reach the scale, privacy, self custody,
and decentralization goals we have.
> ## The N-of-N Rule
>
> What is a "contract", anyway?
>
> A "contract" is an agreement between two or more parties.
> You do not make a contract to yourself, since (we assume) you are
> completely a single unit (in practice, humans are internally divided into
> smaller compute modules with slightly different incentives (note: I did not
> get this information by *personally* dissecting the brains of any humans),
> hence the "we assume").
> Thus, a contract must by necessity require N participants
This is getting too pedantic about contracts. If you want to go there,
you're also missing "consideration".
Smart Contracts are really just programs. And you absolutely can enter
smart contracts with yourself solely, for example, Vaults (as covered in
day 10) are an example where you form a contract where you are intended to
be the only party.
You could make the claim that a vault is just an open contract between you
and some future would be hacker, but the intent is that the contract is
there to just safeguard you and those terms should mostly never execute. +
you usually want to define contract participants as not universally
quantified...
>
> This is of interest since in a reliability perspective, we often accept
> k-of-n.
> <snip>
> But with an N-of-N, *you* are a participant and your input is necessary
> for the execution of the smart contract, thus you can be *personally*
> assured that the smart contract *will* be executed faithfully.
>
>
Yes I agree that N-N or K-N have uses -- Sapio is designed to work with
arbitrary thresholds in lieu of CTV/other covenant proposals which can be
used to emulate arbitrary business logic :)
However, the benefit of the contracts without that is non-interactivity of
sending. Having everyone online is a major obstacle for things like
decentralized coordination free mining pools (kinda, the whole coordination
free part). So if you just say "always do N-of-N" you basically lose the
entire thread of"smart contract capabilities improving the four pillars
(covered in earlier posts) which solidifies bitcoin's adjudication of
transfers of value.
--000000000000abe20905d2982d71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span st=
yle=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">--</span=
><br></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><a href=3D"https://twitter.com/Jeremy=
Rubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jer=
emyRubin" target=3D"_blank"></a></div></div></div><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">Hi!</div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Tue, Dec 7, 2021 at 4:33 PM ZmnSCPxj <<a href=
=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex">Good morning Jeremy,<br>
<br>
><br>
> Here's the day 6 post: <a href=3D"https://rubin.io/bitcoin/2021/12=
/03/advent-6/" rel=3D"noreferrer" target=3D"_blank">https://rubin.io/bitcoi=
n/2021/12/03/advent-6/</a>, the topic is why smart contracts (in extended f=
orm) may be a critical precursor to securing Bitcoin's future rather th=
an something we should do after making the base layer more robust.<br>
<br>
<br>
*This* particular post seems to contain more polemic than actual content.<b=
r>
This is the first post I read of the series, so maybe it is just a "br=
eather" post between content posts?<br></blockquote><div><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;c=
olor:rgb(0,0,0)">The series in general is intended to be a bit more on the =
approachable side than hardcore detail.</div><div><div dir=3D"ltr" class=3D=
"gmail_signature"></div></div><br class=3D"gmail-Apple-interchange-newline"=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex">
<br>
In any case, given the subject line, it seems a waste not to discuss the ac=
tual "smart" in "smart" contract...<br>
<br></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Ye=
ah maybe a better title would be "The Case for Enhanced Functionality =
in Bitcoin" -- it's not really about smart contracts per se, but t=
he thing that people are calling smart contracts in the broader community. =
This gets down to prescriptive v.s. descriptive lingo and it's not real=
ly a debate I care much for :)</div><br></div><div><br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex">
## Why would a "Smart" contract be "Smart"?<br>
<br>
A "smart" contract is simply one that somehow self-enforces rathe=
r than requires a third party to enforce it.<br>
It is "smart" because its execution is done automatically.<br></b=
lockquote><div><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">There are no a=
utomatic executing smart contracts on any platform I'm aware of. Bitcoi=
n requires TX submission, same with Eth.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Enforcement and execut=
ion are different subjects.</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)"></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Consider the humble HTLC.<br>
<span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)"><b><snip></b></span><br>
This is why the reticence of Bitcoin node operators to change the programmi=
ng model is a welcome feature of the network.<br>
Any change to the programming model risks the introduction of bugs to the u=
nderlying virtual machine that the Bitcoin network presents to contract mak=
ers.<br>
And without that strong reticence, we risk utterly demolishing the basis of=
the "smart"ness of "smart" contracts --- if a "sm=
art" contract cannot reliably be executed, it cannot self-enforce, and=
if it cannot self-enforce, it is no longer particularly "smart".=
<br></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I =
don't think that anywhere in the post I advocated for playing fast and =
loose with the rules to introduce any sort of unreliability.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Wh=
at I'm saying is more akin to we can actually improve the "hardwar=
e" that Bitcoin runs on to the extent that it actually does give us be=
tter ability to adjudicate the transfers of value, and we should absolutely=
and aggressively pursue that rather than keeping Bitcoin running on a set =
mechanisms that are insufficient to reach the scale, privacy, self custody,=
and decentralization goals we have.</div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex">
## The N-of-N Rule<br>
<br>
What is a "contract", anyway?<br>
<br>
A "contract" is an agreement between two or more parties.<br>
You do not make a contract to yourself, since (we assume) you are completel=
y a single unit (in practice, humans are internally divided into smaller co=
mpute modules with slightly different incentives (note: I did not get this =
information by *personally* dissecting the brains of any humans), hence the=
"we assume").</blockquote><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Thus=
, a contract must by necessity require N participants</blockquote><div><br>=
</div><div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)">This is getting too pedantic=
about contracts. If you want to go there, you're also missing "co=
nsideration".</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">Smart Contracts are really just programs. An=
d you absolutely can enter smart contracts with yourself solely, for exampl=
e, Vaults (as covered in day 10) are an example where you form a contract w=
here you are intended to be the only party.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">You could make the =
claim that a vault is just an open contract between you and some future wou=
ld be hacker, but the intent is that the contract is there to just safeguar=
d you and those terms should mostly never execute.=C2=A0+ you usually want =
to define contract participants as not universally quantified...</div></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex">
<br>
This is of interest since in a reliability perspective, we often accept k-o=
f-n.<br><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><snip></span><br>
But with an N-of-N, *you* are a participant and your input is necessary for=
the execution of the smart contract, thus you can be *personally* assured =
that the smart contract *will* be executed faithfully.<br><br></blockquote>=
<div><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)">Yes I agree that N-N or =
K-N have uses -- Sapio is designed to work with arbitrary thresholds in lie=
u of CTV/other covenant proposals which can be used to emulate arbitrary bu=
siness logic :)</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">H=
owever, the benefit of the contracts without that is non-interactivity of s=
ending. Having everyone online is a major obstacle for things like decentra=
lized coordination free mining pools (kinda, the whole coordination free pa=
rt). So if you just say "always do N-of-N" you basically lose the=
entire thread of"smart contract capabilities improving the four pilla=
rs (covered in earlier posts) which solidifies bitcoin's adjudication o=
f transfers of value.</div></div></div>
--000000000000abe20905d2982d71--
|