Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Ariel,

> However, consider the situation where a group of participants are playing poker. One participant loses all their funds and decides to present to the escrow the contract+an old contract state+a signed message following the contract rules (eg. an independently signed cashing out message). How would the escrow know that the contract state is old and the operation is disallowed, without using a consensus mechanism like a blockchain?

One might point to the various channel mechanisms (Poon-Dryja, Decker-Wattenhofer, Decker-Russell-Osuntokun) as counterarguments.
Though they require a blockchain as backing, old states are invalidated (Poon-Dryja) or replaceable (Decker-*), without necessarily requiring a blockchain to keep track of all the states.

Suppose our purported smart contract platform supports some kind of covenant system.
This means, that it is possible to make a branch of the contract require that the fund go to a specific address template in the transaction that spends it.
Suppose we use this mechanism to require that the Bitcoin-level transaction pay again to a contract in the same contract platform.
It then becomes possible to make a covenant that requires spending the transaction to the same covenant.

This can allow us to enforce creating an offchain sequence of transactions T1...Tn, such that T2 spends T1, T3 spends T2, etc.
Then the final transaction Tn completes the sequence and pays out according to the rules of Poker, or whatever.
This sequence is anchored on an onchain transaction T0 which enters the funds into the smart contract.

The smart contract platform just signs "blindly" without particularly caring whether the signature went onchain, or even whether the UTXO being spent exists onchain --- all it cares, is that the smart contract can be given witnesses correctly.

Now upon reaching Tn, the winner(s) can just publish the sequence of transactions T1...Tn.
Alternately, they can present the sequence of transactions T1...Tn to all participants, and offer to give back part of the money allocated to fees for all the transactions T1...Tn in exchange for a single transaction that shortcuts all of that and spends to however Tn splits out.

Basically, consider that the Decker-Russell-Osuntokun mechanism starts with a mechanism very much like the above (a sequence of update transactions) and then does some optimizations to allow the final transaction Tn to spend any transaction Ti where i < n.
But the basic concept that the sequence is at all possible, and can be kept offchain, implies this state does not require to be stored onchain at all.




Regards,
ZmnSCPxj