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 66D9FCC4; Wed, 18 Sep 2019 13:45:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2118711; Wed, 18 Sep 2019 13:45:00 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id a23so35689edv.5; Wed, 18 Sep 2019 06:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Scu7qXkLy0YScq9OHpmcY3HjxNjLYYhDjzxZidu7w8c=; b=GWfl9XO0j7IDFUoaXC4JgZuRgB64Le7/RjqhkURxPLUDUt1aa6hHEh8AjhROrvPXVN +hJVfdNaw2xDg0tshXU4GTwHJaj/h+LbafWs53rK2UNMqlhYbyPmRJ3wGw1Gr+uzcHCn l72WnFBJ/9ecvx4HwNVl/eU2aE/ZYAq2W6OX4Canc8TqMXwUNq1jyF0XqjGjictTuJLX A/3xThpnJk5C7KCtNEg4kQenTmUt91nT6E+LBtnm3WENktmmPbNRvKBWfQmGMZuFEdAd kRUdrxTmuLRBiXvDPcP9rRgx+DNZH7Yn3prcoG8N1tGILfiTJe/5u42yl8CEh2mDAe13 TCKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Scu7qXkLy0YScq9OHpmcY3HjxNjLYYhDjzxZidu7w8c=; b=RhNXKXZvamy1bZ6r0TQhTOUQLLvi1UMkQHtjgdU1uy3eroBGIAzaehlamODTqYkUGs 2dCabojh1oDqlV1srJOcpZIZS3k3nnaVgoCHe0AxBBgb8K9zfaKYvSa2fP+UThveZw5W JQG6UIbAXYL++EDVWViHQ2xo+qzadrQL/brTGXlOi3aVu/N8QfkdzWuk3IAPjGocyi2d GvRr6PphXIbiAUZL5mzuCbFs9eRQFG9TIilX/fGqnZu+r4o4rIh50B/32RKjEHOiguEM 5ZuECgUbTAdeE0d5f36ZzHbh69E47gYoxGLyIqdyKhDe7g7vFPnQmgf0jbRD71ecYfqz rlCA== X-Gm-Message-State: APjAAAWE9ba2Vx9q8C5BVsGDS1kPFAp+DiarB5KrKPkGH99fEmxrcnrK nOJqrVmWgnfk8dkIvXa+E2E= X-Google-Smtp-Source: APXvYqxL6cR90jT4PygQyA0uHkfBO5STfBvboR6roDgts5O8OMs+XSGNjCIv+uvJGbkXp07uCPViZw== X-Received: by 2002:a05:6402:1a4f:: with SMTP id bf15mr10615597edb.292.1568814299288; Wed, 18 Sep 2019 06:44:59 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa]) by smtp.gmail.com with ESMTPSA id t1sm666785ejb.63.2019.09.18.06.44.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Sep 2019 06:44:58 -0700 (PDT) From: Christian Decker To: ZmnSCPxj , Richard Myers In-Reply-To: References: <87mufhva0k.fsf@gmail.com> Date: Wed, 18 Sep 2019 15:44:47 +0200 Message-ID: <87ef0doh0w.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE 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 13:45:02 -0000 ZmnSCPxj writes: >> cooperative close: >> * when all parties mutually agree to close the channel >> * close the channel with a layer one transaction which finalizes the outputs 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 of any hosted update mechanisms, or more prosaically, "close of > channel factory 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 mechanism is if you have some contract in some deeply-nested > mechanism that will absolute-locktime expire "soon", in which case you > have to close everything that hosts it. But for example if a channel > factory has channels A B C and only A has an HTLC that will expire > soon, while the factory and A have to close, B and C can continue > operation, even almost as if nothing happened to A. Indeed this is something that I think we already mentioned back in the duplex micropayment channel days, though it was a bit hidden and only mentioned HTLCs (though the principle carries over for other structures built on the raw update mechanism): > The process simply involves one party creating the teardown > transaction, both parties signing it and committing it to the > blockchain. HTLC outputs which have not been removed by agreement can > be copied over to the summary transaction such that the same timelocks > and resolution rules apply. Notice that in the case of eltoo the settlement transaction is already the same as the teardown transaction in DMC. >> 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 transaction to the layer one blockchain >> * should be optimized for privacy and low on-chain fees paid for by parties entering and leaving the channel > > Assuming you mean that any owned funds will eventually have to be > claimed onchain, 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 participants 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. Indeed this is the first proposal I had back at the Milan spec meeting, and you are right that it requires stashing the funds in a temporary co-owned output to make sure the transition once we splice in is atomic. Batching could help here, if we have 3 participants joining they can coordinate to set the funds aside together and then splice-in at the same time. The downside is the added on-chain transaction, and the fact that the funds are not operational until they reach the required depth (I don't think we can avoid this with the current security guarantees provided by Bitcoin). Notice that there is still some uncertainty regarding the confirmation of the splice-in even though the funds were stashed ahead of time, and we may end up in a state where we assumed that the splice-in will succeed, but the fees we attached turn out to be too low. In this case we built a sandcastle that collapses due to our foundation being washed away, and we'd have to go back and agree on re-splicing with corrected fees (which a malicious participant might sabotage) or hope the splice eventually confirms. > 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 post-splice-in mechanism, until the splice-in tx is deeply > confirmed, after which the pre-splice-in version is discarded. > Updates need to be done on *both* mechanisms until then, and any > introduced money is "unuseable" anyway until the splice-in tx > confirms deeply since it would not exist in the pre-splice-in > mechanism yet. This is the more complex variant we discussed during the last face-to-face in Australia, and it seemed to me that people were mostly in favor of doing it this way. It adds complexity since we maintain multiple variants (making it almost un-implementable in LN-penalty), however the reduced footprint, and the uncertainty regarding confirmations in the first solution are strong arguments in favor of this option. > 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 offchain mechanism to another > multiparticipant offchain, by publishing a single transaction onchain. > It may be doable via some extension of my proposed ritual for changing > membership set. Aside from a bit more coordination I don't see any roadblocks to do this, and it'd be an awesome improvement. It even allows sub-dust transfers between channels, as long as the total funds in the channel remain above dust :-) >> 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. 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. The footprint would be 1 unilateral close, n outputs for participants, m outputs for contracts built on top, and 1 open transaction that recollects all outputs in which the non-responding participant is not a co-signer. The main advantage is that we can avoid downtime. Just spit-balling here, since it'd leak some of the update logic back into the contracts built on top of the update mechanism, which for me is enough to discard this idea again. >> 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. >> 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. >> liveness: >> * if signers know they will be offline, can they pre-sign updates that 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 own 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 one, otherwise we get a combinatorial explosion for the fallback cases where each combination of inactive participants needs to splice themselves out. It also adds the complexity of having to identify which participant 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 my fallback and then becoming unresponsive (added rounds of communication can help here, but are cumbersome). It may be a bit much added complexity for a small complexity to be honest, hopefully this won't be needed too often :-) Cheers, Christian