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 22315A55; Tue, 10 Sep 2019 01:28:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BBF2A76F; Tue, 10 Sep 2019 01:28:11 +0000 (UTC) Date: Tue, 10 Sep 2019 01:28:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568078889; bh=+xNy5BbgDCQgnDUoPhAZ/ODMmkHX0zXvQnDneF0adlc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=t4HEksokB5BG442rG550/oiLXH6Y/vdel+LwrmkMwVp4gBS1G8w20051kx8Wn6PRB oWN/C3zB0Qhx76izPtcv4aE6Hg2EOD2TTvUeCA7luv4doiWgxA62iszUJtMVPJc0Dt qYVGDJFbx31oBmmQYzzMYqdFHOGgz9gZSdLEc9xM= To: Richard Myers From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <87mufhva0k.fsf@gmail.com> 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=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion , "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo 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: Tue, 10 Sep 2019 01:28:13 -0000 Good morning Richard, > I believe using the eltoo update scheme as a way to consolidate blocks of= off-chain transactions is an interesting idea worth exploring.=C2=A0=C2= =A0 > > ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo= . Although using CSV is more complicated and outputs must also use SIGHASH_= NOINPUT [1], the ability to have multiple party channels and the most used = types of scripts makes eltoo compelling compared to LN-Penalty for this kin= d of application. I broadly agree. I imagine a future where most people do not typically have single-signer ow= nership of coins onchain, but are instead share-owners of coins, with singl= e-signer ownership occurring onchain only in the case of dispute or for lon= g-term cold storage. > > The multiple party aspect in particular introduces an interesting way to = unify concepts from different second layer protocols like federated sidecha= ins and statechains (ht.=C2=A0aakselrod [2]). > > Though the Statechains proposal relies on eltoo [3], I think what Christi= an suggested does not try to solve the dynamic membership problem. That's w= hy I think of this as more an evolution of the channel factory paper toward= s something like a federated sidechain. > > > I think this reconciliation between the off-chain model and the on-chai= n > > model, with many concepts cleanly mapping from one context to another > > (state outputs =3D UTXO, off-chain update =3D on-chain transactions, > > cut-through =3D confirmation, operation batching =3D block creation) is > > rather nice :-) > > One additional concept that could be new to this off-chain blockchain mod= el would be something like batched multi-party loop-in/out. In a Schnorr/Ta= proot world you could add signers/inputs and remove signers/outputs with a = single multi-signature negotiated off-chain. You'd still like to limit thes= e onchain txs, even if they are small, but updating channels periodically s= eems like a straight forward way to address the dynamic membership problem. Indeed. Such a change-in-membership transaction would be a 1-input 1-output transac= tion, and with use of n-of-n MuSig would be as small (and as private, modul= o the fact that you are coordinating this with a bunch of other participant= s) as a single-sig user making a 1-input 1-output transaction (which genera= lly is not very private because such transactions are usually "send-to-self= " and changing membership generally means ownership does not actually chang= e much). The cost of this transaction would be small (certainly smaller than the upd= ate+state transactions needed in Decker-Russell-Osuntokun) For setting this up, it might be useful to have the below ritual. This assumes only a change in the membership set is desired, without a simu= ltaneous change in the UTXO set. 1. Create a new update+state transaction for the current Decker-Russell-Os= untokun mechanism. The state transaction pays out to a single output paying to the new mem= bership set rather than the current UTXO set of the mechanism. Do *not* sign this yet. Call this the "final" update+state transaction. 2. Create a new Decker-Russell-Osuntokun mechanism initial update+state tr= ansaction. This pays out to the current UTXO set of the previous mechanism. This will spend from the new membership set. Completely sign these transactions. * The update transaction can spend the above "final" transaction, as it= is `SIGHASH_NOINPUT`. 3. Sign the final update+state transaction of the previous Decker-Russell-= Osuntokun mechanism. Do *not* broadcast the update+state transaction yet. 4. Create and sign the membership-change onchain transaction. This spends the current onchain funding transaction output and outputs = to the same new membership set. Broadcast this onchain. The above ritual ensures that, after step 3 completes, the mechanism can co= ntinue operating without waiting for onchain activity to complete. It ensures that, even if the membership-change onchain transaction becomes = invalid later (by somebody bribing a miner to publish a previous update tra= nsaction from the older membership set), we will still enter an update that= will eventually put the new membership set onchain. This reduces the critical path to only steps 1 to 3, and we can continue op= erating with the new membership set as soon as step 3 completes and we do n= ot need to wait for the membership-change transaction to be deeply-confirme= d in order to use the new membership set mechanism. However, it has the drawback that, until the membership-change onchain tran= saction is deeply-confirmed onchain, the CSV parameter is temporarily doubl= ed (as there is the possibility that the previous mechanism is closed). Also, the mechanism cannot be mutually closed until the membership-change o= nchain transaction is deeply-confirmed, as there is no stable txid we can s= pend from (we would strongly prefer to use `SIGHASH_ALL` for cooperative cl= oses to improve our privacy). > > I guess this all gets back to how to design an off-chain protocol for man= aging these negotiations. Ultimately I can imagine a sort of multi-party el= too based 'signet' with the same RPC interface, but different transaction v= alidation and block creation logic.=C2=A0 Perhaps there would be a new mess= age where the channel parties would add their signature before forwarding a= valid block, and the block wouldn't be built on until all parties had sign= ed. The "block" that would need to be signed by the participants would actually= be a Decker-Russell-Osuntokun update+state transaction, and would commit t= o the UTXO set rather than the transaction set. Unless I misunderstand your meaning here. Regards, ZmnSCPxj