From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ariel Lorenzo-Luaces <arielluaces@gmail•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Smart Contracts Unchained
Date: Thu, 04 Apr 2019 07:07:10 +0000 [thread overview]
Message-ID: <Yz-vUCuXGAD-evAyVSQDlL-8GzfDE-hDvGza7dgTY39gdklIZbFIv6XDfoBHSz96bwBNLCtAtCsXKvX7n-9oRqSgIVBD17y57Vvu8tzURXw=@protonmail.com> (raw)
In-Reply-To: <77b8f255-8f70-431e-839c-b99361d1dac7@gmail.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
next prev parent reply other threads:[~2019-04-04 7:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 1:55 ZmnSCPxj
2019-04-04 2:35 ` Tamas Blummer
2019-04-04 3:37 ` Ariel Lorenzo-Luaces
2019-04-04 7:07 ` ZmnSCPxj [this message]
2019-04-04 15:03 ` ZmnSCPxj
2019-04-04 17:18 ` Aymeric Vitte
2019-04-04 23:52 ` ZmnSCPxj
2019-04-05 17:46 ` Aymeric Vitte
2019-04-08 10:45 ` ZmnSCPxj
2019-04-08 16:28 ` Aymeric Vitte
2019-04-05 6:00 ` ZmnSCPxj
2019-04-17 16:17 ` Nadav Kohen
2019-04-18 5:33 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Yz-vUCuXGAD-evAyVSQDlL-8GzfDE-hDvGza7dgTY39gdklIZbFIv6XDfoBHSz96bwBNLCtAtCsXKvX7n-9oRqSgIVBD17y57Vvu8tzURXw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=arielluaces@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox