Date: Thu, 04 Apr 2019 07:07:10 +0000
To: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Yz-vUCuXGAD-evAyVSQDlL-8GzfDE-hDvGza7dgTY39gdklIZbFIv6XDfoBHSz96bwBNLCtAtCsXKvX7n-9oRqSgIVBD17y57Vvu8tzURXw=@protonmail.com>
In-Reply-To: <77b8f255-8f70-431e-839c-b99361d1dac7@gmail.com>
References: <IAFPSZAn6TYt348fmmnPznQ_ApG7pa48eMjzTgrjuVAt6fS1tNieRxlcIXyTATy2vjZCUn4wVQcsyDlyb_3Ip46BstFRikB95-lKewAZBEE=@protonmail.com>
	<77b8f255-8f70-431e-839c-b99361d1dac7@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Smart Contracts Unchained
Precedence: list

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 c=
ontract rules (eg. an independently signed cashing out message). How would =
the escrow know that the contract state is old and the operation is disallo=
wed, without using a consensus mechanism like a blockchain?

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

Suppose our purported smart contract platform supports some kind of covenan=
t system.
This means, that it is possible to make a branch of the contract require th=
at the fund go to a specific address template in the transaction that spend=
s 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 tran=
saction 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 fun=
ds into the smart contract.

The smart contract platform just signs "blindly" without particularly carin=
g 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 wi=
tnesses correctly.

Now upon reaching Tn, the winner(s) can just publish the sequence of transa=
ctions T1...Tn.
Alternately, they can present the sequence of transactions T1...Tn to all p=
articipants, 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 sho=
rtcuts 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) a=
nd 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