Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-13 📝 Original message: Good morning ZmnSCPxj, As ...
📅 Original date posted:2018-04-13
📝 Original message:
Good morning ZmnSCPxj,
As a skeptic of discrete logarithm's long-term security, I view scriptless
scripts as dangerously seductive. (But wow, are they cool! Almost cool
enough to wish we could uninvent quantum computing. I wonder if R-LWE can
be used instead as foundation? Not that I expect R-LWE to hold long-term
either...) But I digress.
As I listen to all the work starting up in the legacy financial markets to
mitigate the likely future failure of LIBOR, given how little thought went
into that possibility in the writing of currently-traded derivative
contracts, I'm reminded of how important and also how possible it is to
think about short and long-term goals simultaneously as we build systems.
It is far easier now than it will soon be to add expressiveness into the
core protocol, such as negative fees and optional exponential component.
Just because we pragmatically ignore negative fees and exponents in routing
decisions today, does not mean we will not feel enormous need for them in
the future - and having the ability to express such fee structures now will
enable efficiency improvements in the future, as simple implementation
(rather than protocol) upgrades.
I recognize AMP (at least as you proposed) is a long way out, but it seems
like something we'll inevitably want and will surely add. It is therefore
worth assuming now, as we think strategically about how fee dynamics will
improve efficiency over time. Who knows, my skepticism of discrete
logarithm hardness may prove misplaced, or else we'll find other ways to
achieve AMP. (I have not read roasbeef's proposal, but I shall.) The
protocol does not presently allow an exponential component, but it would be
trivial to add (even if, at first, defaulted to 1).
Thanks,
Ben
On Fri, Apr 13, 2018 at 9:26 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Benjamin,
>
>
>
>
> Sent with ProtonMail <https://protonmail.com>; Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 13, 2018 4:37 AM, Benjamin Mord <ben at 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 <ZmnSCPxj at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180413/c35af87b/attachment.html>;
📝 Original message:
Good morning ZmnSCPxj,
As a skeptic of discrete logarithm's long-term security, I view scriptless
scripts as dangerously seductive. (But wow, are they cool! Almost cool
enough to wish we could uninvent quantum computing. I wonder if R-LWE can
be used instead as foundation? Not that I expect R-LWE to hold long-term
either...) But I digress.
As I listen to all the work starting up in the legacy financial markets to
mitigate the likely future failure of LIBOR, given how little thought went
into that possibility in the writing of currently-traded derivative
contracts, I'm reminded of how important and also how possible it is to
think about short and long-term goals simultaneously as we build systems.
It is far easier now than it will soon be to add expressiveness into the
core protocol, such as negative fees and optional exponential component.
Just because we pragmatically ignore negative fees and exponents in routing
decisions today, does not mean we will not feel enormous need for them in
the future - and having the ability to express such fee structures now will
enable efficiency improvements in the future, as simple implementation
(rather than protocol) upgrades.
I recognize AMP (at least as you proposed) is a long way out, but it seems
like something we'll inevitably want and will surely add. It is therefore
worth assuming now, as we think strategically about how fee dynamics will
improve efficiency over time. Who knows, my skepticism of discrete
logarithm hardness may prove misplaced, or else we'll find other ways to
achieve AMP. (I have not read roasbeef's proposal, but I shall.) The
protocol does not presently allow an exponential component, but it would be
trivial to add (even if, at first, defaulted to 1).
Thanks,
Ben
On Fri, Apr 13, 2018 at 9:26 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Benjamin,
>
>
>
>
> Sent with ProtonMail <https://protonmail.com>; Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 13, 2018 4:37 AM, Benjamin Mord <ben at 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 <ZmnSCPxj at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180413/c35af87b/attachment.html>;