[Lightning-dev] High level fee mechanics

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Apr 11 09:17:15 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180411/a0d0a1ae/attachment-0001.html>


More information about the Lightning-dev mailing list