From ZmnSCPxj at protonmail.com  Tue Nov  5 04:59:33 2019
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Tue, 05 Nov 2019 04:59:33 +0000
Subject: [Lightning-dev] A proposal for up-front payments.
In-Reply-To: <87ftj33w2z.fsf@rustcorp.com.au>
References: <87ftj33w2z.fsf@rustcorp.com.au>
Message-ID: <L0p5sSPLxLmM6tzffMX9L7S4PZvWY2rBNIeZygNqvRPaJ0ywPB0BR-hcHnZOtsxnU5RZ1TL4aNHUQ-WtIdICUhd6QcJQIq6aGY1FJ579ruM=@protonmail.com>


Good morning Rusty,

Is this intended to be enforceable onchain if a channel is dropped onchain while a message is being routed?
By a vague sense of the description, it seems to me, it would require a complicated SCRIPT (or multiple tiny 50-msatoshi UTXOs) to enforce onchain.

Also, it is not exactly clear to me, the mechanism you are proposing in detail.
Can you give a motivating example, for example in a route from ZmnSCPxj, through Rusty, to my imaginary friend YAIjbOJa (who is not in fact me)?

Regards,
ZmnSCPxj


> 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