Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-06 📝 Original message: Olaoluwa Osuntokun ...
📅 Original date posted:2019-11-06
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other
> alternatives for a few years now, and none of them seems to resolve the
> series of routing related incentive issues that prepaid HTLCs would.
>
>> Since both Offers and Joost's WhatSat are looking at sending messages,
>> it's time to float actual proposals.
>
> IMO both should just be done over HORNET, so we don't need introduce a new
> set of internal protocol level messages whenever we have some new
> control/signalling need. Instead, we'd have a control/signal channel (give
> me
> routes, invoices, sign this, etc), and a payment channel (HTLCs as used
> today).
I'm not so sure, as I don't think we're going to actually use each one
more than once or twice?
I mean, we could stream movies through LN, but I think that's an added
service, which would be best done by HORNET.
>> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed
>> (new field), and a hash.
>
> The prepay amount should be signalled in the update add message instead.
> This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we
> need a new onion field as well to signal the incoming amount the node
> _should_ have received (allows them to detect deviations in the sender's
> intended route).
Sorry, brain fart: it's a new field in the update_add_htlc of course.
I just, um, added that to make sure you were all reading carefully! :_
>> 3. Failing/succeeding an HTLC returns some of those msat, and a count and
>> preimage (new fields).
>
> Failing shouldn't return the prepay amount, otherwise extending long lived
> HTLCs then cancelling them at the last minute is still costless. This
> costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the
> biggest incentive flaw that exists today in the greater routing network.
No, that's type (liquidity) 3 spam, which needs a completely different
solution.
Definitely needs fixing, but up-front fees don't do it (except in the
case where you might want to indicate you're *going* to have a long-held
HTLC, where you'd pay additional up-front, but that's future work).
>> You get to keep 50 msat[1] per preimage you present[2].
>
> We should avoid introducing any new constants to the protocol, as they're
> typically dreamed up independent of any empirical lessons learned from
> deployment.
OTOH, we should avoid creating more complex knobs for users, since the
complexity of the protocol is becoming unmanagable. I think we did this
too much with v1, so instead of getting empirical data we got defaults
which in practice are unspecified specifications.
I like a flat value to start, since it's easy to implement and deploy.
> On the topic of the prepay cost, the channel update message should be
> extended to allow nodes to signal prepay costs similar to the way we handle
> regular payment success fees. In order to eliminate a number of costless
> attacks possible today on the routing network, nodes should also be able to
> signal a new coefficient used to _scale_ the prepay fee as a function of the
> CLTV value of the incoming HTLC.
... and HTLC amount, surely? That becomes a pretty complex tuning
parameter.
I think we should directly target type 3 spam through a separate
mechanism (as discussed previously). This is just to prevent quantity
of messages.
> With this addition, senders need to pay to
> _add_ an HTLC to a remote commitment transaction (fixed base cost), then
> also need to pay a variable rate that scales with the duration of the
> proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once
> we introduce this, loop attacks and the like are no longer free to launch,
> and nodes can dynamically respond to congestion in the network by raising
> their prepay prices.
I disagree; you should signal with normal fees, not prepay. Otherwise
we're increasing fees at a time that success rates are lowering, which
makes the incentive misalightment far more promiment :(
Cheers,
Rusty.
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Rusty,
>
> Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other
> alternatives for a few years now, and none of them seems to resolve the
> series of routing related incentive issues that prepaid HTLCs would.
>
>> Since both Offers and Joost's WhatSat are looking at sending messages,
>> it's time to float actual proposals.
>
> IMO both should just be done over HORNET, so we don't need introduce a new
> set of internal protocol level messages whenever we have some new
> control/signalling need. Instead, we'd have a control/signal channel (give
> me
> routes, invoices, sign this, etc), and a payment channel (HTLCs as used
> today).
I'm not so sure, as I don't think we're going to actually use each one
more than once or twice?
I mean, we could stream movies through LN, but I think that's an added
service, which would be best done by HORNET.
>> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed
>> (new field), and a hash.
>
> The prepay amount should be signalled in the update add message instead.
> This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we
> need a new onion field as well to signal the incoming amount the node
> _should_ have received (allows them to detect deviations in the sender's
> intended route).
Sorry, brain fart: it's a new field in the update_add_htlc of course.
I just, um, added that to make sure you were all reading carefully! :_
>> 3. Failing/succeeding an HTLC returns some of those msat, and a count and
>> preimage (new fields).
>
> Failing shouldn't return the prepay amount, otherwise extending long lived
> HTLCs then cancelling them at the last minute is still costless. This
> costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the
> biggest incentive flaw that exists today in the greater routing network.
No, that's type (liquidity) 3 spam, which needs a completely different
solution.
Definitely needs fixing, but up-front fees don't do it (except in the
case where you might want to indicate you're *going* to have a long-held
HTLC, where you'd pay additional up-front, but that's future work).
>> You get to keep 50 msat[1] per preimage you present[2].
>
> We should avoid introducing any new constants to the protocol, as they're
> typically dreamed up independent of any empirical lessons learned from
> deployment.
OTOH, we should avoid creating more complex knobs for users, since the
complexity of the protocol is becoming unmanagable. I think we did this
too much with v1, so instead of getting empirical data we got defaults
which in practice are unspecified specifications.
I like a flat value to start, since it's easy to implement and deploy.
> On the topic of the prepay cost, the channel update message should be
> extended to allow nodes to signal prepay costs similar to the way we handle
> regular payment success fees. In order to eliminate a number of costless
> attacks possible today on the routing network, nodes should also be able to
> signal a new coefficient used to _scale_ the prepay fee as a function of the
> CLTV value of the incoming HTLC.
... and HTLC amount, surely? That becomes a pretty complex tuning
parameter.
I think we should directly target type 3 spam through a separate
mechanism (as discussed previously). This is just to prevent quantity
of messages.
> With this addition, senders need to pay to
> _add_ an HTLC to a remote commitment transaction (fixed base cost), then
> also need to pay a variable rate that scales with the duration of the
> proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once
> we introduce this, loop attacks and the like are no longer free to launch,
> and nodes can dynamically respond to congestion in the network by raising
> their prepay prices.
I disagree; you should signal with normal fees, not prepay. Otherwise
we're increasing fees at a time that success rates are lowering, which
makes the incentive misalightment far more promiment :(
Cheers,
Rusty.