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

[Prayank via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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.
> > 
> > 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.
> > 
> > But with an N-of-N, *you* are a participant and your input is necessary for 

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

[Jeremy via bitcoin-dev]

--
@JeremyRubin 


Hi!

On Tue, Dec 7, 2021 at 4:33 PM ZmnSCPxj  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.
> **
> 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.
> 
> 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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
___
bitcoin-dev mailing list

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

[Jeremy via bitcoin-dev]

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 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev