diff options
| author | Christian Decker <decker.christian@gmail.com> | 2019-09-18 15:44:47 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-09-18 13:45:02 +0000 |
| commit | a5a25c939988f8094969df44feff678089161b74 (patch) | |
| tree | 1b18ade0c19a535b8902546aa569054f30330eaa /67/62aa9364535b2ca6aa6e11dc286ec59c4f4770 | |
| parent | d668e51a3d9629c9ad1c685b75fbfa1375af4c48 (diff) | |
| download | pi-bitcoindev-a5a25c939988f8094969df44feff678089161b74.tar.gz pi-bitcoindev-a5a25c939988f8094969df44feff678089161b74.zip | |
Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo
Diffstat (limited to '67/62aa9364535b2ca6aa6e11dc286ec59c4f4770')
| -rw-r--r-- | 67/62aa9364535b2ca6aa6e11dc286ec59c4f4770 | 310 |
1 files changed, 310 insertions, 0 deletions
diff --git a/67/62aa9364535b2ca6aa6e11dc286ec59c4f4770 b/67/62aa9364535b2ca6aa6e11dc286ec59c4f4770 new file mode 100644 index 000000000..3b6f09382 --- /dev/null +++ b/67/62aa9364535b2ca6aa6e11dc286ec59c4f4770 @@ -0,0 +1,310 @@ +Return-Path: <decker.christian@gmail.com> +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 <decker.christian@gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, Richard Myers <rich@gotenna.com> +In-Reply-To: <ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.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> +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 <bitcoin-dev@lists.linuxfoundation.org>, + "lightning-dev@lists.linuxfoundation.org" + <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 <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: Wed, 18 Sep 2019 13:45:02 -0000 + +ZmnSCPxj <ZmnSCPxj@protonmail.com> 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 + |