Good morning Trey,
> One thing
> we've talked about is if you and your counterparty want to route
> payments through each other but also want to enter into discreet log
> contracts, it might make sense to set up a subchannel for each purpose
> so you don't have to re-sign for all the potential outcomes for the
> DLCs (slow!) every time you add/remove an HTLC. Only the routing
> (sub)channel would be announced to the routing network.

Of note, the routing gossip is not trust-based.
Instead, part of the routing gossip is the block and transaction and output on 
which the channel is anchored onchain.
Nodes check if the specified txo is unspent, and matches the purported capacity 
of the channel.
Once a channel outpoint is spent, nodes automatically remove it from their maps.

In a world with Burchert-Decker-Wattenhofer factories, the factory would have 
an onchain txo.
Gossip would contain all the channels in the factory, and would be signed by 
the same signatories as the onchain txo.
Nodes would check that the channels purported to be contained in the factory 
sum up to the value of this txo.

I suppose that could be relaxed, so that the channels purported to be in the 
factory would sum up to less than or equal to the value of the channel factory 
txo instead.
This would allow a Fulgurite system to allocate only part of its funds to 
Lightning-visible routing nodes.

It strikes me that the issue of re-signing the DLC subcontracts could be 
avoided if you use `SIGHASH_NOINPUT`.
The same signatories could be used for the DLCs, and even if the update 
transaction changes, you can reanchor the DLC subcontracts with 

> > Code speaks louder than words.
> Of course. :)

Yes, so feel free to ignore whatever I say, since I have not coded for a while.

> > CSV requirements are a time-based requirement that affect the behavior of 
> > absolute timelocks used by HTLCs.
> > It is better to admit this earlier than later, since it becomes possible as 
> > an attack point if you do not take care to pay attention to the CSV 
> > requirement.
> > In particular, timelocked contracts need to be published onchain before the 
> > timeout expires, and a N-block CSV requirement then means you have to 
> > publish onchain N+1 blocks before the absolute timelock expires.
> Restrictions regarding when to publish could be managed at a higher
> level. What Fulgurite is trying to solve is how to manage the state
> negotiation rather than the high-level logic about when exactly to
> publish commitment txs. Maybe we should slightly alter the mechanics
> for how HTLC expiry works in-channel vs on-chain for this problem?

At minimum the lower-level system would have to alert the higher-level system 
that a time-sensitive contract needs to collapse the Fulgrite system or else it 
would not be possible to enforce the timelock.

Since contracts inside a multiparticipant updatable system can be cancelled by 
the agreement of all participants, I suppose the higher layer can decide to 
demand an update that the timelock be followed within the multiparticipant 
updatable system.
But the upper layer needs to be informed of the latest time that the contract 
can be enforced onchain.
Your alternative is that the upper layer needs to know whether the lower layer 
is using Poon-Dryja (no CSV requirement) or Decker-Wattenhofer (CSV 
requirement) or Decker-Russell-Osuntokun (CSV requirement), which you can argue 
is a layering violation.
Further the exact specs (how many blocks do all participants agree is 
reasonable for the CSV requirement?) would vary.

So it seems to me better to move time-sensitivity to Fulgurite than to higher 
Higher layers can simply be concerned about what contracts it wants to enter 
The higher layer informs the Fulgurite layer of the shortest absolute timelock 
in each contract it enters into.
The Fulgurite layer then returns to the higher layer the latest blockheight at 
which it can still safely collapse the Fulgurite system, or an error that the 
absolute timelock is too near and is already not enforceable at the Fulgurite 

Lightning-dev mailing list

Reply via email to