📅 Original date posted:2018-09-26 📝 Original message: Olaoluwa Osuntokun ...

Rusty Russell [ARCHIVE] /

npub1zw7…khpx

2023-06-09 12:51:31

in reply to nevent1q…f26u

📅 Original date posted:2018-09-26
📝 Original message:
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.

Author Public Key

npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx

Seen on

wss://relay.noswhere.com

Show more details

Published at

2023-06-09 12:51:31

Kind type

1 Short Text Note

Event JSON

{ "id": "059511b759af1c6598b8ec663df97a60f337c26fd0ab188890d71937de92a631", "pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425", "created_at": 1686315091, "kind": 1, "tags": [ [ "e", "366eecfee520115b57e1274fd7d7de990d7837f6af86b6411ee4e47e7644a309", "", "root" ], [ "e", "5f1073d5331bae6e05af3d7c68adef8c0f56aa67de9f0f1760953b0f63ed2dcb", "", "reply" ], [ "p", "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476" ] ], "content": "📅 Original date posted:2018-09-26\n📝 Original message:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e\u003e That might not be so desirable, since it leaks the current channel\n\u003e\u003e capacity to the user\n\u003e\n\u003e\u003eFrom my PoV, the only way a node can protect the _instantaneous_ available\n\u003e bandwidth in their channel is to randomly reject packets, even if they have\n\u003e the bandwidth to actually accept and forward them.\n\u003e\n\u003e Observe that if a \"prober\" learns that you've _accepted_ a packet, then\n\u003e they know you have at least that amount as available bandwidth. As a result,\n\u003e I can simply send varying sat packet sizes over to you, either with the\n\u003e wrong timelock, or an unknown payment hash.\n\nYes. You have to have a false capacity floor, which must vary\nperiodically, to protect against this kind of probing (randomly failing\nattempts as you get close to zero capaicty is also subject to probing,\nAFAICT).\n\n\u003e Since we don't yet have the\n\u003e \"unadd\" feature in the protocol, you _must_ accept the HTLC before you can\n\u003e cancel it. This is mitigated a bit by the max_htlc value in the channel\n\u003e update (basically our version of an MTU), but I can still just send\n\u003e _multiple_ HTLC's rather than one big one to attempt to ascertain your\n\u003e available bandwidth.\n\nThis is orothogonal. There's no point probing your own channel, you're\npresumably probing someone else's.\n\nCheers,\nRusty.", "sig": "9f15132c5a697ac04c0bd819764ba94360fc7f66dab0aa88ade803abd3d4006bcf4103aac6ac096fda851d8a5f224f724f76daa2cd0a48631fc897b93a953783" }