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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 444D1C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 00:32:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 1FC8A4013E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 00:32:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id T1fJ4UzC8XtZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 00:32:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp2.osuosl.org (Postfix) with ESMTPS id DA98D400C7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 Dec 2021 00:32:50 +0000 (UTC)
Date: Wed, 08 Dec 2021 00:32:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1638923567;
bh=b4XQ+bFcQEz9Wb5LFvKUgACvM7gqGtkPeEw2T5zUN9A=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
From:To:Cc;
b=rq6zu8bG84aqBure7QqeUCrsxQoFD/nGdy+Z9vUYQDj2GBpI3WXvgAEASVB4J8Xce
OkJkru8JtVDpVcdumP7bhoEOMuLNgaurlELS/+9HQKMfQyLTmmuSZddVsUCtBbzyOC
VUBqGAWzv0WJGq9OUcImY7LpjQqr0cOyKPxGEidNT8BV8mFhNBhU7H+j+LoZYzVxk+
xzhoFXTGRlKo2eHp+et8nrBgB3NavMYN+7+zLmQoCuAVtRT8igVnq0OTdwlKgoJsso
hc51Ny5rMnhcx8yUPPS5z+ZK22bUNNDyu3sWeaFh2ZsNva4BrA6fN50He97b1bplU1
iDNLQQaaBNBrw==
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com>
In-Reply-To: <CAD5xwhjSZtm6X9J0w6uVg_ZDO7FuS=OCQ_kncURAcW_DuXq9HQ@mail.gmail.com>
References: <CAD5xwhjSZtm6X9J0w6uVg_ZDO7FuS=OCQ_kncURAcW_DuXq9HQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 00:32:53 -0000
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 precurso=
r to securing Bitcoin's future rather than something we should do after mak=
ing 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 "breathe=
r" post between content posts?
In any case, given the subject line, it seems a waste not to discuss the ac=
tual "smart" in "smart" contract...
## Why would a "Smart" contract be "Smart"?
A "smart" contract is simply one that somehow self-enforces rather than req=
uires a third party to enforce it.
It is "smart" because its execution is done automatically.
Consider the humble HTLC.
It is simply a contract which says:
* If B can provide the preimage for this hash H, it gets the money from A.
* If the time L arrives without B claiming this fund, A gets its money back=
.
Why would an HTLC self-enforce?
Why would a simple paper contract with the above wording, signed and notari=
zed, be insufficient?
An HTLC self-enforces because given the Bitcoin network, it is not possible=
to violate and transfer the funds outside of the HTLC specification.
Whereas a paper contract can be mere ink on a page, if sufficient firepower=
is directed at the people (judges, lawyers, etc.) that would ensure its fa=
ithful execution.
You puny humans are notoriously squishy and easily destroyed.
But we must warn as well that the Bitcoin network is *also* run by people.
Thus, a "smart" contract is only "smart" to a degree, and that degree is de=
pendent on how easily it is for the "justice system" that enforces the cont=
ract to be subverted.
After all, a "smart" contract is software, and software must run on some ha=
rdware in order to execute.
Thus, even existing paper contracts are "smart" to a degree, too.
It is simply that the hardware they run on top of --- a bunch of puny human=
s --- is far less reliable than cold silicon (so upgrade your compute subst=
rate already, puny humans!).
Our hope with the Bitcoin experiment is that we might actually be able to m=
ake it much harder to subvert contracts running on the Bitcoin network.
It is that difficulty of subversion which determines the "smart"ness of a s=
mart contract.
Bitcoin is effectively a massive RAID1 on several dozen thousands of redund=
ant compute hardware, ensuring that the execution of every contract is fait=
hful to the Bitcoin SCRIPT programming model.
This is why the reticence of Bitcoin node operators to change the programmi=
ng model is a welcome feature of the network.
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.
And without that strong reticence, we risk utterly demolishing the basis of=
the "smart"ness of "smart" contracts --- if a "smart" contract cannot reli=
ably be executed, it cannot self-enforce, and if it cannot self-enforce, it=
is no longer particularly "smart".
## 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 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").
Thus, a contract must by necessity require N participants.
This is of interest since in a reliability perspective, we often accept k-o=
f-n.
For example, we might run a computation on three different pieces of hardwa=
re, and if only one diverges, we accept the result of the other two as true=
and the diverging hardware as faulty.
However, the above 2-of-3 example has a hidden assumption: that all three p=
ieces of hardware are actually owned and operated by a single entity.
A contract has N participants, and is not governed by a single entity.
Thus, it cannot use k-of-n replication.
Contracts require N-of-N replication.
In Bitcoin terms, that is what we mean by "consensus" --- that all Bitcoin =
network participants can agree that some transfer is "valid".
Similarly, L2 layers, to be able to host properly "smart" contracts, requir=
e N-of-N agreement.
For example, a Lightning Network channel can properly host "smart" HTLCs, a=
s the channel is controlled via 2-of-2 agreement.
Lesser L2 layers which support k-of-n thus have degraded "smartness", as a =
quorum of k participants can evict the n-k and deny the execution of the sm=
art contract.
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.
Regards,
ZmnSCPxj
|
