[bitcoin-dev] Smart Contracts Unchained

[bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

https://zmnscpxj.github.io/bitcoin/unchained.html

Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain.  Often this means creating a new blockchain, or at least a sidechain to an existing blockchain.  This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.

Re: [bitcoin-dev] Smart Contracts Unchained

[Tamas Blummer]

Hi ZmnSCPxj,

Thought provoking, thank you!

Something I dislike in the scheme, that one could not tell which party colluded with the escrow agent.

Tamas Blummer

> On Apr 4, 2019, at 03:55, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> https://zmnscpxj.github.io/bitcoin/unchained.html
> 
> Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain.  Often this means creating a new blockchain, or at least a sidechain to an existing blockchain.  This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Smart Contracts Unchained

[Ariel Lorenzo-Luaces]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

Hello ZmnSCPxj

I like the proposal because it generalizes escrow type mechanisms and I think it's a useful train of thought for distributed exchanges.

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?

Cheers
Ariel Lorenzo-Luaces

On Apr 3, 2019, 7:14 PM, at 7:14 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>https://zmnscpxj.github.io/bitcoin/unchained.html
>
>Smart contracts have traditionally been implemented as part of the
>consensus rules of some blokchain.  Often this means creating a new
>blockchain, or at least a sidechain to an existing blockchain.  This
>writeup proposes an alternative method without launching a separate
>blockchain or sidechain, while achieving security similar to federated
>sidechains and additional benefits to privacy and
>smart-contract-patching.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 1936 bytes --]

Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

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

Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

Somebody pointed out this to me:

https://gavintech.blogspot.com/2014/06/bit-thereum.html

I have updated the page accordingly.

One thing that seems not mentioned in bit-thereum is the "as long as everybody agrees" escape hatch, i.e. one branch which allows spending to anything (including a transaction that violates the letter of the contract) as long as all participants agree.
This is gives my newer mechanism the ability to "fix" buggy contracts if everybody involved can agree to the terms of a new contract, by simply abandoning the existing contract and spending to the new contract.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 4, 2019 9:55 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain. Often this means creating a new blockchain, or at least a sidechain to an existing blockchain. This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Smart Contracts Unchained

[Aymeric Vitte]

What if the smart contract platform(s) disappear?

The proposal induces a very centralized system, to my knowledge all of 
existing sidechains whether on bitcoin or ethereum are centralized, 
except lightning (if we forget that someone must watch what others are 
doing when you are on a trek in Nepal)

Now I don't get why a sidechain should be a blockchain on top on another 
one (given also that we can't consider bitcoin or ethereum as 
decentralized today, so the path might be long for the sidechains...), 
the latest is used to store the final state, the former does not have to 
store forever the intermediate states, then it could just use a 
decentralized system (not necessarilly blockchain-like) to store the 
intermediate states and maybe be a distributed escrow

I know, easy to say, please do it (why not), now the fact that 
sidechains claim to be decentralized or that they will be is just 
misleading people (that's not the case of your proposal but it does not 
say what happens if the platforms go down)


Le 04/04/2019 à 03:55, ZmnSCPxj via bitcoin-dev a écrit :
> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain.  Often this means creating a new blockchain, or at least a sidechain to an existing blockchain.  This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

Good morning Aymeric,


> What if the smart contract platform(s) disappear?
>

It is still possible to recover the funds, *if* you can convince all participants of some "fair" distribution of the funds.
You do this by all participants simply signing with their participant keys and taking the first branch of the script.
This branch does not require the participation of the smart contract platform, at all.
If all participants can agree to the result of the smart contract without dispute, then they can exit the platform even after the platform disappears.

Now of course there will be participants who will not cooperate in such a case, for example if they were doing some betting game and "lost".
But at least it gives the possibility of doing so, and it will not be as massive a loss.

Indeed, if the smart contract platform code is open source, it may be possible to set up another implementation of the smart contract platform.
And it would be possible to at least try to convince all participants to switch to that new platform (again, via the "as long as everybody agrees" escape hatch).
Again, this is not possible with current federated sidechains, or Ethereum (if Ethereum fails, all ETH becomes valueless).

> The proposal induces a very centralized system, to my knowledge all of
> existing sidechains whether on bitcoin or ethereum are centralized,
> except lightning (if we forget that someone must watch what others are
> doing when you are on a trek in Nepal)

I would not lump together Lightning with sidechains.
Indeed, this design moves things closer to true offchain techniques (as in Lightning) than to sidechain techniques.

