path: root/e5/941716f49b72746e85e8b0b87fedb04972f906

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 71B07C0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:23:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 51F3D60AA3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:23:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id m-4IrN4GY-2R
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:23:54 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 38AE2605E8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:23:54 +0000 (UTC)
Date: Wed, 08 Dec 2021 23:23:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail2; t=1639005831;
 bh=mN3qAHN3pRjt6ooxI3WTtsIYeWW1nzQ7pqjEEypAP60=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:From:To:Cc;
 b=M7FsC0cBWwON3ACg8Bvl7E5c1my+dM7qXR4pp68dkq2ZFNn1o+/bifCsHoMyqd1QK
 +5pf4vKRDq3f4+VXUnTI9nQxKEcyiUT+msQ80cfNsKANB9qdQ3WRJeqivgv3wps1qF
 i1P/O7PJXguhb4xP7vaaezD3d6yFfRC1U8kYvCR8+Jc7LC7dBk8etVNmK19bDgrMkT
 r2YKvmsYCUUZq/A1+pWPgqIxnCS2AbJuqN5i99jjb/vUNKxdwbzmZf/IjjGC51uV5d
 ATaCXcv2/s7x7uRz7MiCcCvKQsCQG5fkAodj8A9irV4CWeW5hVkd9QUqSbE4uSce93
 HjKiInkeS6QXg==
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
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 23:23:55 -0000

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