📅 Original date posted:2018-09-28
📝 Original message:
> This is orothogonal. There's no point probing your own channel, you're
> presumably probing someone else's.
In my scenario, you're receiving a new HTLC, from some remote party
unbeknownst to you. I was replying to cdecker's reply to johan that one
wouldn't always add this new type of routing hint for all channels since it
leaks available bandwidth information. Without something like an "unadd" you
can't do anything against an individual attempting to prob you other than
drop packets (drop as in don't even add to your commit, resulting in an HTLC
timeout), as if you cancel back, then they know that you had enough
bandwidth to _accept_ the HTLC in the first place.
-- Laolu
On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell <rusty at blockstream.com> wrote:
> Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> >> That might not be so desirable, since it leaks the current channel
> >> capacity to the user
> >
> >>From my PoV, the only way a node can protect the _instantaneous_
> available
> > bandwidth in their channel is to randomly reject packets, even if they
> have
> > the bandwidth to actually accept and forward them.
> >
> > Observe that if a "prober" learns that you've _accepted_ a packet, then
> > they know you have at least that amount as available bandwidth. As a
> result,
> > I can simply send varying sat packet sizes over to you, either with the
> > wrong timelock, or an unknown payment hash.
>
> Yes. You have to have a false capacity floor, which must vary
> periodically, to protect against this kind of probing (randomly failing
> attempts as you get close to zero capaicty is also subject to probing,
> AFAICT).
>
> > Since we don't yet have the
> > "unadd" feature in the protocol, you _must_ accept the HTLC before you
> can
> > cancel it. This is mitigated a bit by the max_htlc value in the channel
> > update (basically our version of an MTU), but I can still just send
> > _multiple_ HTLC's rather than one big one to attempt to ascertain your
> > available bandwidth.
>
> This is orothogonal. There's no point probing your own channel, you're
> presumably probing someone else's.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180928/3fae8786/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:51:31
in reply to nevent1q…4rax
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:51:31Event JSON
{
"id": "5aa2d92832f1dfa07f4b43d1b41bbc6972f2d0674b0afc0b7631485bfa27fb97",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315091,
"kind": 1,
"tags": [
[
"e",
"366eecfee520115b57e1274fd7d7de990d7837f6af86b6411ee4e47e7644a309",
"",
"root"
],
[
"e",
"059511b759af1c6598b8ec663df97a60f337c26fd0ab188890d71937de92a631",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-09-28\n📝 Original message:\n\u003e This is orothogonal. There's no point probing your own channel, you're\n\u003e presumably probing someone else's.\n\nIn my scenario, you're receiving a new HTLC, from some remote party\nunbeknownst to you. I was replying to cdecker's reply to johan that one\nwouldn't always add this new type of routing hint for all channels since it\nleaks available bandwidth information. Without something like an \"unadd\" you\ncan't do anything against an individual attempting to prob you other than\ndrop packets (drop as in don't even add to your commit, resulting in an HTLC\ntimeout), as if you cancel back, then they know that you had enough\nbandwidth to _accept_ the HTLC in the first place.\n\n-- Laolu\n\n\nOn Wed, Sep 26, 2018 at 5:54 PM Rusty Russell \u003crusty at blockstream.com\u003e wrote:\n\n\u003e Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e \u003e\u003e That might not be so desirable, since it leaks the current channel\n\u003e \u003e\u003e capacity to the user\n\u003e \u003e\n\u003e \u003e\u003eFrom my PoV, the only way a node can protect the _instantaneous_\n\u003e available\n\u003e \u003e bandwidth in their channel is to randomly reject packets, even if they\n\u003e have\n\u003e \u003e the bandwidth to actually accept and forward them.\n\u003e \u003e\n\u003e \u003e Observe that if a \"prober\" learns that you've _accepted_ a packet, then\n\u003e \u003e they know you have at least that amount as available bandwidth. As a\n\u003e result,\n\u003e \u003e I can simply send varying sat packet sizes over to you, either with the\n\u003e \u003e wrong timelock, or an unknown payment hash.\n\u003e\n\u003e Yes. You have to have a false capacity floor, which must vary\n\u003e periodically, to protect against this kind of probing (randomly failing\n\u003e attempts as you get close to zero capaicty is also subject to probing,\n\u003e AFAICT).\n\u003e\n\u003e \u003e Since we don't yet have the\n\u003e \u003e \"unadd\" feature in the protocol, you _must_ accept the HTLC before you\n\u003e can\n\u003e \u003e cancel it. This is mitigated a bit by the max_htlc value in the channel\n\u003e \u003e update (basically our version of an MTU), but I can still just send\n\u003e \u003e _multiple_ HTLC's rather than one big one to attempt to ascertain your\n\u003e \u003e available bandwidth.\n\u003e\n\u003e This is orothogonal. There's no point probing your own channel, you're\n\u003e presumably probing someone else's.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180928/3fae8786/attachment.html\u003e",
"sig": "be4c239247e373af50a317eb4cb926b0f0c522171f55f23e70a0a7971d654b4ebd2538f0066e4f11eff6a05bb43e38600e27efc4104a7d30d8eb58bab22707b4"
}