📅 Original date posted:2018-04-11
📝 Original message:
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>;
Benjamin Mord [ARCHIVE] /
npub16y…kjvwy
2023-06-09 12:49:59
in reply to nevent1q…gejr
Author Public Key
npub16ycdmhx5sct3h37cwvjff8le7qlp9k0ngst5ry5n262j6gkesrssskjvwyPublished at
2023-06-09 12:49:59Event JSON
{
"id": "6bd612d8abfc5dcd7bbfb18522277c736bd2f521820db8479b9f6164558dda89",
"pubkey": "d130dddcd486171bc7d87324949ff9f03e12d9f3441741929356952d22d980e1",
"created_at": 1686314999,
"kind": 1,
"tags": [
[
"e",
"5533e0c7b82d5e1638d90538ba530a9ff2eb1331858945caf03204245bcfecca",
"",
"root"
],
[
"e",
"5281459076efec077d8da37041ae9795f0a63051edeaf93cc23b824d5af9fedf",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-04-11\n📝 Original message:\nDo (should) channels have the option of publicizing their balances, so as\nto improve routing performance / scalability in a large network, and for\ncompetitive differentiation among competing routes? This would allow\nchannel owners to balance privacy with efficiency, and where the incentive\nto publish would go up in proportion to network scalability requirements.\nBrute force trial \u0026 error seems expensive at scale, and also reduces\nprivacy of the sender - so it seems a useful hedge to leave this decision\nto the market (if technically practical).\n\n\nOn Wed, Apr 11, 2018 at 5:17 AM, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Alejandro,\n\u003e\n\u003e\n\u003e No, channel balance of each peer on the channel is not revealed on node\n\u003e gossip.\n\u003e\n\u003e Logically, invert the question: do you want to report how much you\n\u003e spend/receive on each of your channels to the network? Do you want to\n\u003e report how much you own on Lightning to be reported to everyone on\n\u003e Lightning?\n\u003e\n\u003e Since the balance on each peer is effectively the amount of money each\n\u003e peer owns on that channel, and each change to that balance represents a\n\u003e send/receive on that channel, you will not want to report your balance, and\n\u003e any changes in that balance, to the entire network.\n\u003e\n\u003e Logically you can then expect not to receive such updates from anybody\n\u003e else, either.\n\u003e\n\u003e How do real-life implementations like c-lightning get your payment routes\n\u003e then? By brute-force trial-and-error\n\u003e\n\u003e\n\u003e If payment routes are discovered by brute-force trial-and-error, and\n\u003e actually the sender can interrupt any payment by simply not revealing the\n\u003e secret, isn't it possible for any sender to simply start probing\n\u003e to discover the capacities in each path?\n\u003e\n\u003e\n\u003e Yes. Although now the sender risks its funds: if a node along the route\n\u003e it selects stalls, then the sender risks having its money locked for some\n\u003e blocks.\n\u003e\n\u003e Also, the sender only gets one bit of information to the question: Is the\n\u003e channel balance in this direction greater than X?\n\u003e\n\u003e Finally, the exact failure TEMPORARY_CHANNEL_FAILURE can mean that the\n\u003e other node is currently down rather than the channel not having enough\n\u003e capacity in that direction, or if there are too many HTLCs in-flight on\n\u003e that channel, or so on (the most likely currently seems to be the node is\n\u003e currently down rather than the channel balance being insufficient, since it\n\u003e seems many people do not leave their nodes running 24/7).\n\u003e\n\u003e So it is always less desirable than getting the exact channel balances at\n\u003e each balance update. You get degraded privacy, but not a full loss of\n\u003e privacy compared to broadcasting all balance updates.\n\u003e\n\u003e (in particular, if the channel balance changes, you would have to re-query\n\u003e the channel again to learn this)\n\u003e\n\u003e (your technique is flawed in the detail that the sender simply selects a\n\u003e destination randomly and a random payment hash, which has negligible\n\u003e probability of the randomly-selected destination knowing its preimage, but\n\u003e is otherwise sound in its broad strokes)\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180411/5d786b71/attachment-0001.html\u003e",
"sig": "fda5e049828c67948527fef196965eda4177acf638915ea7c3cf4012b729f72915f58488db649375256efc2f2a8ae30f71df342f32db6c1ae0af311ae2cdbd65"
}