Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-05 📝 Original message: Hi Rusty, Agreed w.r.t ...
📅 Original date posted:2019-11-05
📝 Original message:
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).
> 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).
> 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.
> 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.
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. 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.
-- Laolu
On Mon, Nov 4, 2019 at 6:25 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> It's been widely known that we're going to have to have up-front
> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
> spam).
>
> Since both Offers and Joost's WhatSat are looking at sending
> messages, it's time to float actual proposals. I've been trying to come
> up with something for several years now, so thought I'd present the best
> I've got in the hope that others can improve on it.
>
> 1. New feature bit, extended messages, etc.
> 2. Adding an HTLC causes a *push* of a number of msat on
> commitment_signed (new field), and a hash.
> 3. Failing/succeeding an HTLC returns some of those msat, and a count
> and preimage (new fields).
>
> How many msat can you take for forwarding? That depends on you
> presenting a series of preimages (which chain into a final hash given in
> the HTLC add), which you get by decoding the onion. You get to keep 50
> msat[1] per preimage you present[2].
>
> So, how many preimages does the user have to give to have you forward
> the payment? That depends. The base rate is 16 preimages, but subtract
> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
> onion. The blockhash is the hash of the block specified in the onion:
> reject if it's not in the last 3 blocks[3].
>
> This simply adds some payment noise, while allowing a hashcash style
> tradeoff of sats for work.
>
> The final node gets some variable number of preimages, which adds noise.
> It should take all and subtract from the minimum required invoice amount
> on success, or take some random number on failure.
>
> This leaks some forward information, and makes an explicit tradeoff for
> the sender between amount spent and privacy, but it's the best I've been
> able to come up with.
>
> Thoughts?
> Rusty.
>
> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
> 655msat per message. Flat pricing for simplicity; we're trying to
> prevent spam, not create a spam market.
> [2] Actually, a number and a single preimage; you can check this is
> indeed the n'th preimage.
> [3] This reduces incentive to grind the damn things in advance, though
> maybe that's dumb? We can also use a shorter hash (siphash?), or
> even truncated SHA256 (128 bits).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191105/b461390a/attachment-0001.html>;
📝 Original message:
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).
> 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).
> 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.
> 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.
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. 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.
-- Laolu
On Mon, Nov 4, 2019 at 6:25 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> It's been widely known that we're going to have to have up-front
> payments for msgs eventually, to avoid Type 2 spam (I think of Type 1
> link-local, Type 2 though multiple nodes, and Type 3 liquidity-using
> spam).
>
> Since both Offers and Joost's WhatSat are looking at sending
> messages, it's time to float actual proposals. I've been trying to come
> up with something for several years now, so thought I'd present the best
> I've got in the hope that others can improve on it.
>
> 1. New feature bit, extended messages, etc.
> 2. Adding an HTLC causes a *push* of a number of msat on
> commitment_signed (new field), and a hash.
> 3. Failing/succeeding an HTLC returns some of those msat, and a count
> and preimage (new fields).
>
> How many msat can you take for forwarding? That depends on you
> presenting a series of preimages (which chain into a final hash given in
> the HTLC add), which you get by decoding the onion. You get to keep 50
> msat[1] per preimage you present[2].
>
> So, how many preimages does the user have to give to have you forward
> the payment? That depends. The base rate is 16 preimages, but subtract
> one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the
> onion. The blockhash is the hash of the block specified in the onion:
> reject if it's not in the last 3 blocks[3].
>
> This simply adds some payment noise, while allowing a hashcash style
> tradeoff of sats for work.
>
> The final node gets some variable number of preimages, which adds noise.
> It should take all and subtract from the minimum required invoice amount
> on success, or take some random number on failure.
>
> This leaks some forward information, and makes an explicit tradeoff for
> the sender between amount spent and privacy, but it's the best I've been
> able to come up with.
>
> Thoughts?
> Rusty.
>
> [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about
> 655msat per message. Flat pricing for simplicity; we're trying to
> prevent spam, not create a spam market.
> [2] Actually, a number and a single preimage; you can check this is
> indeed the n'th preimage.
> [3] This reduces incentive to grind the damn things in advance, though
> maybe that's dumb? We can also use a shorter hash (siphash?), or
> even truncated SHA256 (128 bits).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191105/b461390a/attachment-0001.html>;