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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to