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

[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 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 mentioned,
or with multiparty Fulgurite acting as though it were just BDW.

> 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.

I'm not saying lie altogether, you still have to have the funds locked
on-chain.  Just say "here's this (layer 1) channel, we can route x
msat through it" and leave it at that, and have peers verify that x is
less than or equal to what the on-chain txo says it should have.  And
apparently that's already in BOLT 1.1 so that should be doable soon.
You still have the same security guarantees (with regard to verifying
funds actually seem to exist) with BDW as you would with Fulgurite
subchannels as external users can't verify that there's actually funds
in a channel if there's no tx spending into it on-chain, which still
happens with both systems as I understand it.

And I'd say that it is (somewhat) possible to lie in gossip.  If
parties in a BDW channel collude they could absolutely produce
announcements that say there's much more balance in subchannels than
there actually is, or vice-versa.  But that's not really a problem
when routing payments since they don't get much of anything from it
since large payments would fail there anyways.

> 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).

I'm not really sure how this is an issue since if the HTLC+DLC didn't
exist at all then you'd have to reject the payments anyways.  I'm in
favor of publishing messages that say "yes I know it looks like
there's more balance, there's actually less than that" for this
reason, so that nodes would know not to send payments that way.  What
*would* be nice to do is just "lie" about the effective capacity of
the channel in the announce or update message.  And it's not really
lying, you just don't have a way of justifying that announcement vs
what it looks like on-chain.  And of course NOINPUT would make DLCs
less of a hassle, even in Poon-Dryja, as previously mentioned.

Also aside from that, it'd be nice to have update_channel messages
have a way to say the balances (and fees) in each direction in a
channel.  Since for very public nodes you'd be able to deduce roughly
how much balance can flow in a particular direction and it would aid
in calculating the optimal payment in the long run, especially for
scenarios where you don't care about privacy as much as usability (and
you can still fuzz the balances, etc.).  You don't even have
to publish update_channels very often, say every hour or day,
depending on the capacity and usage of the channel.

- Trey Del Bonis

On Sun, Dec 9, 2018 at 11:31 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> 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 work.
>
> Regards,
> ZmnSCPxj