Re: [bitcoin-dev] Smart Contracts Unchained
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
Re: [bitcoin-dev] Smart Contracts Unchained
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 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
Re: [bitcoin-dev] Smart Contracts Unchained
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 ___ bitcoin-dev mailing list
Re: [bitcoin-dev] Smart Contracts Unchained
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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
Re: [bitcoin-dev] Smart Contracts Unchained
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
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 > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