So while centralized, it is less centralized than a federated sidechains.

> Now I don't get why a sidechain should be a blockchain on top on another
> one (given also that we can't consider bitcoin or ethereum as
> decentralized today, so the path might be long for the sidechains...),
> the latest is used to store the final state, the former does not have to
> store forever the intermediate states, then it could just use a
> decentralized system (not necessarilly blockchain-like) to store the
> intermediate states and maybe be a distributed escrow
>
> I know, easy to say, please do it (why not), now the fact that
> sidechains claim to be decentralized or that they will be is just
> misleading people (that's not the case of your proposal but it does not
> say what happens if the platforms go down)

Perhaps it can be a next step.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

Building from this ---

It is possible via this mechanism for the federation to be selected by the participants, rather than the federation being defined as a fixed set by the smart contract platform.

Perhaps anyone can advertise themselves (by e.g. locking some bonded amount on the blockchain with a `OP_CHECKSEQUENCEVERIFY`) as being willing to act as trusted executors of smart contracts.

Participants then select such executors they believe to be trustworthy, and what voting quorum of the selected executors is sufficient to convince the participants of the correct execution of the smart contract.

Of course, more choices, more cognitive effort for you mere humans, so probably not a good idea in general.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 4, 2019 9:55 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain. Often this means creating a new blockchain, or at least a sidechain to an existing blockchain. This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Smart Contracts Unchained

[Aymeric Vitte]

Hi,

Apparently you are not a fan of ethereum, as far as I can tell ethereum 
sidechains look like a mess with stupid tokens/transactions flooding the 
network while they are completely centralized, but some bitcoin 
sidechains can easily compete with this too, like Tether, don't even 
understand how anyone can give some credit to that stuff the way it is 
implemented, and if bitcoin fails that would be the same as for ethereum

Most likely everyone would agree if the escrow disappears, but not sure 
at all, let's imagine 1 to N put 10K on the table for a game, they 
update the states and at the end N wins everything, N is rich and don't 
care finally if the others cheaters have their coins locked (and to lose 
10K), same with setting up a new escrow to resolve the conflict

