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 637CBCA5 for ; Wed, 18 Sep 2019 05:28:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A39F76D for ; Wed, 18 Sep 2019 05:28:45 +0000 (UTC) Date: Wed, 18 Sep 2019 05:28:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568784522; bh=HvgFn5bfTTMPMKVmrBnHFj4E2IZKTzNwlgcpsQU/0Rg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Cx1mm15Tobu4iF/N2TodnW1iSzzJ/OM1l9rv4x9dwhp5PFrhHQeYNHtxXMuNGtW8y s/KYDS8TZuWRqN3e5o3FcabvZY/XoUykMe2jR02ZU07uEHA56x+2t6IOhVF9IepmD8 f3V5ubAFBBgBsUiksw4onaIwZcfOwf0fEL6hoMU8= 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: Wed, 18 Sep 2019 05:28:47 -0000 Good morning Richards, and list, > Thanks for the feedback ZmnSCPxj. > > > I imagine a future where most people do not typically have single-signe= r ownership of coins onchain, but are instead share-owners of coins, with s= ingle-signer ownership occurring onchain only in the case of dispute or for= long-term cold storage. > > The change-in-membership ritual you describe seems like a good start for = elaborating on this idea.=C2=A0 > > Some aspects of multi-party Decker-Russell-Osuntokun channels have analog= s to a signet blockchain that use a n-of-n federation of signers. But other= places, like change-in-membership, do not have direct analogs. > > For example, some signet concepts with multi-party channel analogs: > > block script: > * the first 'update' and 'settle' transactions, aka 'setup' and 'refund' = transactions, define the set of signers that must sign subsequent channel u= pdates > > genesis block: > * the initial 'funding' transaction, aka outpoint of the commitment trans= action, which establishes the funded channel > > utxo set: > * the specific set of on-chain outputs from the 'settlement' transaction = that spends the balance of the latest 'update' transaction signed by the co= mplete set of channel parties. > > mempool: > * the set of proposals for specific changes to the set of outputs from th= e latest 'settlement' transaction (similar to update_add_htlc, update_fail_= htlc, etc) > > Concepts where layer two channels do not have an obvious analog to a laye= r one signet blockchain: > > cooperative close: > * when all parties mutually agree to close the channel > * close the channel with a layer one transaction which finalizes the outp= uts from the most recent channel output state > * should be optimized for privacy and low on-chain fees Of note is that a close of an update mechanism does not require the close o= f any hosted update mechanisms, or more prosaically, "close of channel fact= ory does not require close of hosted channels". This is true for both unilateral and cooperative closes. Of course, the most likely reason you want to unilaterally close an outer m= echanism is if you have some contract in some deeply-nested mechanism that = will absolute-locktime expire "soon", in which case you have to close every= thing that hosts it. But for example if a channel factory has channels A B C and only A has an H= TLC that will expire soon, while the factory and A have to close, B and C c= an continue operation, even almost as if nothing happened to A. > > membership change (ZmnSCPxj ritual): > * when channel parties want to leave or add new members to the channel > * close and reopen a new channel via something like a channel splicing tr= ansaction to the layer one blockchain > * should be optimized for privacy and low on-chain fees paid for by parti= es entering and leaving the channel Assuming you mean that any owned funds will eventually have to be claimed o= nchain, I suppose this is doable as splice-out. But note that currently we have some issues with splice-in. As far as I can tell (perhaps Lisa Neigut can correct me, I believe she is = working on this), splice-in has the below tradeoffs: 1. Option 1: splice-in is async (other updates can continue after all part= icipants have sent the needed signatures for the splice-in). Drawback is that spliced-in funds need to be placed in a temporary n-of= -n, meaning at least one additional tx. 2. Option 2: splice-in is efficient (only the splice-in tx appears onchain= ). Drawback is that subsequent updates can only occur after the splice-in = tx is deeply confirmed. * This can be mitigated somewhat by maintaining a pre-splice-in and pos= t-splice-in mechanism, until the splice-in tx is deeply confirmed, after wh= ich the pre-splice-in version is discarded. Updates need to be done on *both* mechanisms until then, and any intr= oduced money is "unuseable" anyway until the splice-in tx confirms deeply s= ince it would not exist in the pre-splice-in mechanism yet. But perhaps a more interesting thing (and more in keeping with my sentiment= "a future where most people do not typically have single-signer ownership = of coins onchain") would be to transfer funds from one multiparticipant off= chain mechanism to another multiparticipant offchain, by publishing a singl= e transaction onchain. It may be doable via some extension of my proposed ritual for changing memb= ership set. > > balance change (similar to membership change): > * when channel parties want to add or remove some of the finalized value = in the channel > * close and reopen a new channel via something like a channel splicing tr= ansaction to the layer one blockchain > * should be optimized for privacy and low on-chain fees paid for by parti= es adding and removing value from the channel > > uncooperative close: > * when one or more nodes fails to sign the next channel state update > * use a layer one transaction to commit both finalized and un-finalized o= utputs from the most recent channel output state > * script timeouts determine when channel parties should uncooperatively c= lose the channel if not all parties have signed the next 'update' and 'sett= lement' transaction > > uncooperative membership change: > * a subset of channel parties might want to cooperatively sign a channel = splicing transaction to 'splice out' uncooperative parties I believe this is currently considered unsafe. https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001975= .html Unless you refer to another mechanism...? I believe this will end up requiring deep confirmation of the uncooperative= close followed by a new mechanism open. > > mining, mining reward and difficulty adjustment > * no equivalent concept for multi-party channels Fees for each update. Consider how HTLC routing in Lightning implicitly pays forwarding nodes to = cooperate with the forwarding. I imagine most nodes in a multiparticipant offchain system will want to be = paid for cooperation, even if just a nominal sub-satoshi amount. > > transaction fees: > * updates to layer two channels do not incur transactions fees > * invalid updates dropped to layer one should be paid by cheating node > * splice in/out transactions should be paid by requesting signers only > * do transaction fees prevent 'griefing' attacks? > > privacy: > * disassociate a particular update from signer(s) > * disassociate IP address of signers from signature > * using SIGHASH_ALL for cooperative closes I suppose Tor can be used to disassociate IP address from signers if everyo= ne is from a hidden service. However, we need to include some kind of mix mechanism to allow individual = signers to disassociate their ownership of funds from their identity as sig= ners. Though such mechanisms already exist as theoretical constructs, so "just ne= eds implementing". But then again: if you own funds in the mechanism, you *should* be a signer= (else you are trusting a federation). So a basic fact here is that if you are a participant in some offchain mech= anism, you are likely (approaching 100% probability) to own money in it. > > liveness: > * if signers know they will be offline, can they pre-sign updates that ju= st commit their own outputs, rather then splice out? > * contingent tap-leafs to splice out non-responsive signers It might be possible to create a new mechanism-within-mechanism layer, if a= signer knows they will be offline. For example, suppose entities A, B, and C have an offchain update mechanism= , which we shall call a "factory". Suppose this factory contains an A-B channel, a B-C channel, a A-C channel,= and some funds owned by B only. Then suppose A knows he or she will be offline for some time. Before A goes offline, they can move from this UTXO set: * A-B channel * B-C channel * A-C channel * B funds To this UTXO set: * A-B channel * A-C channel * B-C offchain update mechanism (sub-factory), which itself has its own UTX= O set: * B-C channel * B funds This allows B and C to manage the B-C channels and B funds without cooperat= ion of A. Then, later, when A returns online, the B-C offchain update mechanism is co= llapsed back to the parent A-B-C offchain update mechanism. This assumes A knows it will be offline (which it might do for e.g. regular= maintenance, or software updates). Regards, ZmnSCPxj