From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts
Date: Wed, 08 Dec 2021 23:23:46 +0000 [thread overview]
Message-ID: <k50-_xW0s3WUdfQ2R8_189Q9omJjYglHAv9lXUpxlwabM_mHJmSa7mCzD8BOYnY3nOaYJGLhUwtbV6mJvEHzlk630u-ZfOuFCpUbEa9UY6M=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhgxaDzM3T7YiRjOzC7cjD65yyq2_Z=QZ0Ko-d3LGvB9jQ@mail.gmail.com>
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 aware of. Bitcoin requires TX submission, same with Eth.
>
> Enforcement and execution are different subjects.
Nothing really prevents a cryptocurrency system from recording a "default branch" 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 mempool.
* If the TXO is already spent by then, then they are not put in the mempool.
That way, at least the timelocked branch can be automatically executed, because the tx can be submitted "early".
The only real limitation against the above is the amount of resources it would consume on typical nodes.
Even watchtower behavior can be programmed directly into the blockchain layer, 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 cost 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 programming model is a welcome feature of the network.
> > Any change to the programming model risks the introduction of bugs to the underlying virtual machine that the Bitcoin network presents to contract makers.
> > And without that strong reticence, we risk utterly demolishing the basis 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 the post title better.
> What I'm saying is more akin to we can actually improve the "hardware" that Bitcoin runs on to the extent that it actually does give us better ability to adjudicate the transfers of value, and we should absolutely and aggressively pursue that rather than keeping Bitcoin running on a set mechanisms that are insufficient to reach the scale, privacy, self custody, and decentralization goals we have.
Agreed.
>
>
> > ## 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 completely a single unit (in practice, humans are internally divided into smaller compute 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 getting too pedantic about contracts. If you want to go there, you're also missing "consideration".
>
> Smart Contracts are really just programs. And you absolutely can enter smart 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 the 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 your 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 you and some future would be hacker, but the intent is that the contract is there to just safeguard you and those terms should mostly never execute. + 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* assured 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 arbitrary thresholds in lieu of CTV/other covenant proposals which can be used to emulate arbitrary business logic :)
>
> However, the benefit of the contracts without that is non-interactivity of sending. Having everyone online is a major obstacle for things like decentralized 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 value.
The point really is "buyer beware".
Any k-of-n where you do not puppet at least (n - k + 1) allows you to be evicted 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 executed faithfully --- then go ahead --- do k-of-n.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-12-08 23:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 23:29 Jeremy
2021-12-08 0:32 ` ZmnSCPxj
2021-12-08 1:11 ` Jeremy
2021-12-08 23:23 ` ZmnSCPxj [this message]
2021-12-23 9:42 Prayank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='k50-_xW0s3WUdfQ2R8_189Q9omJjYglHAv9lXUpxlwabM_mHJmSa7mCzD8BOYnY3nOaYJGLhUwtbV6mJvEHzlk630u-ZfOuFCpUbEa9UY6M=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox