Date: Wed, 08 Dec 2021 00:32:37 +0000
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
Precedence: list

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