(Resubmitted because it was accidentally auto-discarded.)
Hello list and ZmnSCPxj,
>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.
I'm not trying to solve that problem. Although I don't foresee it
being difficult to allow participants to cooperatively join channels
in a procedure like a splice, the output would be to a (n+1)-of-(n+1)
multisig address (or alternatively, -1 for leaving channels).
>*However*, I wonder if Fulgurite adds more complexity than necessary.
I believe that the step up in complexity is justified given the change
in how we express information in channels.
>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.
You're right. The point of bringing multiparty channels into this
discussion was to say "here's how we'd do it in Fulgurite if somebody
wanted to", it just requires a lot more coordination that not every
environment would be able to have. Points of failure, etc.
>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.
That's true. My construction should still be able to do
Burchert-Decker-Wattenhofer exactly as described with a little work
using the same primitives, although I haven't gone out of my way yet
to formulate how to do it yet since it's a little auxiliary to what
we've been wanting to do with subchannels here at the DCI. 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.
>Code speaks louder than words.
Of course. :)
>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?
I'll admit that there's still a few unknowns that I have yet to think
about and figure out how to deal with, like this. But it's my
intuition that there's probably a simple solution just by making sure
the right checks happen in the right places.
- Trey Del Bonis
On Thu, Dec 6, 2018 at 6:20 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote:
>
> 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
