From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 71B07C0012 for ; 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 ; 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 ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <4RdeDclGQpoDin2VLO5Ngmoghw03BZ_tvdO0vaIp_fNWWlKL9tHeIz1iQMpHxAww2pzjI4NXYtNFuND5Qkj7AmvLUajSp4AKxNg70VWr3Rw=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. > > > > 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. > > > > 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