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 0447D13EB; Thu, 3 Oct 2019 10:33:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12EBB189; Thu, 3 Oct 2019 10:33:49 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id h2so1989536edn.3; Thu, 03 Oct 2019 03:33:49 -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=c1AP+RJ0NeQxMuarET0pMrAggF1fH4YB7aNat8+M8GI=; b=DJxt1++NNqvRQkF4Go2JZRXdiUFwsa/JZAG+VqCvwjR3EtIott7rcsu4Vlpm0V+ZPk 71i3Kam8vvKQhTPr0x73XQg3JZlHdOUP62qMrWe0hityaE6NRw04rpNdLbx37a3VqVfh dDkCzyRT47d8W0lidw52K04aueZWfBk5pRWCpFW/iVTwOR39Zac/MDBTjy5dAr2dxxFy 6GLbekyiZTrK16bQcMoen1Wu1CGXKorziBbDEZWrihM7/Xq7qaWXc6wbVqGwWqGJ6nfJ Q2VQS6aYiCQ//fboR1j4TE+lH9Z/yt+tWsWtV+f4j2QcwVuhDhvTiJv2vOvgFPRnmDka 6Fyw== 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=c1AP+RJ0NeQxMuarET0pMrAggF1fH4YB7aNat8+M8GI=; b=j/GtsfztgNGr89eYbuP/pJlEFYcOeGPmMcOXVQDRyznZl8FI/pxMq0BFpJVj9l9vA7 sV0Bju7IpYka2Fazsboh1+FWFr2zl6+TgU5FetiNyZqKll6kUGDFiDfNC9YxvnwbmBUa MLv9QWrMNAL7nqhyO23kshmxtd3TJDqn7PDAj2cFOxOtiRCjAOYc4a5mb1ZcKLNG2WZk DjKqA0p1JXbRVXBahFbikUabyrxI2y6S17B2qVEV2Xd+k7IWCERmK34q2LYdQtl9RMSb wl6uCG8pGr/yfRNYNQzzr1s4sW+bwxHMoW8+lexJOEvqdK7rbzsVhvrxWxNSKE46GtDD 9dRg== X-Gm-Message-State: APjAAAWUC3TPAydIDsWMpTc1V4wI3IVWG5sjGrYaMiD3hSFCnhOnUb/r IfHDoWZ42d13U8tJIHwJqjygtxnaKVI= X-Google-Smtp-Source: APXvYqzG1purW0v3aRN1OeK6AGNeXuXShZF/RiPgppRfNGtMF8m2hIWpLsH4KCnXLoEe/1Kuaepj3Q== X-Received: by 2002:a17:906:20c7:: with SMTP id c7mr6894135ejc.248.1570098828463; Thu, 03 Oct 2019 03:33:48 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532]) by smtp.gmail.com with ESMTPSA id l7sm394192edv.84.2019.10.03.03.33.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 03 Oct 2019 03:33:47 -0700 (PDT) From: Christian Decker To: ZmnSCPxj In-Reply-To: <4zx7e_vHQr58myY5w_-bAjTk04LTGNknZudZs4wbUiOIoVKhL69M7k1eELCSuoBND2CtVXXzDFBHW4351cttIh80eP8jiaoO8cmbSefZmj4=@protonmail.com> References: <87wodp7w9f.fsf@gmail.com> <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com> <87tv8s7djq.fsf@gmail.com> <4zx7e_vHQr58myY5w_-bAjTk04LTGNknZudZs4wbUiOIoVKhL69M7k1eELCSuoBND2CtVXXzDFBHW4351cttIh80eP8jiaoO8cmbSefZmj4=@protonmail.com> Date: Thu, 03 Oct 2019 11:42:00 +0200 Message-ID: <87o8yy6u8n.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] Continuing the discussion about noinput / anyprevout 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, 03 Oct 2019 10:33:51 -0000 ZmnSCPxj writes: >> That is very much how I was planning to implement it anyway, using a >> trigger transaction to separate timeout start and the actual >> update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo >> there shouldn't be an issue here :-) > > My understanding is that a trigger transaction is not in fact > necessary for Decker-Russell-Osuntokun: any update transaction could > spend the funding transaction output directly, and thereby start the > relative timelock. At least, if we could arrange the funding > transaction output to be spendable directly using `SIGHASH_NOINPUT` or > variants thereof. This is the case in which we don't have a pre-signed settlement transaction (or in this case refund transaction) that uses a relative timelock. In order to have a refund transaction we would need to have the first update and settlement pair be signed before funding (otherwise the funder isn't sure she is getting her funds back). Since that first update and settlement pair do not need to be rebound (they can only ever be bound to the funding transaction) they can be signed without noinput/anyprevoutanyscript. If we use output tagging we would mandate that this first update must be published, so that the funding output is indistinguishable from a normal output, and the first update switches from non-noinput/anyprevoutanyscript to enabling it. Collaborative closes are still indistinguishable, unilateral closes require the switch, but then would be identifiable anyway. The one downside I can see is that we now mandate that unilateral closes also publish the first update, which is a bit annoying. >> While I do agree that we should keep outputs as unidentifiable as >> possible, I am starting to question whether that is possible for >> off-chain payment networks since we are gossiping about the existence of >> channels and binding them to outpoints to prove their existence anyway. > > * Lightning supports unpublished channels, so we do not gossip some outpoints even though they are in fact channels underneath. > * I confess the existence of unpublished channels in the spec fails to summon any reaction other than incredulity from me, but they exist nonetheless, my incredulity notwithstanding. That is true, we do however selectively tell others about the channel's existence (in invoices, our peers, ...) so I wouldn't consider that to be the most secret information :-) As for why they exist: nodes need to have the option of not announcing their channels to reduce the noise in the network with channels that are unlikely to be useable in order to forward payments. If every node were to announce their channels we'd have a much larger routing table, mostly consisting of unusable channels going to leafs in the network. Furthermore, the sheer threat that there might be unannounced channels adds uncertainty for attackers trying to profile nodes: "I see only my channel with my peer, but he might have unannounced channels, so I can't really tell whether the payment I forwarded to it is destined for it or one of its unannounced peers". > * Historical channels that have been cooperatively closed are no longer normally gossiped, so the fact that they used to be channels is no longer widely broadcast, and may eventually be forgotten by most or all of the network. > * This means anyone who wants to record the historical use of Lightning will have to retain the information themselves, rather than delegating it to fullnodes everywhere. Good point, it requires storing the ephemeral data from gossip, that's not all that hard, but I agree that it puts up a small barrier for newcomers.