diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-09-19 02:01:54 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-09-19 02:02:04 +0000 |
| commit | 8789329e5b334a5356b8a954da0cc98d16226f35 (patch) | |
| tree | 41d3632cbb12213267efdbfe1e20ce697c83cb42 | |
| parent | 2bf7a824c40da4fc774efe0a0d88873d44f1ddad (diff) | |
| download | pi-bitcoindev-8789329e5b334a5356b8a954da0cc98d16226f35.tar.gz pi-bitcoindev-8789329e5b334a5356b8a954da0cc98d16226f35.zip | |
Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo
| -rw-r--r-- | 0c/fbfb62475357bfef5b0574b13a9d40f8d771d0 | 265 |
1 files changed, 265 insertions, 0 deletions
diff --git a/0c/fbfb62475357bfef5b0574b13a9d40f8d771d0 b/0c/fbfb62475357bfef5b0574b13a9d40f8d771d0 new file mode 100644 index 000000000..d40423ad3 --- /dev/null +++ b/0c/fbfb62475357bfef5b0574b13a9d40f8d771d0 @@ -0,0 +1,265 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 06D77104F + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <decker.christian@gmail.com> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com> +In-Reply-To: <87ef0doh0w.fsf@gmail.com> +References: <87mufhva0k.fsf@gmail.com> + <G_LSM42y_gQFNVrTfHHN5hqR_foZU6AlOJkfz9zMDLFyQGdk4opZ14QC97w2rjrw4UmWTwEkJDKEc_eUMItdmxEsQOl7S-gBO2y8ovFPBc0=@protonmail.com> + <CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com> + <RQVxRFj-yzhYfEPMZhVrSYCaEvFhRrlxkSI-sYmqwEE7bRO6hKPV-vdB2ijcFYND-2x_5esnr7aofW6-74B3mHFLiLlHm-FM4WPeiJo-GhQ=@protonmail.com> + <CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com> + <ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.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 <bitcoin-dev@lists.linuxfoundation.org>, + "lightning-dev\\@lists.linuxfoundation.org" + <lightning-dev@lists.linuxfoundation.org>, Richard Myers <rich@gotenna.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |