Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-06 📝 Original message: In my opinion, the ...
📅 Original date posted:2019-11-06
📝 Original message:
In my opinion, the prepayment should be a last resort. It does take away
some of the attractiveness of the Lightning Network. Especially if you need
to make many payment attempts over long routes, the tiny prepays do add up.
For a $10 payment, it's probably nothing to worry about. But for
micro-payments this can become prohibitively expensive. And it is exactly
the micro-payment use case where Lightning outshines other payment systems.
A not yet imagined micro-payment based service could even be the launchpad
to world domination. So I think we should be very careful with interfering
with that potential.
Isn't spam something that can also be addressed by using rate limits for
failures? If all relevant nodes on the network employ rate limits, they can
isolate the spammer and diminish their disruptive abilities. If a node sees
that its outgoing htlc packets stack up, it can reduce the incoming flow on
the channels where the htlcs originate from. Large routing nodes could
agree with their peers on service levels that define these rate limits.
Joost
On Tue, Nov 5, 2019 at 3:25 AM 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/20191106/5bbc081f/attachment.html>;
📝 Original message:
In my opinion, the prepayment should be a last resort. It does take away
some of the attractiveness of the Lightning Network. Especially if you need
to make many payment attempts over long routes, the tiny prepays do add up.
For a $10 payment, it's probably nothing to worry about. But for
micro-payments this can become prohibitively expensive. And it is exactly
the micro-payment use case where Lightning outshines other payment systems.
A not yet imagined micro-payment based service could even be the launchpad
to world domination. So I think we should be very careful with interfering
with that potential.
Isn't spam something that can also be addressed by using rate limits for
failures? If all relevant nodes on the network employ rate limits, they can
isolate the spammer and diminish their disruptive abilities. If a node sees
that its outgoing htlc packets stack up, it can reduce the incoming flow on
the channels where the htlcs originate from. Large routing nodes could
agree with their peers on service levels that define these rate limits.
Joost
On Tue, Nov 5, 2019 at 3:25 AM 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/20191106/5bbc081f/attachment.html>;