Good morning Alejandro,
>> No, channel balance of each peer on the channel is not revealed on node
>> 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,
>> 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)
Lightning-dev mailing list