I think that you should highlight this (and what private key corresponds 
to E + h(E | s) * G, not sure it's trivial for everybody), probably a 
way to get this more decentralized is to reward the escrows (what is the 
interest here for people to run a smart contract platform?)

For lightning, maybe it's a question of wording, I consider it as a 
sidechain AND methods that can be used by other sidechains, as well as 
the others you quoted, even if only two people in the world use 
lightning, it is still decentralized, because it sustains itself alone

Regards

Aymeric

Le 05/04/2019 à 01:52, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
>> What if the smart contract platform(s) disappear?
>>
> It is still possible to recover the funds, *if* you can convince all participants of some "fair" distribution of the funds.
> You do this by all participants simply signing with their participant keys and taking the first branch of the script.
> This branch does not require the participation of the smart contract platform, at all.
> If all participants can agree to the result of the smart contract without dispute, then they can exit the platform even after the platform disappears.
>
> Now of course there will be participants who will not cooperate in such a case, for example if they were doing some betting game and "lost".
> But at least it gives the possibility of doing so, and it will not be as massive a loss.
>
> Indeed, if the smart contract platform code is open source, it may be possible to set up another implementation of the smart contract platform.
> And it would be possible to at least try to convince all participants to switch to that new platform (again, via the "as long as everybody agrees" escape hatch).
> Again, this is not possible with current federated sidechains, or Ethereum (if Ethereum fails, all ETH becomes valueless).
>
>> The proposal induces a very centralized system, to my knowledge all of
>> existing sidechains whether on bitcoin or ethereum are centralized,
>> except lightning (if we forget that someone must watch what others are
>> doing when you are on a trek in Nepal)
> I would not lump together Lightning with sidechains.
> Indeed, this design moves things closer to true offchain techniques (as in Lightning) than to sidechain techniques.
>
> So while centralized, it is less centralized than a federated sidechains.
>
>> Now I don't get why a sidechain should be a blockchain on top on another
>> one (given also that we can't consider bitcoin or ethereum as
>> decentralized today, so the path might be long for the sidechains...),
>> the latest is used to store the final state, the former does not have to
>> store forever the intermediate states, then it could just use a
>> decentralized system (not necessarilly blockchain-like) to store the
>> intermediate states and maybe be a distributed escrow
>>
>> I know, easy to say, please do it (why not), now the fact that
>> sidechains claim to be decentralized or that they will be is just
>> misleading people (that's not the case of your proposal but it does not
>> say what happens if the platforms go down)
> Perhaps it can be a next step.
>
> Regards,
> ZmnSCPxj

Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

Good morning Aymeric,

> Hi,
>
> Apparently you are not a fan of ethereum, as far as I can tell ethereum
> sidechains look like a mess with stupid tokens/transactions flooding the
> network while they are completely centralized, but some bitcoin
> sidechains can easily compete with this too, like Tether, don't even
> understand how anyone can give some credit to that stuff the way it is
> implemented, and if bitcoin fails that would be the same as for ethereum

I prefer to be more precise in my terminology.
Colored coins are not the same as sidechains, and there are colored coins and then there are colored coins.
This mechanism does not propose some change in colored coins.
An important aspect of colored coins is that one can foist them on somebody else to extract things of real value from them, but this mechanism is more strongly for a fixed set of participants.

I strongly suspect that Bitcoin will outlast Ethereum, but that is rather not very related to this topic.

> Most likely everyone would agree if the escrow disappears, but not sure
> at all, let's imagine 1 to N put 10K on the table for a game, they
> update the states and at the end N wins everything, N is rich and don't
> care finally if the others cheaters have their coins locked (and to lose
> 10K), same with setting up a new escrow to resolve the conflict
>

Indeed.
Still, the option to do so exists, and sometimes all that is needed for humans to do the right thing, is to be given the option to do so.

> I think that you should highlight this (and what private key corresponds
> to E + h(E | s) * G, not sure it's trivial for everybody), probably a
> way to get this more decentralized is to reward the escrows (what is the
> interest here for people to run a smart contract platform?)

I assumed both were obvious, but I suppose a few more words about those would not be amiss.

>
> For lightning, maybe it's a question of wording, I consider it as a
> sidechain AND methods that can be used by other sidechains, as well as
> the others you quoted, even if only two people in the world use
> lightning, it is still decentralized, because it sustains itself alone

Again, I prefer precision in my terminology.
For me, a sidechain is a blockchain of some sort.
In particular, a kind of Merklized singly-linked list containing representations of transformations of state, is how I define blockchain to be.

No such Merklized singly-linked list exists in Lightning Network, thus I do not consider it, "blockchain".
And thus I do not consider it "sidechain", as a sidechain is a blockchain.
Current LN does use "shachains" by Rusty, but shachains are not Merklized singly-linked lists, but are instead a kind of inverse mountain range structure.

Still, one might consider both federated sidechains and Lightning Network to have a "federated" offchain structure.
This is because the coins on the Bitcoin blockchain are locked to a multisignature and activity is not recorded on the Bitcoin blockchain.
However, in LN, each channel is a 2-member federation (you and a counterparty) and the mechanism in LN requires consensus (2-of-2) rather than a quorum (m-of-n).
This greatly increases the security of LN: the owner of funding on an LN channel can always refuse to sign an update if the other member of the federation is taken over.
Compare this to the quorum that typical federations have, where takeover of a sufficient quorum is enough to steal funds from the remaining federation.
https://zmnscpxj.github.io/offchain/safety.html

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Smart Contracts Unchained

[Aymeric Vitte]

Hi,

I took the example of colored coins because you quoted ethereum and like
most of ethereum tokens most of them reflect something coming from
nowhere, worse I can send you 10K Tethers if you like that of course
will not be validated by the central system but will be recorded in
bitcoin blockchain

Bitcoin oulasting ethereum, maybe, but the bitcoin community must make
more efforts to explain things, like "both were obvious" below is not in
fact for an usual reader, so a few more words would be good indeed

For me a sidechain does not have to be a blockchain but a decentralized
system allowing to secure off chain transactions until the final state
is stored into the blockchain, I don't see the use of storing forever
the intermediate states neither why the sidechain should be a
blockchain, if not then the sidechain would just be another
bitcoin/ethereum, no? What would be the purpose of building a blockchain
on top of another one? Just do your own, and this would eliminate the
drawback of needing to have bitcoins or ethers to smart contract things
that have nothing to do with them, as well as mixing addresses between
the blockchain and the sidechains

Regards

Aymeric

Le 08/04/2019 à 12:45, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> Hi,
>>
>> Apparently you are not a fan of ethereum, as far as I can tell ethereum
>> sidechains look like a mess with stupid tokens/transactions flooding the
>> network while they are completely centralized, but some bitcoin
>> sidechains can easily compete with this too, like Tether, don't even
>> understand how anyone can give some credit to that stuff the way it is
>> implemented, and if bitcoin fails that would be the same as for ethereum
> I prefer to be more precise in my terminology.
> Colored coins are not the same as sidechains, and there are colored coins and then there are colored coins.
> This mechanism does not propose some change in colored coins.
> An important aspect of colored coins is that one can foist them on somebody else to extract things of real value from them, but this mechanism is more strongly for a fixed set of participants.
>
> I strongly suspect that Bitcoin will outlast Ethereum, but that is rather not very related to this topic.
>
>> Most likely everyone would agree if the escrow disappears, but not sure
>> at all, let's imagine 1 to N put 10K on the table for a game, they
>> update the states and at the end N wins everything, N is rich and don't
>> care finally if the others cheaters have their coins locked (and to lose
>> 10K), same with setting up a new escrow to resolve the conflict
>>
> Indeed.
> Still, the option to do so exists, and sometimes all that is needed for humans to do the right thing, is to be given the option to do so.
>
>> I think that you should highlight this (and what private key corresponds
>> to E + h(E | s) * G, not sure it's trivial for everybody), probably a
>> way to get this more decentralized is to reward the escrows (what is the
>> interest here for people to run a smart contract platform?)
> I assumed both were obvious, but I suppose a few more words about those would not be amiss.
>
>> For lightning, maybe it's a question of wording, I consider it as a
>> sidechain AND methods that can be used by other sidechains, as well as
>> the others you quoted, even if only two people in the world use
>> lightning, it is still decentralized, because it sustains itself alone
> Again, I prefer precision in my terminology.
> For me, a sidechain is a blockchain of some sort.
> In particular, a kind of Merklized singly-linked list containing representations of transformations of state, is how I define blockchain to be.
>
> No such Merklized singly-linked list exists in Lightning Network, thus I do not consider it, "blockchain".
> And thus I do not consider it "sidechain", as a sidechain is a blockchain.
> Current LN does use "shachains" by Rusty, but shachains are not Merklized singly-linked lists, but are instead a kind of inverse mountain range structure.
>
> Still, one might consider both federated sidechains and Lightning Network to have a "federated" offchain structure.
> This is because the coins on the Bitcoin blockchain are locked to a multisignature and activity is not recorded on the Bitcoin blockchain.
> However, in LN, each channel is a 2-member federation (you and a counterparty) and the mechanism in LN requires consensus (2-of-2) rather than a quorum (m-of-n).
> This greatly increases the security of LN: the owner of funding on an LN channel can always refuse to sign an update if the other member of the federation is taken over.
> Compare this to the quorum that typical federations have, where takeover of a sufficient quorum is enough to steal funds from the remaining federation.
> https://zmnscpxj.github.io/offchain/safety.html
>
> Regards,
> ZmnSCPxj

Re: [bitcoin-dev] Smart Contracts Unchained

[Nadav Kohen]

[-- Attachment #1: Type: text/plain, Size: 5425 bytes --]

Hi all!

I've been thinking a lot about how to add the benefits that lightning
provides in terms of privacy and speed to the smart contracts unchained
setup. The high-level idea is to utilize the fact that a lightning channel
already has on-chain funds locked up, and if parties cooperate, some of
these funds can be moved into the 2/3 MultiSig output needed for the escrow
scheme by cooperating off-chain (and then moved back to their channel
balances off-chain as well). The following is an admittedly pretty rough
outline of how this might be accomplished.

A - B : Smart Contracts in a Lightning Channel

1) Parties both commit to a 2/3 MultiSig output on their next commitment
transaction
2) Parties then both revoke_and_ack
3) When the contract yields a result, the to_local and to_remote balances
can be updated and the 2/3 MultiSig output can be removed
4) If either party is uncooperative, their counter-party can force close
the channel and funds can be resolved on-chain using the escrow

