Date: Wed, 08 Dec 2021 23:23:46 +0000
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <k50-_xW0s3WUdfQ2R8_189Q9omJjYglHAv9lXUpxlwabM_mHJmSa7mCzD8BOYnY3nOaYJGLhUwtbV6mJvEHzlk630u-ZfOuFCpUbEa9UY6M=@protonmail.com>
In-Reply-To: <CAD5xwhgxaDzM3T7YiRjOzC7cjD65yyq2_Z=QZ0Ko-d3LGvB9jQ@mail.gmail.com>
References: <CAD5xwhjSZtm6X9J0w6uVg_ZDO7FuS=OCQ_kncURAcW_DuXq9HQ@mail.gmail.com>
 <4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com>
 <CAD5xwhgxaDzM3T7YiRjOzC7cjD65yyq2_Z=QZ0Ko-d3LGvB9jQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about
	Smart Contracts
Precedence: list

Good morning Jeremy,


> > ## 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 awar=
e of. Bitcoin requires TX submission, same with Eth.
>
> Enforcement and execution are different subjects.

Nothing really prevents a cryptocurrency system from recording a "default b=
ranch" and enforcing that later.
In Bitcoin terms, nothing fundamentally prevents this redesign:

* A confirmed transaction can include one or more transactions (not part of=
 its wtxid or txid) which spend an output of that confirmed transaction.
  * Like SegWit, they can be put in a new region that is not visible to pre=
-softfork nodes, but this new section is committed to in the coinbase.
* Those extra transactions must be `nLockTime`d to a future blockheight.
* When the future blockheight arrives, we add those transactions to the mem=
pool.
  * If the TXO is already spent by then, then they are not put in the mempo=
ol.

That way, at least the timelocked branch can be automatically executed, bec=
ause the tx can be submitted "early".
The only real limitation against the above is the amount of resources it wo=
uld consume on typical nodes.

Even watchtower behavior can be programmed directly into the blockchain lay=
er, i.e. we can put encrypted blobs into the same extra blockspace, with a =
partial txid key that triggers decryption and putting those transactions in=
 the mempool, etc.
Thus, the line between execution and enforcement blurs.


But that is really beside the point.

The Real Point is that "smart"ness is not a Boolean flag, but a spectrum.
The above feature would allow for more "smart"ness in contracts, at the cos=
t of increased resource utilization at each node.
In this point-of-view, even a paper contract is "smart", though less "smart=
" than a typical Bitcoin HTLC.

> > Consider the humble HTLC.
> > <snip>
> > This is why the reticence of Bitcoin node operators to change the progr=
amming model is a welcome feature of the network.
> > Any change to the programming model risks the introduction of bugs to t=
he underlying virtual machine that the Bitcoin network presents to contract=
 makers.
> > And without that strong reticence, we risk utterly demolishing the basi=
s 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.

This is not a criticism of your post, merely an amusing article that fits t=
he post title better.

> What I'm saying is more akin to we can actually improve the "hardware" th=
at Bitcoin runs on to the extent that it actually does give us better abili=
ty to adjudicate the transfers of value, and we should absolutely and aggre=
ssively pursue that rather than keeping Bitcoin running on a set mechanisms=
 that are insufficient to reach the scale, privacy, self custody, and decen=
tralization goals we have.

Agreed.

> =C2=A0
>
> > ## 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 compl=
etely a single unit (in practice, humans are internally divided into smalle=
r compute modules with slightly different incentives (note: I did not get t=
his information by *personally* dissecting the brains of any humans), hence=
 the "we assume").
>
> =C2=A0
>
> > Thus, a contract must by necessity require N participants
>
> This is getting too pedantic about contracts. If you want to go there, yo=
u're also missing "consideration".
>
> Smart Contracts are really just programs. And you absolutely can enter sm=
art 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 t=
he only party.

No, because a vault is a contract between your self-of-today and your self-=
of-tomorrow, with your self-of-today serving as an attorney-in-place of you=
r self-of-tomorrow.
After all, at the next Planck Interval you will die and be replaced with a =
new entity that only *mostly* agrees with you.

> You could make the claim that a vault is just an open contract between yo=
u and some future would be hacker, but the intent is that the contract is t=
here to just safeguard you and those terms should mostly never execute.=
=C2=A0+ 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* assu=
red 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 a=
rbitrary thresholds in lieu of CTV/other covenant proposals which can be us=
ed to emulate arbitrary business logic :)
>
> However, the benefit of the contracts without that is non-interactivity o=
f sending. Having everyone online is a major obstacle for things like decen=
tralized 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 v=
alue.

The point really is "buyer beware".
Any k-of-n where you do not puppet at least (n - k + 1) allows you to be ev=
icted and your assets seized by somebody else puppeting k entities.
But if you trust that the other entities will not steal from you --- if you=
 do not need the *definite* assurance that the smart contract *will* be exe=
cuted faithfully --- then go ahead --- do k-of-n.


Regards,
ZmnSCPxj