Good morning Benjamin,
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On April 13, 2018 4:37 AM, Benjamin Mord <b...@mord.io> wrote:
> Thank you, ZmnSCPxj.
>
> "... by adjusting the on-Lightning `fee_base_msat` and
> `fee_proportional_millionths` of channels."
>
> 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.) You make a good point it can
> also improve routing efficiency by hinting at capacity, but for now they are
> unfortunately linear.
>
> 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.
> https://arxiv.org/pdf/1712.10222.pdf
Larger payments also have a much lower chance of successfully propagating
through the network, as every channel in its route needs to have the requisite
capacity, so I think it somewhat balances out (maybe).
Adding a nonlinear component would be difficult to add on to the protocol
currently, as I think there is no provision for it in the protocol. But maybe
I am incorrect..?
> If we combine nonlinear pricing with your March 19 AMP proposal, I expect
> economic efficiency could be greatly improved.
My AMP proposal cannot work soon. It requires at minimum for
Bellare-Neven/MuSig/Schnorr (I get confused, which is the proper name for this)
signatures to be added to Bitcoin to get HD+SS. Then we need to switch over
all implementations to using scriptless script contingent payments rather than
hashlocked contingent payments (and convince all network node operators to
upgrade); we will be unable to use an intermediate node that does not
understand SS contingent payments for my style of AMP.
The earlier AMP proposal by roasbeef is back-compatible (uses the same
hashlocked contingent payments we already use now), but does not support a
proof-of-payment compatible with ZKCP protocols (although possibly I am wrong,
I think roasbeef has mentioned before that it is ZKCP compatible).
Regards,
ZmnSCPxj
> Thanks again,
> Benjamin Mord
>
> On Thu, Apr 12, 2018 at 12:49 AM, ZmnSCPxj <zmnsc...@protonmail.com> wrote:
>
>> Good morning Benjamin,
>>
>>> 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 & 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).
>>
>> I think brute-force scales well enough, but perhaps we should see the
>> network in action more.
>>
>> 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.
>>
>> Regards,
>> ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