If either party does not revoke_and_ack well before any potential for them
to discover if they have an advantage in the contract (or after some small
but reasonable time), their counter-party should go on chain with the
commitment transaction containing the 2/3 MultiSig

A - B - C : Single Hop Smart Contracts (Useful if someone, B in this case,
wants to provide a hub that matches users wanting to enter smart contracts)

1) A irrevocably commits to a 2/3 MultiSig output on their commitment
transaction with B (which B also commits to but does not yet revoke their
old state)
2) C irrevocably commits to the same 2/3 MultiSig output on their
commitment transaction with B (which B also commits to)
3) B irrevocably commits to both outputs
4) When the contract yields a result, say A should win some money from C,
then A can ask B to remove that output (and update balances) by revealing
to B how to claim funds from C
5) B can then ask C to remove the output and add to B's balance

If B does not revoke_and_ack on either channel, then the affected
counter-party should close the channel and go on chain with the 2/3
MultiSig transaction
If B refuses to remove the output, A can claim their funds on-chain where B
can learn how to claim funds from C
If C refuses to remove the output, B can claim their funds on-chain using
the information revealed by A

Problems: How do we ensure that only B can claim the 2/3 MultiSig from C,
and not anyone who sees A's on-chain spend of their 2/3 MultiSig? I'm
pretty sure this is possible to do but I don't know Script well enough

