From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 72E551045 for ; Thu, 18 Apr 2019 05:33:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30958466 for ; Thu, 18 Apr 2019 05:33:49 +0000 (UTC) Date: Thu, 18 Apr 2019 05:33:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1555565626; bh=okBidcCJ37mrTiFBoU3OSH1Uhpf3zJhciNV5BE4woA0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=FsnS28lP3LWMKpeyGV8oBTbRNpHTsEZkwuJ7ceIGvxYW3IHFf7wFrRGStdI+ZZjM3 8akGad2sFY6ae09LUX4ZU0IfaXDscvv4adJn/zuQdaHv78vQiYx8oGPY1xc5UL9N+p prllc3DCRzGxOdir4ODwu9lgN43fBjJM5iPk3+u4= To: Nadav Kohen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW, 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, 18 Apr 2019 13:40:07 +0000 Cc: Bitcoin Protocol Discussion 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, 18 Apr 2019 05:33:50 -0000 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 th= e absolute timelock by the CSV requirement of the channel (unilateral close= time). With current Poon-Dryja channels, transported contracts must be augmented b= y a 2-of-2 on all branches, which can be done by adding a 2-of-2 multisig o= n the escrow branch, using temporary keys. The purpose of the 2-of-2 is to enforce that the only valid claims to the c= ontract have an `nSequence` representing the unilateral close time of the c= hannel. xref. HTLC-timeout and HTLC-success transactions in BOLT#3. Transporting over multiple hops requires that compliance to a contract make= s one side reveal information that the other side does not know, together w= ith 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 provide= s 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 f= ails 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 transpor= table only within a direct channel); this is the basis of channel factories= , where the factory level is effectively a "channel" with more than two par= ticipants, 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 Cont= racts Unchained technique) are basically oracles also. If DLCs can transport their oracle signatures over multiple hops, then it s= hould 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 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, April 18, 2019 12:17 AM, Nadav Kohen wro= te: > Hi all! > > I've been thinking a lot about how to add the benefits that lightning pro= vides 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 alread= y has on-chain funds locked up, and if parties cooperate, some of these fun= ds can be moved into the 2/3 MultiSig output needed for the escrow scheme b= y 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 the= m to discover if they have an advantage in the contract (or after some smal= l but reasonable time), their counter-party should go on chain with the com= mitment 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 contract= s) > > 1) A irrevocably commits to a 2/3 MultiSig output on their commitment tra= nsaction 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 commitm= ent 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 trans= action > 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 pret= ty 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 whic= h D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with the am= ounts 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 contra= cting 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 pr= eimages 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 tr= ansactions 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 low= er bound that works in all cases) > > If D does not reveal their preimages, A can get the relevant preimages fr= om 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 su= pport special double-hash HTLCs > > An alternative way to possibly do multi-hop routing that would require le= ss be told to the escrow service, is to have each routing node add an outpu= t on either side where it takes one position in one channel and the other p= osition in the other channel (essentially allowing them to break event when= the contract is completed). This has the same problems as the Single Hop c= ase as well as the additional problem (that I couldn't imagine a solution f= or) of making the commitments to the 2/3 MultiSig output on commitment tran= sactions atomic; in the single hop case incentives seem to work out but I d= on't know how "failed routing" would be detected or handled in the multi-ho= p case. > > Feedback welcome! > > Best, > Nadav > > On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev wrote: > > > https://zmnscpxj.github.io/bitcoin/unchained.html > > > > Smart contracts have traditionally been implemented as part of the cons= ensus rules of some blokchain.=C2=A0 Often this means creating a new blockc= hain, or at least a sidechain to an existing blockchain.=C2=A0 This writeup= proposes an alternative method without launching a separate blockchain or = sidechain, while achieving security similar to federated sidechains and add= itional benefits to privacy and smart-contract-patching. > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev