[Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol

ZmnSCPxj ZmnSCPxj at protonmail.com
Sat Dec 8 19:37:07 UTC 2018

Good morning Trey,
> There's already some amount of trust in the
> information you're getting about channels, so I think we have a bit of
> flexibility with regard to what we announce to the rest of the
> network. We might have to loosen the restrictions a bit how that
> information is validated of course.

The validation of channel data (other than the fact that it is locked on the blockchain) is simply checking that both sides of the channel have agreed, i.e. signatures from one or both endpoints.
That is the only validation necessary, since any details of the channel will be their inviolate demesne; we do not need global consensus for things like what fees the node wants to charge for the use of the channel.
Only that the channel truly exists, is the only consensus validation we need.

For the case of Burchert-Decker-Wattenhofer channel factories, a single channel announcement will be done for all channels within the factory, signed off by all of the participants in the channel factory, and we presume that the factory participants have validated that the money owned by who is actually owned by that who.  However, each channel within the factory would then need channel updates only signed off by the two direct participants in the channel.  When channels within the factory are reorganized, a new announcement will need to be done and signed off on by participants in the factory who performed the reorg.

Burchert-Decker-Wattenhofer also allows channels to close and then reorganized with only a proper subset of the original factory participants, but this creates even more transactions and possibly greater CSV requirements.

> > So it seems to me better to move time-sensitivity to Fulgurite than to higher layers.
> > Higher layers can simply be concerned about what contracts it wants to enter into.
> > 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 layer.
> That's a good way to do it. I'll try something like that.

Of note, is that the update mechanism can always cancel any contract if all participants in the updateable cryptocurrency system have agreed.

One can consider the fulfillment of the hashlock in an HTLC to actually cancel the contract, and put its fund into whoever fulfilled it.
Similarly, if the timelock on an HTLC is about to expire, then both sides can agree to simply cancel it back to the beneficiary of the timelock branch.

>From this point-of-view, then, when the timelock is about to expire, and the other side refuses to sign off on the cancellation, our only remaining remedy is to fail the system and drop to onchain for enforcement.

Under Poon-Dryja there is no CSV requirement and the above point-of-view is easy to consider.

Under Decker-Wattenhofer and Decker-Russell-Osuntokun, there exists this CSV requirement and this becomes complicated.
Suppose we have a contract with a timelock at time N.
And this contract is put inside an update mechanism with CSV requirement of time M.
The contract must be cancelled by the participants at time N - M.
However, if not cancelled, the contract will be dropped onchain, and its true expiry will still be at time N.
In short, the contract changes between offchain (expires at time N - M) and onchain (expires at time N).


More information about the Lightning-dev mailing list