[bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Jeremy]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Hi!

Over the next month I'm doing a one-a-day blog post series till Christmas,
and I think some of the posts might be appropriate for discussion here.

Unfortunately I forgot to start the calendar series syndicated here too...
The first few posts are less bitcoin development related and philosophical,
so I think we could skip them and start around Day 6 and I'll post the rest
up to Day 10 here today (and do every day starting tomorrow). You can see
an archive of all posts at https://rubin.io/archive/. Every post will have
[Bitcoin Advent Calendar] if you wish to filter it :(.

---------------------------------

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 precursor
to securing Bitcoin's future rather than something we should do after
making the base layer more robust.

Cheers,

Jeremy Rubin

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

[-- Attachment #2: Type: text/html, Size: 2747 bytes --]

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[ZmnSCPxj]

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 precursor to securing Bitcoin's future rather than something we should do after making 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 "breather" post between content posts?

In any case, given the subject line, it seems a waste not to discuss the actual "smart" in "smart" contract...

## 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.

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 notarized, 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 faithful 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 dependent on how easily it is for the "justice system" that enforces the contract to be subverted.
After all, a "smart" contract is software, and software must run on some hardware 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 humans --- is far less reliable than cold silicon (so upgrade your compute substrate already, puny humans!).
Our hope with the Bitcoin experiment is that we might actually be able to make it much harder to subvert contracts running on the Bitcoin network.

It is that difficulty of subversion which determines the "smart"ness of a smart contract.
Bitcoin is effectively a massive RAID1 on several dozen thousands of redundant compute hardware, ensuring that the execution of every contract is faithful to the Bitcoin SCRIPT programming model.

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".

## 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 of interest since in a reliability perspective, we often accept k-of-n.
For example, we might run a computation on three different pieces of hardware, 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 pieces 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, require N-of-N agreement.
For example, a Lightning Network channel can properly host "smart" HTLCs, as 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 smart 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

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Jeremy]

[-- Attachment #1: Type: text/plain, Size: 4848 bytes --]

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

Hi!

On Tue, Dec 7, 2021 at 4:33 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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
> precursor to securing Bitcoin's future rather than something we should do
> after making 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
> "breather" post between content posts?
>

The series in general is intended to be a bit more on the approachable side
than hardcore detail.



>
> In any case, given the subject line, it seems a waste not to discuss the
> actual "smart" in "smart" contract...
>
>
Yeah maybe a better title would be "The Case for Enhanced Functionality in
Bitcoin" -- it's not really about smart contracts per se, but the thing
that people are calling smart contracts in the broader community. This gets
down to prescriptive v.s. descriptive lingo and it's not really a debate I
care much for :)




> ## 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.


> 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.

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.



> ## 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.

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.

[-- Attachment #2: Type: text/html, Size: 9759 bytes --]

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[ZmnSCPxj]

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

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hi 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 precursor
to securing Bitcoin's future rather than something we should do after
making the base layer more robust.

There are few comparisons in this post and links that I consider misleading or incomplete. I had already tweeted this but such discussions are better archived here:

Difference between Bitcoin and Ethereum that is not mentioned on the website which should be considered while looking at fees: 1. Size of blocks added to chain everyday (600 MB) 2. Block limit (500 MB per 10 mins) 3. UTXO vs Account model 4. Failed transactions that pay fees (50k per day) 5. Will these fancy smart contracts work without nodes? No. Where are these nodes running? AWS and Infura has nice articles to highlight their importance 6. Who is paying the fees? Stablecoins, DEX, NFT platforms, CEX and VCs

There can be lot of other differences that affect the fee market including lot of users in Bitcoin obsessed with supply and hodling. Things that have changed in last few years: 1. Darknet markets using Monero 2. Stablecoins stopped using Omni and lot of alternatives exist right now 3. Most of the transactions are related to exchanges. They have started using their own tokens, less exchanges support layer 2 for Bitcoin and users are forced to withdraw some altcoin even if they need bitcoin. 4. Newbies are reading influencers like Elon Musk and happy with their doggy coins to get rich quick/rekt. 5. Bitcoin users or influencers declared DeFi a scam and even sidechains like Liquid, Rootstock do not qualify their purity tests. Projects like DLCs are still not used in any projects with good volume.


-- 
Prayank

A3B1 E430 2298 178F

[-- Attachment #2: Type: text/html, Size: 2410 bytes --]