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 06D77104F for ; Thu, 19 Sep 2019 02:02:04 +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 CA1B48A6 for ; Thu, 19 Sep 2019 02:02:01 +0000 (UTC) Date: Thu, 19 Sep 2019 02:01:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568858518; bh=Rf9J0A+E7/JbCsBkcrIFmsdCT0+wUI+TMxwwCY6WEYs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=hu4Xe7IN1zOgqxPb0Igj0eIJLtE317Duue2IZtAMvXues2fYGaTfQ57SIwRU9CglW Lziw8yV06aH76m7eMT4kEh0wvQxjRw49W41ScJwaSQttivBHyZ8gFjZf/vVcM+nubW zzF53j242Bfflc6RvZ0Kj01OKxvbT8mBchyhArUU= To: Christian Decker From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com> In-Reply-To: <87ef0doh0w.fsf@gmail.com> References: <87mufhva0k.fsf@gmail.com> <87ef0doh0w.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" , Richard Myers 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: Thu, 19 Sep 2019 02:02:04 -0000 Good morning Christian, and list, > > > uncooperative membership change: > > > > > > - a subset of channel parties might want to cooperatively sign a ch= annel splicing transaction to 'splice out' uncooperative parties > > > > I believe this is currently considered unsafe. > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/00= 1975.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. > > Not necessarily. If we have an escape hatch in the scripts that allows > to spend any output attached to the settlement transaction by n-1 > participants we could reclaim these into a new open right away. This would have to be very very carefully designed. The entire point of requiring an n-of-n signature is: * By using an n-of-n signatory where *you* are a signer, you are completely= immune to Sybil attacks: even if everybody other than *you* in the signato= ry set is secretly just one entity, this is no different from doing a 2-of-= 2 bog-standard boring sleepy Zzzzzz Poon-Dryja Lightning Network channel. * Any m-of-n signatory where strictly m < n allows anybody with the abili= ty to run m nodes to outright steal money from you. * As processing power is cheap nowadays, there is no m that can be cons= idered safe. Your alternative is to fall back on proof-of-work, but that just mean= s going onchain, so you might as well just do things onchain. * This is why 2-of-2 channels work so well, it's the minimum useable cons= truction and any multiparty construction, when Sybilled, devolves to a 2-of= -2 channel. So the n-1 participants would have to be very very very carefully limited i= n what they can do. And if the only "right" the n-1 participants can do is to force the nth par= ticipant to claim its funds onchain, then that is implementable with a tran= saction doing just that, which is pre-signed by the nth participant and giv= en to participants 1..n-1. > > > 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. > > If we allow generic contracts on top of the base update mechanism it'll > be rather difficult to identify the beneficiary of an update, so it's > hard to know who should pay a fee. I'd rather argue that cooperating is > in the interest of all participants since they'd eventually want to > create an update of their own, and there is no upside to become > unresponsive. > > Notice that the fees we leverage in LN are because we expose our funds > to the risk of not being available by allocating them to an HTLC, not > for the updates themselves. Since in the forwarding scenario we're only > exposing the funds of the forwarding nodes to this risk it's only > natural that they'd be the ones leveraging a fee, not the other > participants that simply sign off on the change. I suppose that could be argued. However, I imagine it is possible for some of the updates to be implementab= le via HTLCs within sub-mechanisms of the higher mechanism. If so, a participant may refuse to sign for the higher mechanism in order t= o force others to use HTLCs on the lower mechanisms, and thereby earn fees = due to HTLC usage. I believe I argue as much here: https://lists.linuxfoundation.org/pipermail= /lightning-dev/2019-July/002055.html > ZmnSCPxj can request a factory channel reorganization to move some funds = from the ZmnSCPxj<->Rene channel to the ZmnSCPxj<->YAijbOJA channel. > This has the same effect, i.e. it allows a forwarding attempt to push thr= ough, that would not be possible without the factory-level channel reorgani= zation. > > Further, assuming only ZmnSCPxj, YAijbOJA, and Rene are in the channel fa= ctory, then it is the same: all three need to be online in order for the JI= T-routing to work. > > But I observed above that, in a channel rebalance using current channels = (without factories) Rene cannot be convinced to waive the fee. The counterargument above is that if rebalances can be made fee-free, then = the above argument disappears. > > > > 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 > > everyone 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 signers. Though such > > mechanisms already exist as theoretical constructs, so "just needs > > 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 mechanism, you are > > likely (approaching 100% probability) to own money in it. > > Notice that we are negotiating whether or not to apply generic > transactions to a shared state. This also means that there is no direct > relationship between the ownership of an output and the ID signing off > on a change. > > The privacy guarantees are identical to Bitcoin on-chain, with the one > caveat that we may identify the proposing participant, but we can defend > against this by mixing as you propose. Yes, but if we later combine this with allowing multiilateral kick-out of a= member that is unresponsive (i.e. we splice out the outputs it has at leas= t partial ownership of, and keep only those that are owned only by the rema= ining members), then each member would have to honestly claim which UTXOs i= t is interested in keeping after it is kicked out of the membership set, de= feating this point entirely. I believe this is roughly what you propose in the next point, and roughly w= hat you would want with the "n-1 participants" earlier. > > > > liveness: > > > > > > - if signers know they will be offline, can they pre-sign updates t= hat just 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 o= wn UTXO set: > > - B-C channel > > - B funds > > > > This allows B and C to manage the B-C channels and B funds without > > cooperation of A. Then, later, when A returns online, the B-C > > offchain update mechanism is collapsed 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). > > We could theoretically play this game, having each participant create > two updates with the same state-number at each update: > > 1. A normal one that just keeps them in the contract > 2. A fallback splice all outputs they own (direct ones, HTLCs, ...) and > putting the rest back into a channel without them. > > In case of one user becoming inactive the others can sign the splice, > dropping the inactive participant and continue like nothing > happened. The worst case scenario is that the normal update gets > broadcast and confirmed instead, which means we are back to the > unilateral close that we'd have to do anyway without this mechanism. > > Notice however that this only works if participants drop off one by o= ne, > otherwise we get a combinatorial explosion for the fallback cases whe= re > each combination of inactive participants needs to splice themselves > out. It also adds the complexity of having to identify which particip= ant > is the co-owner of an output, otherwise I can claim ownership of an > unrelated output and force that to move on-chain by including it in m= y > fallback and then becoming unresponsive (added rounds of communicatio= n > can help here, but are cumbersome). This might be a plausible way of implementing the "n-1 participants can kic= k out nth participant". > > It may be a bit much added complexity for a small complexity to be > honest, hopefully this won't be needed too often :-) Statement makes no sense, unless you meant to say "It may be a bit much com= plexity for a small benefit" or similar? Regards, ZmnSCPxj