ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-11 📝 Original message: Good morning Trey, > > ...
📅 Original date posted:2018-12-11
📝 Original message:
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 mentioned,
> or with multiparty Fulgurite acting as though it were just BDW.
I suppose it would depend on how we end up defining words.
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 multiparty system communicates between the nodes in order to coordinate updates to the system).
>
> > 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.
Yes.
> 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.
But they cannot produce announcements where the total balance in subchannels is greater than what the actual specified UTXO has.
Again, as I mentioned, in the future where the public mainnet LN is very large, it is likely that nodes with limited working memories will drop channels below a specified capacity from their in-memory routemaps, since the capacity is something they can verify and in general dropping lower-capacity channels is less likely to cause future payment failures.
> > 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.
This is not an issue.
It is simply the option that the Fulgurite user has.
That is, balance the cost of transmitting a large number of DLC signatures, vs. the benefit of earning a little money for routing.
>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.
Certainly that can be done.
It is not lying but being more honest --- it looks like you have more capacity, but you admit that there is less useable capacity than that.
I suppose I fixated too much on the term "lie" here, since it is not the correct term as you are being *more* honest about the actual situation, not less.
> 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.
We would have to design this carefully.
One side may be willing to let such information be known, but the other side might not.
Current `channel_update` contains only signature from one side of the channel, as it contains data like "how much do I want to charge as fees if you use this channel to forward", which requires only the consent of one side.
If one side admits "I have 1.0BTC" on a channel that publicly can be verified as 3.5BTC capacity, that immediately implies that the other side has 2.5BTC on that channel.
Perhaps a new `channel_balance_update` gossip message that is signed by both sides instead.
But the fact that we do not *currently* publish such, and yet payments in current LN are reasonably successful, suggests that it might not be at all necessary.
Current implementations already retry routes, and work well enough without this information.
Various mini-enhancements like non-binding short-channel-id in onion hops, as well as the potential to reuse rendezvous routing for rerouting via alternative routes (modulo reservations Christian Decker has with actually doing the math) can help improve payment success even with no accurate knowledge of the channel state.
> 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.
This greatly increases bandwidth use for gossip, though.
In addition, most of the time the information will not be useful, since it is not likely I will need the accurate information about this channel state if I never have to make a payment that will route through that channel.
Regards,
ZmnSCPxj
📝 Original message:
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 mentioned,
> or with multiparty Fulgurite acting as though it were just BDW.
I suppose it would depend on how we end up defining words.
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 multiparty system communicates between the nodes in order to coordinate updates to the system).
>
> > 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.
Yes.
> 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.
But they cannot produce announcements where the total balance in subchannels is greater than what the actual specified UTXO has.
Again, as I mentioned, in the future where the public mainnet LN is very large, it is likely that nodes with limited working memories will drop channels below a specified capacity from their in-memory routemaps, since the capacity is something they can verify and in general dropping lower-capacity channels is less likely to cause future payment failures.
> > 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.
This is not an issue.
It is simply the option that the Fulgurite user has.
That is, balance the cost of transmitting a large number of DLC signatures, vs. the benefit of earning a little money for routing.
>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.
Certainly that can be done.
It is not lying but being more honest --- it looks like you have more capacity, but you admit that there is less useable capacity than that.
I suppose I fixated too much on the term "lie" here, since it is not the correct term as you are being *more* honest about the actual situation, not less.
> 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.
We would have to design this carefully.
One side may be willing to let such information be known, but the other side might not.
Current `channel_update` contains only signature from one side of the channel, as it contains data like "how much do I want to charge as fees if you use this channel to forward", which requires only the consent of one side.
If one side admits "I have 1.0BTC" on a channel that publicly can be verified as 3.5BTC capacity, that immediately implies that the other side has 2.5BTC on that channel.
Perhaps a new `channel_balance_update` gossip message that is signed by both sides instead.
But the fact that we do not *currently* publish such, and yet payments in current LN are reasonably successful, suggests that it might not be at all necessary.
Current implementations already retry routes, and work well enough without this information.
Various mini-enhancements like non-binding short-channel-id in onion hops, as well as the potential to reuse rendezvous routing for rerouting via alternative routes (modulo reservations Christian Decker has with actually doing the math) can help improve payment success even with no accurate knowledge of the channel state.
> 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.
This greatly increases bandwidth use for gossip, though.
In addition, most of the time the information will not be useful, since it is not likely I will need the accurate information about this channel state if I never have to make a payment that will route through that channel.
Regards,
ZmnSCPxj