Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4ACED1906 for ; Thu, 4 Apr 2019 03:37:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE3D87F8 for ; Thu, 4 Apr 2019 03:37:50 +0000 (UTC) Received: by mail-pg1-f170.google.com with SMTP id v12so517025pgq.1 for ; Wed, 03 Apr 2019 20:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=in-reply-to:references:thread-topic:user-agent:mime-version :content-transfer-encoding:subject:from:date:to:message-id; bh=FmF6QQkdhLUVpup53ytQT9NLFWugw64Uc0Vp8y146rs=; b=M3AnGMEQaNWxljsQ9Y5bRzyRRD85CpXLwLLRPLiFquF1puCa3zqYRgCTKo4lKhMMgv shoDLmyamSPtEw+X4QvHf8fWtk1UB0FbOogmDUQ95vhU3qnpOVh3cpyPrmD8PqDbq+L6 CjqADzmpmWrpV4r61kF0164kiudBLFKjxyZbRQUeqc3YX2qC9pr8xJaTPoTXXTtevWFp wGZNaDzfYRNd2G4xuuLaslG0LycM3etnSGij4WlCmRh5+7ToY4ZQV/BJAQBkhXKtD1ZG gkXDF48o1uMd4f3uJJRuwM8CIISSKvD0QtXrHD7eWZH+MDB4omT3xn3Acm9E3gmJ2xmB zz2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:in-reply-to:references:thread-topic:user-agent :mime-version:content-transfer-encoding:subject:from:date:to :message-id; bh=FmF6QQkdhLUVpup53ytQT9NLFWugw64Uc0Vp8y146rs=; b=LAzYby5xbfwEFE5ElMT3/xzBcXlD6VTcwk7cYieMQVZ0NTdEv9UNyB+YjwzLqvSaVw hwqt2uFsVjwJ6IcLp+/mYXqUQaWngPcN7Q4TLsSNgIdusBV7sRw5SGTvw6ndDU2Veuer qNmngJAUFzoyI75j8Qes3woV0kT/LvDAYTc2wkYbi4kBmUSeX3zchnADncyma9ecnMq+ ahebhTGRgshdM2UoaYUMTEdmWgz3RPmG1wc0+xjryd5mfS0vc3ZR2+pkpsQGk/xCCmCG 0tDYDmFuEFHyn3UVYcmtT+YNgmkP656/mkre2Oh4YSJKH7E/6zOG9su3M4G4TIIG50/f mM2A== X-Gm-Message-State: APjAAAXyCKzBimbM/musQiAoGvEpDI5UvUiuuK1b1W4tD9E996ZJQXEL COxH17h2Sm6lZ40zlLioMsQ= X-Google-Smtp-Source: APXvYqyqSwI/90g50L5HFGEZl0zzXupfoSLvzgCYj0ACnhjWmiGCswoYyF29xrLRxKG8/oI4c55ptA== X-Received: by 2002:a62:4115:: with SMTP id o21mr3289094pfa.153.1554349069613; Wed, 03 Apr 2019 20:37:49 -0700 (PDT) Received: from [10.227.237.177] ([24.244.23.52]) by smtp.gmail.com with ESMTPSA id q10sm21373524pgh.93.2019.04.03.20.37.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 20:37:48 -0700 (PDT) In-Reply-To: References: X-Referenced-Uid: 18804 Thread-Topic: [bitcoin-dev] Smart Contracts Unchained X-Blue-Identity: !l=633&o=96429&fo=97631&pl=592&po=0&qs=PREFIX&f=HTML&n=Ariel%20Lorenzo-Luaces&e=arielluaces%40gmail.com&m=!%3AZjEwN2MyYjMtOWE0OC00NzJhLWEzYTQtYjc3MTEzNTNhODJm%3ASU5CT1g%3D%3AMTg4MDQ%3D%3AANSWERED&p=563&q=SHOW User-Agent: Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----S4AOSF8H4KWEK2CJSK9R4OU7L84FJY" Content-Transfer-Encoding: 7bit X-Local-Message-Id: <77b8f255-8f70-431e-839c-b99361d1dac7@gmail.com> From: Ariel Lorenzo-Luaces Date: Wed, 03 Apr 2019 20:37:47 -0700 To: ZmnSCPxj ,bitcoin-dev@lists.linuxfoundation.org Message-ID: <77b8f255-8f70-431e-839c-b99361d1dac7@gmail.com> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, URI_NOVOWEL autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 04 Apr 2019 05:05:48 +0000 Subject: Re: [bitcoin-dev] Smart Contracts Unchained X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 03:37:51 -0000 ------S4AOSF8H4KWEK2CJSK9R4OU7L84FJY Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hello ZmnSCPxj I like the proposal because it generalizes escrow type mech= anisms and I think it's a useful train of thought for distributed exchanges= =2E However, consider the situation where a group of participants are play= ing poker=2E One participant loses all their funds and decides to present t= o the escrow the contract+an old contract state+a signed message following = the contract rules (eg=2E an independently signed cashing out message)=2E H= ow would the escrow know that the contract state is old and the operation i= s disallowed, without using a consensus mechanism like a blockchain? Cheer= s Ariel Lorenzo-Luaces On Apr 3, 2019, 7:14 PM, at 7:14 PM, ZmnSCPxj via b= itcoin-dev wrote: >https://zmns= cpxj=2Egithub=2Eio/bitcoin/unchained=2Ehtml > >Smart contracts have traditi= onally been implemented as part of the >consensus rules of some blokchain= =2E Often this means creating a new >blockchain, or at least a sidechain t= o an existing blockchain=2E This >writeup proposes an alternative method w= ithout launching a separate >blockchain or sidechain, while achieving secur= ity similar to federated >sidechains and additional benefits to privacy and= >smart-contract-patching=2E >_____________________________________________= __ >bitcoin-dev mailing list >bitcoin-dev@lists=2Elinuxfoundation=2Eorg >ht= tps://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev ------S4AOSF8H4KWEK2CJSK9R4OU7L84FJY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello ZmnSCPxj

I like the proposal because it generalizes escrow type mecha= nisms and I think it's a useful train of thought for distributed exchanges= =2E

However, consider the situation where a= group of participants are playing poker=2E One participant loses all their= funds and decides to present to the escrow the contract+an old contract st= ate+a signed message following the contract rules (eg=2E an independently s= igned cashing out message)=2E How would the escrow know that the contract s= tate is old and the operation is disallowed, without using a consensus mech= anism like a blockchain?

Cheers
<= div dir=3D"auto">Ariel Lorenzo-Luaces
On = Apr 3, 2019, at 7:14 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists= =2Elinuxfoundation=2Eorg> wrote:
https://zmnscpxj=2Egithub=2Eio/bitcoi=
n/unchained=2Ehtml

Smart contracts have traditionally been imple= mented as part of the consensus rules of some blokchain=2E Often this mean= s creating a new blockchain, or at least a sidechain to an existing blockch= ain=2E This writeup proposes an alternative method without launching a sep= arate blockchain or sidechain, while achieving security similar to federate= d sidechains and additional benefits to privacy and smart-contract-patching= =2E


bitcoin-dev mailing list
bitcoin-dev@lists=2Elinuxfoundat= ion=2Eorg
https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bit= coin-dev
------S4AOSF8H4KWEK2CJSK9R4OU7L84FJY--