[Lightning-dev] High level fee mechanics

Benjamin Mord ben at mord.io
Wed Apr 11 16:00:47 UTC 2018


Do (should) channels have the option of publicizing their balances, so as
to improve routing performance / scalability in a large network, and for
competitive differentiation among competing routes? This would allow
channel owners to balance privacy with efficiency, and where the incentive
to publish would go up in proportion to network scalability requirements.
Brute force trial & error seems expensive at scale, and also reduces
privacy of the sender - so it seems a useful hedge to leave this decision
to the market (if technically practical).


On Wed, Apr 11, 2018 at 5:17 AM, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Alejandro,
>
>
> No, channel balance of each peer on the channel is not revealed on node
> gossip.
>
> Logically, invert the question: do you want to report how much you
> spend/receive on each of your channels to the network? Do you want to
> report how much you own on Lightning to be reported to everyone on
> Lightning?
>
> Since the balance on each peer is effectively the amount of money each
> peer owns on that channel, and each change to that balance represents a
> send/receive on that channel, you will not want to report your balance, and
> any changes in that balance, to the entire network.
>
> Logically you can then expect not to receive such updates from anybody
> else, either.
>
> How do real-life implementations like c-lightning get your payment routes
> then?  By brute-force trial-and-error
>
>
> If payment routes are discovered by brute-force trial-and-error, and
> actually the sender can interrupt any payment by simply not revealing the
> secret, isn't it possible for any sender to simply start probing
> to discover the capacities in each path?
>
>
> Yes.  Although now the sender risks its funds: if a node along the route
> it selects stalls, then the sender risks having its money locked for some
> blocks.
>
> Also, the sender only gets one bit of information to the question: Is the
> channel balance in this direction greater than X?
>
> Finally, the exact failure TEMPORARY_CHANNEL_FAILURE can mean that the
> other node is currently down rather than the channel not having enough
> capacity in that direction, or if there are too many HTLCs in-flight on
> that channel, or so on (the most likely currently seems to be the node is
> currently down rather than the channel balance being insufficient, since it
> seems many people do not leave their nodes running 24/7).
>
> So it is always less desirable than getting the exact channel balances at
> each balance update.  You get degraded privacy, but not a full loss of
> privacy compared to broadcasting all balance updates.
>
> (in particular, if the channel balance changes, you would have to re-query
> the channel again to learn this)
>
> (your technique is flawed in the detail that the sender simply selects a
> destination randomly and a random payment hash, which has negligible
> probability of the randomly-selected destination knowing its preimage, but
> is otherwise sound in its broad strokes)
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180411/5d786b71/attachment-0001.html>


More information about the Lightning-dev mailing list