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

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Dec 6 11:20:43 UTC 2018

Good morning list, and also Trey,

I confirmed that Trey accidentally replied only to me, but intended to reply to the list.

> > Burchert-Decker-Wattenhofer channel factories are essentially multiparty (> 2 participants) "channels" ("offchain updateable cryptocurrency systems") with multiple "child" 2-party channels. In general though having multiple channels between the same 2 participants is not as valuable (which is why Burchert-Decker-Wattenhofer only has two levels in the hierarchy, and why the parent level is multiparty while the child level is 2-party).
> Where I was going with the paper is to figure out some of the details
> surrounding how to actually implement the protocols described by the
> more formal reasearch in the area and leave space in the design for
> other protocols that have yet to be designed to be implemented without
> having to do a large overhaul of the protocol. If we want to go and
> do Burchert-Decker-Wattenhofer-style channel factories we just have to
> describe it in terms of manipulating the Fulgurite state graph,
> without everyone in the channel actually having to understand
> Burchert-Decker-Wattenhofer. Note that Fulgurite subchannels are
> expected to have only a subset of the participants of their parents.

In effect, Fulgurite simply generalizes Lightning shared-ownership update systems ("channels").
The insight effectively is that:

1.  Any contract of interest to participants of a single "shared-ownership update system" can be done, as long as the contract is enforceable onchain.
2.  The "shared-ownership update system" itself is a contract that is enforceable onchain.
3.  Therefore, a "shared-ownership update system" can contain "shared-ownership update systems" of interest to its participants.

So "subsystems" here can have the same set of participants, or a subset of participants.
Non-participants cannot safely (non-custodially) use any such "shared-ownership update system" and any subsystems within it since they have no power to refuse to sign off an invalid state transition.

*However*, I wonder if Fulgurite adds more complexity than necessary.

2-party shared-ownership update systems ("channels") are best, since everyone has to sign.  Fewer participants means fewer points of failure.  Larger participant sets mean it is more likely somebody will be absent when any one of them wants to update the shared-ownership update system.

Burchert-Decker-Wattenhofer channel factories have the advantage that once the channels within the factory have been set up, participants can then be absent, and only their channels are affected.

> > Of note is that the existing update protocols can carry almost any Bitcoin-enforceable contract, including the same contracts used to enforce them. This is what allows update protocols to "nest" as in Burchert-Decker-Wattenhofer (or your concept of "parent" and "child" channels).
> Of course. But unless I'm mistaken I haven't seen any practical
> implentations of it yet, which is what I'm attempting to do. I know I
> won't get much adoption without BOLT support, but that's not a goal in
> the short term at least.

Code speaks louder than words.

> > There are some important details like the fact that Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on their transported contracts, and most contracts cannot be transported across systems (HTLCs can but with longer timelocks for each step).
> Building transactions might not be able to be 100% transparent to the
> partition behavior, but I don't really think that's a major
> restriction we need to worry about right now. Partitions talk about
> their on-chain representation at a relatively high level (see the
> `Contract` enum in the `core` crate) and the transaction builder (yet
> to be written) figures out how to implement that.

I believe it *is* important to worry about it right now.
The only objection I have to Decker-Russell-Osuntokun is that it adds an additional CSV requirement to transported contracts.
Otherwise it is strictly superior to Poon-Dryja.
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.


1.  Any absolute timelocked contract implies a timeout for the lifetime of the Fulgurite system/channel it is in.
2.  The contract must be fulfilled via a non-timelocked branch before that lifetime.
3.  If not fulfilled via a non-timelocked branch, the Fulgurite system must collapse onchain 1 block before the lifetime.
4.  If the Fulgurite system is based on Decker-Wattenhofer or Decker-Russell-Osuntokun, it must collapse onchain N+1 blocks before the lifetime, where N is the CSV timeout for the update system used.


More information about the Lightning-dev mailing list