📅 Original date posted:2018-09-20 📝 Original message: I was thinking you could ...

Johan Torås Halseth [ARCHIVE] /

npub1ppn…s2fw

2023-06-09 12:51:31

in reply to nevent1q…2c6g

📅 Original date posted:2018-09-20
📝 Original message:
I was thinking you could just make many requests to get the same
information, but if you always choose the same channel as long as its
capacity meets the requirement, then not much is learnt :)

On Thu, Sep 20, 2018 at 9:26 AM Christian Decker <decker.christian at gmail.com>
wrote:

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

Author Public Key

npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fw

Show more details

Published at

2023-06-09 12:51:31

Kind type

1 Short Text Note

Event JSON

{ "id": "f533d224a78b410eeac39468151ad8ec303d5c29136b3034df495d573b1cab0f", "pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f", "created_at": 1686315091, "kind": 1, "tags": [ [ "e", "366eecfee520115b57e1274fd7d7de990d7837f6af86b6411ee4e47e7644a309", "", "root" ], [ "e", "9ddeb9ddea48b85845d31f331ae23e1bd67ebbf7200f2a9e611a97173354243b", "", "reply" ], [ "p", "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057" ] ], "content": "📅 Original date posted:2018-09-20\n📝 Original message:\nI was thinking you could just make many requests to get the same\ninformation, but if you always choose the same channel as long as its\ncapacity meets the requirement, then not much is learnt :)\n\n\n\nOn Thu, Sep 20, 2018 at 9:26 AM Christian Decker \u003cdecker.christian at gmail.com\u003e\nwrote:\n\n\u003e That might not be so desirable, since it leaks the current channel\n\u003e capacity to the user. Depending on how fine grained the amount in the\n\u003e invoice is and how the user can control it, he could do a binary search\n\u003e over capacities and very reliably tell how much capacity you have and\n\u003e track it over time. That is still the case for a single channel, but if\n\u003e you always chose the same channel it reduces how much info is leaked.\n\u003e\n\u003e Cheers,\n\u003e Christian\n\u003e\n\u003e Johan Torås Halseth \u003cjohanth at gmail.com\u003e writes:\n\u003e \u003e Any reason not to include _all_ (up to a limit) incoming channels with\n\u003e \u003e sufficient capacity?\n\u003e \u003e\n\u003e \u003e Cheers,\n\u003e \u003e Johan\n\u003e \u003e\n\u003e \u003e On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell \u003crusty at blockstream.com\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e Hi all,\n\u003e \u003e\u003e\n\u003e \u003e\u003e I'm considering a change to c-lightning, where `invoice` would\n\u003e \u003e\u003e automatically append an 'r' field for a channel which has sufficient\n\u003e \u003e\u003e *incoming* capacity for the amount (using a weighted probability across\n\u003e \u003e\u003e our peers).\n\u003e \u003e\u003e\n\u003e \u003e\u003e This isn't quite what 'r' was for, but it would be a useful\n\u003e \u003e\u003e hint for payment routing and also potentially for establishing an\n\u003e \u003e\u003e initial channel. This is an issue for the Blockstream Store which\n\u003e \u003e\u003e deliberately doesn't advertize an address any more to avoid\n\u003e \u003e\u003e centralization.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Thoughts welcome!\n\u003e \u003e\u003e Rusty.\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e Lightning-dev mailing list\n\u003e \u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\u003e\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180920/114dfd18/attachment.html\u003e", "sig": "a63b53cff6bb44e1204d349af01f8820e0a9526816b72ae05fedd38d05008b0c4f3bb5a768002ddbfe8cbbfdf297d7aa1059b6c4921cb192d54fd88f2d1947ac" }