[Lightning-dev] Decker-Wattenhofer channels (was: An Idea to Improve Connectivity of the Graph)

[ZmnSCPxj]

Good morning Christian,
> 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.

Ouch.  The numbers look much much larger than the numbers we have as default in c-lightning.

> 
> > 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.


I was referring to the below comparisons of Decker-Wattenhofer with an HTLC offered but timed out:

funding -> kickoff -> (relative-locktime) invalidation tree HTLC-offer -> (absolute-timelock) HTLC-timeout -> claim

vs. Poon-Dryja:

funding -> commitment HTLC-offer -> (absolute-locktime) HTLC-timeout -> (relative-locktime) claim

Indeed I was pleasantly surprised to find out that HTLC-timeout exists in the BOLT 3 spec, and is itself also revokable (and thus has a relative-locktime to claim it).  The relative-locktime on claiming the HTLC-timeout output is effectively appended to the absolute locktime and does not overlap with it, as in the Decker-Wattenhofer case, and allows it to be considered separately from the HTLC timeout.

 
> > 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 :-)

Well, the Burchert-Decker-Wattenhofer channel factories have very nice theoretical numbers of how much blockspace they could save over just Lightning, and they use the invalidation tree structure.  I guess this simply leads back again to my original argument: we should have Burchert-Decker-Wattenhofer channel factories terminate into Poon-Dryja channels; we have the channel factories have a small number of updates so that the relative locktimes involved are kept small and this reflects the reality that we want to rearrange channels less often than we actually update them, and we use Poon-Dryja channels for the actual channels so that we keep the locktimes involved relatively small for the number of updates we can support.  We also have the precision, that the `cltv_delta` we report for a channel should be larger for channels created inside a channel factory, by the relative locktime consumed by the invalidation tree structure, precisely because of the relative locktimes along the way to the HTLC in the transaction.

Perhaps we can simply not have channel factories allow channel reorganization?  Then we would not have an invalidation tree at all ( consuming no relative-locktime): we have a funding transaction that funds the entire factory that is confirmed onchain, then an offchain split transaction (non timelocked) that funds multiple channels, and finally commitment transactions that spend from the split transaction.  In the case of a unilateral close we save no blockspace, but in case of a multilateral close where all channel factory owners are available for closing we can collapse the split and commitment transactions into a single close transaction.  Indeed, perhaps for this we can impose (1) 3 or more members (2) each member puts an equal amount (3) channels are fixed in my favorite structure, a cyclic superhub.

Regards,
ZmnSCPxj