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

2018-12-12 Thread Trey Del Bonis
Hello ZmnSCPxj, >In any case, it is certainly possible for the spec to simply specify allowing >some multiparty system with unspecified link-level behavior, but with >specified global-level behavior (i.e. contains some channels that can be >routed through, but the spec will not define how the

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

2018-12-11 Thread ZmnSCPxj via Lightning-dev
Good morning Trey, > > Would it really be masquerading though? The standard shouldn't care > about how a multiparty channel is implemented, only the effective > balance between each party in each subchannel. And that's regardless > of if it's with Fulgurite being nested in BDW as previously

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

2018-12-10 Thread Trey Del Bonis
Hello ZmnSCPxj, > Yes, but if you want to interoperate, and it is Burchert-Decker-Wattenhofer > that gets into BOLT instead of Fulgurite, then we will need to have some way > to interoperate a Fulgurite system as masquerading as a > Burchert-Decker-Wattenhofer factory. Would it really be

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

2018-12-09 Thread ZmnSCPxj via Lightning-dev
Good morning Trey, > > > We might have to loosen the restrictions a bit how that information is > > > validated of course. > > > 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

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

2018-12-09 Thread Trey Del Bonis
Hi, > > We might have to loosen the restrictions a bit how that information is > > validated of course. > 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

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

2018-12-08 Thread ZmnSCPxj via Lightning-dev
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

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

2018-12-07 Thread Trey Del Bonis
Good afternoon, >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

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

2018-12-06 Thread ZmnSCPxj via Lightning-dev
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

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

2018-12-06 Thread ZmnSCPxj via Lightning-dev
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

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

2018-12-05 Thread ZmnSCPxj via Lightning-dev
Hi Trey, This document is a description of how I view individual channels on Lightning currently. The document is valuable as it provide a viewpoint of how Lightning works at each channel. Burchert-Decker-Wattenhofer channel factories are essentially multiparty (> 2 participants) "channels"