A - B - C - D : Fully Routed Smart Contracts

1) Given the n possible outcomes in which A gets money from the contract
between A and D, a_1 < a_2 < ... < a_n, and the m possible outcomes in
which D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with
the amounts a_1, a_2 - a_1, a_3 - a_2, ..., a_n - a_(n-1) and A must send m
HTLCs to D with amounts d_1, d_2 - d_1, d_3 - d_2, ..., d_m - d_(m-1)
2) These HTLCs must be special and have two hashes, where either preimage
unlocks the funds
3) In the payments from A to D, A knows one preimage and the smart
contracting platform knows the other (and similarly for D to A)
4) Should a_i be the outcome of the contract, D should tell A what the
preimages are to payments 1 through i
5) D should fail all m payments
6) A should fail all payments i+1 through n
(It is possible and in fact likely that there can be ways to use fewer
transactions and thus less collateral than this, perhaps by using
subtraction and not just addition as in a_i - d_j, what I've presented is
simply a lower bound that works in all cases)

If D does not reveal their preimages, A can get the relevant preimages from
the smart contracting platform

Problems: The smart contracting platform is given more information about
the contract in the happy path in this scheme. Also, all routers need to
support special double-hash HTLCs

An alternative way to possibly do multi-hop routing that would require less
be told to the escrow service, is to have each routing node add an output
on either side where it takes one position in one channel and the other
position in the other channel (essentially allowing them to break event
when the contract is completed). This has the same problems as the Single
Hop case as well as the additional problem (that I couldn't imagine a
solution for) of making the commitments to the 2/3 MultiSig output on
commitment transactions atomic; in the single hop case incentives seem to
work out but I don't know how "failed routing" would be detected or handled
in the multi-hop case.

Feedback welcome!

Best,
Nadav

On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the
> consensus rules of some blokchain.  Often this means creating a new
> blockchain, or at least a sidechain to an existing blockchain.  This
> writeup proposes an alternative method without launching a separate
> blockchain or sidechain, while achieving security similar to federated
> sidechains and additional benefits to privacy and smart-contract-patching.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6327 bytes --]

Re: [bitcoin-dev] Smart Contracts Unchained

[ZmnSCPxj]

Good morning Nadav,

Yes, transporting contracts over a single direct channel is always possible.

When Lightning switches to Decker-Russell-Osuntokun ("eltoo"), do note that contracts with an absolute timelock must be forced onchain earlier than the absolute timelock by the CSV requirement of the channel (unilateral close time).

With current Poon-Dryja channels, transported contracts must be augmented by a 2-of-2 on all branches, which can be done by adding a 2-of-2 multisig on the escrow branch, using temporary keys.
The purpose of the 2-of-2 is to enforce that the only valid claims to the contract have an `nSequence` representing the unilateral close time of the channel.
xref. HTLC-timeout and HTLC-success transactions in BOLT#3.

Transporting over multiple hops requires that compliance to a contract makes one side reveal information that the other side does not know, together with some kind of timeout/backoff.
Practically speaking, only HTLC-type contracts can be transported.
For example, DLCs will have many possible branches where the Oracle provides a signature for one branch, and this signature is what is learned by the other party in the contract.
In addition, DLCs for practical use require a timeout (in case the Oracle fails to reveal the signature on the appointed time).
Thus, far fewer contracts can be transported over the network.

(Of note is that a Lightning channel is itself a contract (that is transportable only within a direct channel); this is the basis of channel factories, where the factory level is effectively a "channel" with more than two participants, and transporting Lightning channels instead of HTLCs)
(You may be interested in looking at the "Fulgurite" effort)

OF note is that DLCs have an Oracle.
I observe that escrow services (which are specializations of the Smart Contracts Unchained technique) are basically oracles also.
If DLCs can transport their oracle signatures over multiple hops, then it should be possible for Smart Contracts Unchained to transport the federation/escrow signatures over multiple hops also.
I do not know the math behind DLCs enough to be certain, however, and leave it to better mathematicians than I.

