Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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 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. > > I was more talking about situations where wearen't doing > Burchert-Decker-Wattenhofer and want (unannounced) subchannels. 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. > Another idea is to have peers lie in the channel announcement which > particular channel has the funds moving when routing a payment. LN cannot support lying on gossip. The issue is that if lying were possible, then it would be possible to just give fake channels that do not exist at all (rather than being an alias to some other channel) and which cannot actually route payments. By requiring that funds be visibly locked onchain, we ensure that lying attacks are costly and that attackers have the option of behaving honestly (performing forwarding requests) and get compensated for the opportunity cost, or swallowing the opportunity cost. In the future, as the LN size increases, some nodes may remove channels of low capacity from their local routemaps in an effort to reduce their memory consumption. Larger capacity channels that are near to my node are more likely to succeed in forwarding, so it is better to retain them. This implies removing low-capacity channels that are far away from my node from my routemap to keep my routemap size manageable. > So > you say "this channel has x msat capacity" and when other peers > request to route payments through it, the parties already have agreed > to send it through the unannounced subchannel. This is already allowed in BOLT 1.1. Short channel IDs are only used as a cheap (8-byte) indicator for the next node in the route. If there is some private unannounced channel, or some other channel on the route, the forwarding node may use that if the publicly announced channel has insufficient capacity on the forwarding node side. Of course, if the publicly-visible channel has low total capacity, it becomes unlikely to be used for forwarding by third parties. Again, this is the tradeoff the Fulgurite user must consider. What could be done today would be this: 1. You and your peer lock your funds in a Fulgurite system. 2. The Fulgurite system is split into two subchannels, one is an "ordinary" HTLC-only channel, the other supports HTLC and DLC. 3. Everyone else on LN assumes your LN channel is the entire Fulgurite system (because that is what is committed onchain and that is what they will use). 4. If somebody routes through you, you prefer the HTLC-only subchannel. 5. If the HTLC-only subchannel has insufficient capacity you have two options: (1) swallow the cost of signing all 1 million DLC sub-contract signatures for every update of the HTLC, or (2) just pretend you're out of funds in the specified direction, regardless of the DLC-subchannel state (nobody can force you to use it anyway, and it is your choice to give up on the routing fees). In the future, when Burchert-Decker-Wattenhofer gets onto BOLT: 1. You and your peer lock your funds in a Fulgurite system. 2. The Fulgurite system is split into two subchannels, one is an "ordinary" HTLC-only channel, the other supports HTLC and DLC. 3. You and your peer pretend to create a Burchert-Decker-Wattenhofer channel factory that contains a single channel (the HTLC-only subchannel), with the rest of the funds not claimed to be used on LN. 4. If somebody routes through you, you prefer the HTLC-only subchannel. 5. If the HTLC-only subchannel has insufficient capacity you have two options: (1) swallow the cost of signing all 1 million DLC sub-contract signatures for every update of the HTLC, or (2) just pretend you're out of funds in the specified direction, regardless of the DLC-subchannel state (nobody can force you to use it anyway, and it is your choice to give up on the routing fees). > It should be trivial to compose Fulgurite in > Burchert-Decker-Wattenhofer exactly as-is, and you'd still get all the > nice scalability benefits. Exactly, which is why I mentioned how Burchert-Decker-Wattenhofer channel gossip will have to w
Re: [Lightning-dev] Fulgurite: ideas for making a more flexible Lightning Network protocol
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 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. I was more talking about situations where we *aren't* doing Burchert-Decker-Wattenhofer and want (unannounced) subchannels. Another idea is to have peers lie in the channel announcement which particular channel has the funds moving when routing a payment. So you say "this channel has x msat capacity" and when other peers request to route payments through it, the parties already have agreed to send it through the unannounced subchannel. Or just leave the ability to route through unanounced secret subchannels to situations where you've been given an invoice with a partial path already provided and the sender just "assumes" that the payment will work. It should be trivial to compose Fulgurite in Burchert-Decker-Wattenhofer exactly as-is, and you'd still get all the nice scalability benefits. > 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). To do that generally would be to have partitions give an optional "must be gone by" deadline where we should either get rid of the partition by then (somehow, we don't actually care) or force the channel on-chain if we're not using a "timeless" update mechanism like Poon-Dryja. Operations like ExpireHtlc should calculate an earlier deadline at which they'd become accepted, and be the thing to actually remove the in-channel HTLC "the right way". Complementary to that, I have the update mechanism update a "validity deadline" as a side effect after a state has been re-signed, which helps us to know when to do periodic re-signings. - Trey Del Bonis On Sat, Dec 8, 2018 at 2:37 PM ZmnSCPxj wrote: > > 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 th
