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 72DD4B62; Thu, 19 Sep 2019 10:27:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88D6383A; Thu, 19 Sep 2019 10:27:20 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id r9so2679959edl.10; Thu, 19 Sep 2019 03:27:20 -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=i1QTpi+oIb94uFEPW89bveQ1XESLrhWJTNpnyF6RlpU=; b=XBOTeFAui+EHUimMg1q9OIcf5XbR7McYBuf/wGfjf9MZTAhYlGPRft8EazrU1ztC/e sO91RKfDsSWr6cUtD+GUZ2WeUnfswvuITNnsd/yrr/Mxuxism0H1Bx9IasQ0AD85Tn5+ dQ4IFaoXXcPDbXPkJN9aL41YIfqRWoEKDtdw+yQvGxvgaNroL0vgOB0Ze/w+qqb1aLsS DQ9H28ESwK/X6w8dObKTyAOYbyO2zBVarXQ7pyUkN0d5AOylTg/+QHSOQIaf+Mm7DrQt hNiI5Rt5lxQ2Y9mGE7c/er5KqzL/VAOLG9fkLYTf1s6aX48U9EmvnLhkjEg+80pIJKA5 8WNA== 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=i1QTpi+oIb94uFEPW89bveQ1XESLrhWJTNpnyF6RlpU=; b=dHrPTBXvbSZI8HYfZutxXTRndt4NZVkKynVspGmFjgLnjN0LFlSEXRKbaFx8pGE32Q iRFLYP6ZzJjffKPxCd0QNgDAUn0DYimJ8p1nhZV7Wv4+BQDlumicIoM11jTFu1xU4XKL zhGRoVYPfjQbZkNum3sthdowS9S1LzWKAZKx8t3E5jsX+7R1hDGBU1NXjkZK61H3wrtr S5XZtELmtGSiI9ZhG3MYEM/YC+ufknJFFMldEWDaNk/bfwn3X1U360QK1QYj9V8ruw6m F8VE7lt/DNs2+g+t0e1Ch23xb+z6g0yrrZ+I14yswPgGtJiX6Od8E9KDsuMXRDB4m9lm GdxQ== X-Gm-Message-State: APjAAAVmTfydH52yvrxhgs0GRxnUt82iSQ1KblG8wsTCX3xVN2tTMKSm qGddVFQqEIxnF2aGx1wdjco= X-Google-Smtp-Source: APXvYqwiBsxkgr8cEmysgM04JCMBfcbX8C/nebpDHLOqy5KIEMKW3tSCUtxcIDHkIXjEBqhP4g1SFg== X-Received: by 2002:a50:ef12:: with SMTP id m18mr15039497eds.18.1568888839094; Thu, 19 Sep 2019 03:27:19 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa]) by smtp.gmail.com with ESMTPSA id l19sm1557260edb.50.2019.09.19.03.27.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Sep 2019 03:27:18 -0700 (PDT) From: Christian Decker To: ZmnSCPxj In-Reply-To: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com> References: <87mufhva0k.fsf@gmail.com> <87ef0doh0w.fsf@gmail.com> <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com> Date: Thu, 19 Sep 2019 12:26:13 +0200 Message-ID: <87sgos8tve.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" , 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 10:27:21 -0000 ZmnSCPxj writes: >> 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 signatory 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 ability to run m nodes to outright steal money from you. > * As processing power is cheap nowadays, there is no m that can be considered safe. > Your alternative is to fall back on proof-of-work, but that just means 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 construction 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 in what they can do. > And if the only "right" the n-1 participants can do is to force the nth participant to claim its funds onchain, then that is implementable with a transaction doing just that, which is pre-signed by the nth participant and given to participants 1..n-1. Just to be clear, I do *not* want to support uncooperative splice-outs. This is due to their need to either pre-sign a splice-out of the party like I explained further down, or it requires encumbering whatever we build on top in order to do a fast-reopen. But I do think there is value in exploring what the options are :-) >> 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 least partial ownership of, and keep only those that are owned > only by the remaining members), then each member would have to > honestly claim which UTXOs it is interested in keeping after it is > kicked out of the membership set, defeating this point entirely. I > believe this is roughly what you propose in the next point, and > roughly what you would want with the "n-1 participants" earlier. That is indeed the issue I explained further down: > 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). Claiming ownership would then involve providing a valid input script (disregarding any timelocks) that could spend the output under some condition. Others would have to verify this proof-of-ownership before accepting the node's self-splice-out before accepting it. >> 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 complexity for a small benefit" or similar? Indeed, that was a weird sentence :-) I did mean that it is a lot of complexity for very little benefit :-) Cheers, Christian