Regards,
ZmnSCPxj

Regards,
ZmnSCPxj

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 18, 2019 12:17 AM, Nadav Kohen <nadav@suredbits.com> wrote:

> Hi all!
>
> I've been thinking a lot about how to add the benefits that lightning provides in terms of privacy and speed to the smart contracts unchained setup. The high-level idea is to utilize the fact that a lightning channel already has on-chain funds locked up, and if parties cooperate, some of these funds can be moved into the 2/3 MultiSig output needed for the escrow scheme by cooperating off-chain (and then moved back to their channel balances off-chain as well). The following is an admittedly pretty rough outline of how this might be accomplished.
>
> A - B : Smart Contracts in a Lightning Channel
>
> 1) Parties both commit to a 2/3 MultiSig output on their next commitment transaction
> 2) Parties then both revoke_and_ack
> 3) When the contract yields a result, the to_local and to_remote balances can be updated and the 2/3 MultiSig output can be removed
> 4) If either party is uncooperative, their counter-party can force close the channel and funds can be resolved on-chain using the escrow
>
> If either party does not revoke_and_ack well before any potential for them to discover if they have an advantage in the contract (or after some small but reasonable time), their counter-party should go on chain with the commitment transaction containing the 2/3 MultiSig
>
> A - B - C : Single Hop Smart Contracts (Useful if someone, B in this case, wants to provide a hub that matches users wanting to enter smart contracts)
>
> 1) A irrevocably commits to a 2/3 MultiSig output on their commitment transaction with B (which B also commits to but does not yet revoke their old state)
> 2) C irrevocably commits to the same 2/3 MultiSig output on their commitment transaction with B (which B also commits to)
> 3) B irrevocably commits to both outputs
> 4) When the contract yields a result, say A should win some money from C, then A can ask B to remove that output (and update balances) by revealing to B how to claim funds from C
> 5) B can then ask C to remove the output and add to B's balance
>
> If B does not revoke_and_ack on either channel, then the affected counter-party should close the channel and go on chain with the 2/3 MultiSig transaction
> If B refuses to remove the output, A can claim their funds on-chain where B can learn how to claim funds from C
> If C refuses to remove the output, B can claim their funds on-chain using the information revealed by A
>
> Problems: How do we ensure that only B can claim the 2/3 MultiSig from C, and not anyone who sees A's on-chain spend of their 2/3 MultiSig? I'm pretty sure this is possible to do but I don't know Script well enough
>
> A - B - C - D : Fully Routed Smart Contracts
>
> 1) Given the n possible outcomes in which A gets money from the contract between A and D, a_1 < a_2 < ... < a_n, and the m possible outcomes in which D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with the amounts a_1, a_2 - a_1, a_3 - a_2, ..., a_n - a_(n-1) and A must send m HTLCs to D with amounts d_1, d_2 - d_1, d_3 - d_2, ..., d_m - d_(m-1)
> 2) These HTLCs must be special and have two hashes, where either preimage unlocks the funds
> 3) In the payments from A to D, A knows one preimage and the smart contracting platform knows the other (and similarly for D to A)
> 4) Should a_i be the outcome of the contract, D should tell A what the preimages are to payments 1 through i
> 5) D should fail all m payments
> 6) A should fail all payments i+1 through n
> (It is possible and in fact likely that there can be ways to use fewer transactions and thus less collateral than this, perhaps by using subtraction and not just addition as in a_i - d_j, what I've presented is simply a lower bound that works in all cases)
>
> If D does not reveal their preimages, A can get the relevant preimages from the smart contracting platform
>
> Problems: The smart contracting platform is given more information about the contract in the happy path in this scheme. Also, all routers need to support special double-hash HTLCs
>
> An alternative way to possibly do multi-hop routing that would require less be told to the escrow service, is to have each routing node add an output on either side where it takes one position in one channel and the other position in the other channel (essentially allowing them to break event when the contract is completed). This has the same problems as the Single Hop case as well as the additional problem (that I couldn't imagine a solution for) of making the commitments to the 2/3 MultiSig output on commitment transactions atomic; in the single hop case incentives seem to work out but I don't know how "failed routing" would be detected or handled in the multi-hop case.
>
> Feedback welcome!
>
> Best,
> Nadav
>
> On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > https://zmnscpxj.github.io/bitcoin/unchained.html
> >
> > Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain.  Often this means creating a new blockchain, or at least a sidechain to an existing blockchain.  This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev