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

Reply via email to