<div dir="ltr"><div>&gt; This is orothogonal.  There&#39;s no point probing your own channel, you&#39;re</div><div>&gt; presumably probing someone else&#39;s.</div><div><br></div><div>In my scenario, you&#39;re receiving a new HTLC, from some remote party</div><div>unbeknownst to you. I was replying to cdecker&#39;s reply to johan that one</div><div>wouldn&#39;t always add this new type of routing hint for all channels since it</div><div>leaks available bandwidth information. Without something like an &quot;unadd&quot; you</div><div>can&#39;t do anything against an individual attempting to prob you other than</div><div>drop packets (drop as in don&#39;t even add to your commit, resulting in an HTLC</div><div>timeout), as if you cancel back, then they know that you had enough</div><div>bandwidth to _accept_ the HTLC in the first place.</div><div><br></div><div>-- Laolu</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell &lt;<a href="mailto:rusty@blockstream.com">rusty@blockstream.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Olaoluwa Osuntokun &lt;<a href="mailto:laolu32@gmail.com" target="_blank">laolu32@gmail.com</a>&gt; writes:<br>
&gt;&gt; That might not be so desirable, since it leaks the current channel<br>
&gt;&gt; capacity to the user<br>
&gt;<br>
&gt;&gt;From my PoV, the only way a node can protect the _instantaneous_ available<br>
&gt; bandwidth in their channel is to randomly reject packets, even if they have<br>
&gt; the bandwidth to actually accept and forward them.<br>
&gt;<br>
&gt; Observe that if a &quot;prober&quot; learns that you&#39;ve _accepted_  a packet, then<br>
&gt; they know you have at least that amount as available bandwidth. As a result,<br>
&gt; I can simply send varying sat packet sizes over to you, either with the<br>
&gt; wrong timelock, or an unknown payment hash.<br>
<br>
Yes.  You have to have a false capacity floor, which must vary<br>
periodically, to protect against this kind of probing (randomly failing<br>
attempts as you get close to zero capaicty is also subject to probing,<br>
AFAICT).<br>
<br>
&gt; Since we don&#39;t yet have the<br>
&gt; &quot;unadd&quot; feature in the protocol, you _must_ accept the HTLC before you can<br>
&gt; cancel it. This is mitigated a bit by the max_htlc value in the channel<br>
&gt; update (basically our version of an MTU), but I can still just send<br>
&gt; _multiple_ HTLC&#39;s rather than one big one to attempt to ascertain your<br>
&gt; available bandwidth.<br>
<br>
This is orothogonal.  There&#39;s no point probing your own channel, you&#39;re<br>
presumably probing someone else&#39;s.<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div></div>