public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Smart Contracts Unchained
@ 2019-04-04  1:55 ZmnSCPxj
  2019-04-04  2:35 ` Tamas Blummer
                   ` (5 more replies)
  0 siblings, 6 replies; 13+ messages in thread
From: ZmnSCPxj @ 2019-04-04  1:55 UTC (permalink / raw)
  To: bitcoin-dev

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.


^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: [bitcoin-dev] Smart Contracts Unchained
    2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
  @ 2019-04-04  2:35 ` Tamas Blummer
    2019-04-04  3:37 ` Ariel Lorenzo-Luaces
                     ` (4 subsequent siblings)
    5 siblings, 0 replies; 13+ messages in thread
  From: Tamas Blummer @ 2019-04-04  2:35 UTC (permalink / raw)
    To: ZmnSCPxj, Bitcoin Protocol Discussion
  
  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
  
  
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: [bitcoin-dev] Smart Contracts Unchained
    2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
    2019-04-04  2:35 ` Tamas Blummer
  @ 2019-04-04  3:37 ` Ariel Lorenzo-Luaces
    2019-04-04  7:07   ` ZmnSCPxj
    2019-04-04 15:03 ` ZmnSCPxj
                     ` (3 subsequent siblings)
    5 siblings, 1 reply; 13+ messages in thread
  From: Ariel Lorenzo-Luaces @ 2019-04-04  3:37 UTC (permalink / raw)
    To: ZmnSCPxj, bitcoin-dev
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• • * Re: [bitcoin-dev] Smart Contracts Unchained
      2019-04-04  3:37 ` Ariel Lorenzo-Luaces
    @ 2019-04-04  7:07   ` ZmnSCPxj
      0 siblings, 0 replies; 13+ messages in thread
    From: ZmnSCPxj @ 2019-04-04  7:07 UTC (permalink / raw)
      To: Ariel Lorenzo-Luaces; +Cc: bitcoin-dev
    
    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
    
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: [bitcoin-dev] Smart Contracts Unchained
    2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
    2019-04-04  2:35 ` Tamas Blummer
    2019-04-04  3:37 ` Ariel Lorenzo-Luaces
  @ 2019-04-04 15:03 ` ZmnSCPxj
    2019-04-04 17:18 ` Aymeric Vitte
                     ` (2 subsequent siblings)
    5 siblings, 0 replies; 13+ messages in thread
  From: ZmnSCPxj @ 2019-04-04 15:03 UTC (permalink / raw)
    To: ZmnSCPxj, Bitcoin Protocol Discussion
  
  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
  
  
  
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: [bitcoin-dev] Smart Contracts Unchained
    2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
                     ` (2 preceding siblings ...)
    2019-04-04 15:03 ` ZmnSCPxj
  @ 2019-04-04 17:18 ` Aymeric Vitte
    2019-04-04 23:52   ` ZmnSCPxj
    2019-04-05  6:00 ` ZmnSCPxj
    2019-04-17 16:17 ` Nadav Kohen
    5 siblings, 1 reply; 13+ messages in thread
  From: Aymeric Vitte @ 2019-04-04 17:18 UTC (permalink / raw)
    To: ZmnSCPxj, Bitcoin Protocol Discussion
  
  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
  
  
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• • * Re: [bitcoin-dev] Smart Contracts Unchained
      2019-04-04 17:18 ` Aymeric Vitte
    @ 2019-04-04 23:52   ` ZmnSCPxj
      2019-04-05 17:46     ` Aymeric Vitte
      0 siblings, 1 reply; 13+ messages in thread
    From: ZmnSCPxj @ 2019-04-04 23:52 UTC (permalink / raw)
      To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion
    
    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
    
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • • * Re: [bitcoin-dev] Smart Contracts Unchained
        2019-04-04 23:52   ` ZmnSCPxj
      @ 2019-04-05 17:46     ` Aymeric Vitte
        2019-04-08 10:45       ` ZmnSCPxj
        0 siblings, 1 reply; 13+ messages in thread
      From: Aymeric Vitte @ 2019-04-05 17:46 UTC (permalink / raw)
        To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
      
      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
      
      
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • • * Re: [bitcoin-dev] Smart Contracts Unchained
          2019-04-05 17:46     ` Aymeric Vitte
        @ 2019-04-08 10:45       ` ZmnSCPxj
          2019-04-08 16:28         ` Aymeric Vitte
          0 siblings, 1 reply; 13+ messages in thread
        From: ZmnSCPxj @ 2019-04-08 10:45 UTC (permalink / raw)
          To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion
        
        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
        
        
        ^ permalink raw reply	[flat|nested] 13+ messages in thread

      • • * Re: [bitcoin-dev] Smart Contracts Unchained
            2019-04-08 10:45       ` ZmnSCPxj
          @ 2019-04-08 16:28         ` Aymeric Vitte
            0 siblings, 0 replies; 13+ messages in thread
          From: Aymeric Vitte @ 2019-04-08 16:28 UTC (permalink / raw)
            To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
          
          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
          
          
          
          ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: [bitcoin-dev] Smart Contracts Unchained
    2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
                     ` (3 preceding siblings ...)
    2019-04-04 17:18 ` Aymeric Vitte
  @ 2019-04-05  6:00 ` ZmnSCPxj
    2019-04-17 16:17 ` Nadav Kohen
    5 siblings, 0 replies; 13+ messages in thread
  From: ZmnSCPxj @ 2019-04-05  6:00 UTC (permalink / raw)
    To: ZmnSCPxj, Bitcoin Protocol Discussion
  
  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
  
  
  
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• * Re: [bitcoin-dev] Smart Contracts Unchained
    2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
                     ` (4 preceding siblings ...)
    2019-04-05  6:00 ` ZmnSCPxj
  @ 2019-04-17 16:17 ` Nadav Kohen
    2019-04-18  5:33   ` ZmnSCPxj
    5 siblings, 1 reply; 13+ messages in thread
  From: Nadav Kohen @ 2019-04-17 16:17 UTC (permalink / raw)
    To: ZmnSCPxj, Bitcoin Protocol Discussion
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• • * Re: [bitcoin-dev] Smart Contracts Unchained
      2019-04-17 16:17 ` Nadav Kohen
    @ 2019-04-18  5:33   ` ZmnSCPxj
      0 siblings, 0 replies; 13+ messages in thread
    From: ZmnSCPxj @ 2019-04-18  5:33 UTC (permalink / raw)
      To: Nadav Kohen; +Cc: Bitcoin Protocol Discussion
    
    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
    
    
    
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-04-18  5:33 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-04  1:55 [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj
2019-04-04  2:35 ` Tamas Blummer
2019-04-04  3:37 ` Ariel Lorenzo-Luaces
2019-04-04  7:07   ` ZmnSCPxj
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox