From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-dev\\@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput /
	anyprevout
Precedence: list

ZmnSCPxj <ZmnSCPxj@protonmail.com> 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.