📅 Original date posted:2018-09-20 📝 Original message: That might not be so ...

Christian Decker [ARCHIVE] /

npub1wtx…tuyn

2023-06-09 12:51:31

in reply to nevent1q…clt2

📅 Original date posted:2018-09-20
📝 Original message:
That might not be so desirable, since it leaks the current channel
capacity to the user. Depending on how fine grained the amount in the
invoice is and how the user can control it, he could do a binary search
over capacities and very reliably tell how much capacity you have and
track it over time. That is still the case for a single channel, but if
you always chose the same channel it reduces how much info is leaked.

Cheers,
Christian

Johan Torås Halseth <johanth at gmail.com> writes:
> Any reason not to include _all_ (up to a limit) incoming channels with
> sufficient capacity?
>
> Cheers,
> Johan
>
> On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell <rusty at blockstream.com> wrote:
>
>> Hi all,
>>
>> I'm considering a change to c-lightning, where `invoice` would
>> automatically append an 'r' field for a channel which has sufficient
>> *incoming* capacity for the amount (using a weighted probability across
>> our peers).
>>
>> This isn't quite what 'r' was for, but it would be a useful
>> hint for payment routing and also potentially for establishing an
>> initial channel. This is an issue for the Blockstream Store which
>> deliberately doesn't advertize an address any more to avoid
>> centralization.
>>
>> Thoughts welcome!
>> Rusty.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Author Public Key

npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn

Show more details

Published at

2023-06-09 12:51:31

Kind type

1 Short Text Note

Event JSON

{ "id": "9ddeb9ddea48b85845d31f331ae23e1bd67ebbf7200f2a9e611a97173354243b", "pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057", "created_at": 1686315091, "kind": 1, "tags": [ [ "e", "366eecfee520115b57e1274fd7d7de990d7837f6af86b6411ee4e47e7644a309", "", "root" ], [ "e", "94c0b1e6bdc8859a2eca59186b45257257cc657d6efdb91d65bced01dd9bc0e3", "", "reply" ], [ "p", "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f" ] ], "content": "📅 Original date posted:2018-09-20\n📝 Original message:\nThat might not be so desirable, since it leaks the current channel\ncapacity to the user. Depending on how fine grained the amount in the\ninvoice is and how the user can control it, he could do a binary search\nover capacities and very reliably tell how much capacity you have and\ntrack it over time. That is still the case for a single channel, but if\nyou always chose the same channel it reduces how much info is leaked.\n\nCheers,\nChristian\n\nJohan Torås Halseth \u003cjohanth at gmail.com\u003e writes:\n\u003e Any reason not to include _all_ (up to a limit) incoming channels with\n\u003e sufficient capacity?\n\u003e\n\u003e Cheers,\n\u003e Johan\n\u003e\n\u003e On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell \u003crusty at blockstream.com\u003e wrote:\n\u003e\n\u003e\u003e Hi all,\n\u003e\u003e\n\u003e\u003e I'm considering a change to c-lightning, where `invoice` would\n\u003e\u003e automatically append an 'r' field for a channel which has sufficient\n\u003e\u003e *incoming* capacity for the amount (using a weighted probability across\n\u003e\u003e our peers).\n\u003e\u003e\n\u003e\u003e This isn't quite what 'r' was for, but it would be a useful\n\u003e\u003e hint for payment routing and also potentially for establishing an\n\u003e\u003e initial channel. This is an issue for the Blockstream Store which\n\u003e\u003e deliberately doesn't advertize an address any more to avoid\n\u003e\u003e centralization.\n\u003e\u003e\n\u003e\u003e Thoughts welcome!\n\u003e\u003e Rusty.\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\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", "sig": "8abee9bec62a520de15ffbd23c815729e5c1967b2eed8c085bc8ff96f87040b82018f3a63f88f61098d639907c9e64da811322d6407d6426a954c661e421fb49" }