<div dir="ltr">Thank you, ZmnSCPxj.<div><br></div><div>&quot;...

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">by adjusting the on-Lightning `fee_base_msat` and `fee_proportional_millionths` of channels.&quot;</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Yes, I agree these prices are a critical signaling mechanism that can have substantial impact on expected channel lifetime and thus economic efficiency of lightning operation overall. (As you may recall, I believe we should allow negative prices - even if present day routing algorithms choose to treat negative fees as zero for temporary simplicity.) 

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">You make a good point it can also improve routing efficiency by hinting at capacity, but for now they are unfortunately linear.</span></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">The following paper did not account for the improved efficiency that price adjustment in response to channel state will likely enable, but one thing which may be relevant here is the underlying power law assumption of transaction size distribution (which is apparently drawn from actual data), and the more general approach to estimating channel lifespan. In lieu of advertising max capacity, perhaps we should instead permit a price exponent which may optionally be set to something larger than 1. The cost to channel operator of processing a transaction is largely the impact to expected channel lifespan, which in turn is nonlinear with respect to transaction size - and dramatically so as transaction size approaches (or exceeds) remaining capacity.</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><a href="https://arxiv.org/pdf/1712.10222.pdf">https://arxiv.org/pdf/1712.10222.pdf</a></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px"><br></span></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px">If we combine nonlinear pricing with your March 19 AMP proposal, I expect economic efficiency could be greatly improved.</span></div></span></div><div><br></div><div>Thanks again,</div><div>Benjamin Mord</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 12:49 AM, ZmnSCPxj <span dir="ltr">&lt;<a href="mailto:ZmnSCPxj@protonmail.com" target="_blank">ZmnSCPxj@protonmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning Benjamin,<br></div><span class=""><div><br></div><blockquote class="m_6106883119563951706protonmail_quote" type="cite"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" dir="ltr"><div>Do (should) channels have the option of publicizing their balances, so as to improve routing performance / scalability in a large network, and for competitive differentiation among competing routes? This would allow channel owners to balance privacy with efficiency, and where the incentive to publish would go up in proportion to network scalability requirements. Brute force trial &amp; error seems expensive at scale, and also reduces privacy of the sender - so it seems a useful hedge to leave this decision to the market (if technically practical).<br></div></div></div></blockquote><div><br></div></span><div>I think brute-force scales well enough, but perhaps we should see the network in action more.<br></div><div><br></div><div>To an extent, it is possible to hint the suitability of a channel for routing in a particular direction, without completely leaking your balance in detail, by adjusting the on-Lightning `fee_base_msat` and `fee_proportional_millionths` of channels.  If you have a high balance on a channel, you reduce your side of the fee for that channel (i.e. the direction where you are the source for payments on that channel) to encourage others to use it and hopefully pay you on a depleted channel.  If you have a low balance, you increase your fee.  These fees are already propagated using `channel_update`.  No current node software implements this yet, however.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote></div><br></div></div>