From decker.christian at gmail.com  Fri Apr 13 20:51:54 2018
From: decker.christian at gmail.com (Christian Decker)
Date: Fri, 13 Apr 2018 22:51:54 +0200
Subject: [Lightning-dev] Decker-Wattenhofer channels (was: An Idea to
	Improve Connectivity of the Graph)
In-Reply-To: <0I4teAIB5C5yDWJH8-5QhPCDBt6aLdOuYvgONL05K0jpaZ2ipUj2H2XtMfXYS0cwzU5jBw76OpZfVdkMF3WQaYtbiyu0-qewOIWh-bbSkcQ=@protonmail.com>
References: <0I4teAIB5C5yDWJH8-5QhPCDBt6aLdOuYvgONL05K0jpaZ2ipUj2H2XtMfXYS0cwzU5jBw76OpZfVdkMF3WQaYtbiyu0-qewOIWh-bbSkcQ=@protonmail.com>
Message-ID: <871sfirfrp.fsf@gmail.com>

ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:

> Good morning Christian,
>
> I wonder suddenly, about how HTLCs are offered under
> Decker-Wattenhofer Duplex Micropayment Channels.
>
> Under the Decker-Wattenhofer construction, I believe the transaction
> sequence is the below:
>
> funding -> trigger -> (relative-timelock) invalidation tree -> ... (relative-timelock) invalidation tree
>
> The outputs of the final invalidation tree transaction splits up the
> contents of the funds between the payer and payee in the individual
> simplex channels that compose the duplex channels.

Let's drop the simple micropayment channel from the end and just
consider the update mechanism. They are just an optimisation, and we can
do without, just updating from one state to the next state.

> However, HTLCs have an absolute timelock, so I am uncertain how those
> are forced into compatibility with the relative timelock the
> invalidation tree uses.

That is a very good observation. Indeed the absolute timelocks need to
be far enough in the future so that we can commit the latest branch of
the invalidation tree on-chain and then commit the HTLC resolution
before the HTLC timeout expires. That means that if we have a CLTV of
1000, a timelock range of 144 blocks (sum of the CSVs along the branch)
and a delta (security parameters of 6 blocks), then we would need to
start settling on-chain at depth 850 (144 timelock range + 6 blocks to
resolve the HTLC). So if we didn't resolve and remove the HTLC by block
height 850 we would initiate the settlement. This is similar to the
requirement to go on chain when an HTLC fails to resolve in time in LN,
compounded by the need to drop earlier since we need to commit the tree
branch as well.

> Under Poon-Dryja channels, the relative-timelock exists only on the
> claim transaction after a unilateral commitment transaction.  HTLCs
> are offered as outputs of the unilateral commitment transaction, so
> that the relative-timelock on the main output does not interfere with
> their normal operation (apparently the HTLCs offered can also be
> revoked, incidentally, though I have not studied them in detail:
> apparently unrevoked HTLC paths that go to ourself have an extra CSV
> in the HTLC-timeout and HTLC-success paths: but in any case the
> HTLC-timeout case, the relative timelock is relative to the absolute
> one that comes first).

Not really, the HTLC timeouts are also absolute, and require you to drop
on-chain in order to guarantee that all following hops resolve prior to
you resolving the incoming one.

> This is of concern as this seems likely to affect
> Burchert-Decker-Wattenhofer channel factories, which use invalidation
> trees internally also, which come before the HTLCs they eventually pay
> out to.

Yep, it is one of the reasons why I opted to join the Lightning camp :-)