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