Thread
Over the last couple of months I have steadily come to the convinced that Bitcoin Smart Contracts are closer to viable than most people understand.
Further, I *think* Turing Complete contracts can be done on Bitcoin without ANY consensus changes being required.
Intrigued?
🧵
Further, I *think* Turing Complete contracts can be done on Bitcoin without ANY consensus changes being required.
Intrigued?
🧵
Let's review the purpose of "smart contracts", because in the noise of the Layer1 marketing wars we neglect talking about what the tech actually affords.
Smart Contracts are a construct that allow us to verifiably restrict the ways in which we can transfer control of assets.
Smart Contracts are a construct that allow us to verifiably restrict the ways in which we can transfer control of assets.
Stated differently, when we place assets under contract, we voluntarily relinquish the right to unilaterally transfer their control. The base case for BTC is a multisig, or a timelock release.
In Ethereum, any ETH deposited to a "contract" can only leave the contract via its API
In Ethereum, any ETH deposited to a "contract" can only leave the contract via its API
Ethereum boasts having Turing Complete smart contracts by making the execution of the API a matter of global consensus. Every opcode in a contract (API) call is executed by every validator. Any deviation from the specified semantics of those opcodes constitutes a consensus fork.
However, the property that is needed to be a valid contract is merely "the only state transitions on which the network can agree are those consistent with the specified intent of the contract"...a much weaker requirement.
In Bitcoin, we already have Multisignature agreements in Script and with Taproot we actually turn multisig into an L2 protocol. So at base, ANY agreement that can be securely agreed upon by a number of participants, can be reduced to multisig, and is consensus enforceable.
OK, but "securely agreed upon by a number of participants" is a pretty tall order. How big is the set of protocols that fit that description? Schockingly large. However, we have to bend our traditional definitions of "secure" from being a cryptographic property to an economic one
Here's the good news though... this is something we already accept at minimum with the LN security model, and at max is actually the security model of Bitcoin's consensus itself. So this isn't actually a meaningful change to the security model we already live with.
So how does it work? At the genesis of a contract you all counterparties have to post collateral to give them something to lose in discoordination scenarios. From there, it is sufficient to give every party a complete description of what state transitions are permissible.
It is reasonable to assume that any state transition you propose that is NOT consistent with this description, will not be agreed to by your counterparties. However, this isn't enough to guarantee that you can come to agreement on *anything*, so how can we ensure progress?
Well, this is where the collateral comes in. On a regular time interval new relative timelock branches need to be made available, either burning or stealing the collateral by the party that does not cooperate...that's it.
This creates a scenario where all contract counterparties are racing the clock to come to agreement on the next transaction to co-sign. The schelling points are defined in contract, and any attempt to coordinate out of band on noncompliant transitions has a high chance of failure
if you risk losing collateral by trying to coordinate on something not described in the contract, and you don't by faithfully executing it, you are incentivized to cooperate, rather than defect.
This leaves one pesky detail? If you can only lose, why participate at all?
This leaves one pesky detail? If you can only lose, why participate at all?
For this to work properly, the executors of the contract must stand to gain from the execution process. As such, any secure contract design must include a nonzero flow of funds from the "users" of the contract to the "enforcers". Much like miners at L1, we pay for coordination.
With a small profit margin on cooperation, and a high risk of nontrivial loss on defect, all parties will be incentivized to come to agreement before the clock runs out, yielding a faithful execution of the contract.
How complicated can the state transition rules be? Arbitrarily complicated. There is actually nothing that stops you from running an entire copy of the EVM in this way. Without extra tricks, you'd lose the ability to do contract to contract calls, but that's a problem for later.
If this seems delicate, it's because it is. And there are still many many kinks to work out wrt how the actual design of the contracts should be done to ensure there aren't any edge cases in the game theory. But what is nice about it is that it requires no consensus changes.
Additionally, the security model can be easily upgraded with CTV (or any other covenant proposal) activation. This is because you get consensus enforcement preventing an exit of the contract state graph, and coordination limited to choosing which edges of the graph to follow.
Tons more research to do here, but this has been bouncing around my head for a bit and needed to get it out into words. Assuming these details get solved it would mean a relatively quick path to useful Bitcoin smart contracts.
Fin.
If this thread inspired you, follow me as well as @JeremyRubin, and start diving into Sapio* today, as this is where the product of that research will be codified.
Ship code and flip birds. Hope y'all have a great day.
* github.com/sapio-lang/sapio
If this thread inspired you, follow me as well as @JeremyRubin, and start diving into Sapio* today, as this is where the product of that research will be codified.
Ship code and flip birds. Hope y'all have a great day.
* github.com/sapio-lang/sapio
Bonus facts:
1. contracts are not part of global state, meaning no consensus drag
2. when contracts expire, their can be forever destroyed and never need to be reverified, even by the parties executing them
3. contracts are private by default, known only to participants
1. contracts are not part of global state, meaning no consensus drag
2. when contracts expire, their can be forever destroyed and never need to be reverified, even by the parties executing them
3. contracts are private by default, known only to participants
Mentions
There are no mentions of this content so far.