📅 Original date posted:2019-11-05
📝 Original message:
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).
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:57:04
in reply to nevent1q…f4xp
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:57:04Event JSON
{
"id": "c12e42f455cfb45a8045cd6c4bc48b04270315f15666e7cd34edc35259478751",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315424,
"kind": 1,
"tags": [
[
"e",
"0c91e21e034533f122e94b0fd3031654ae905512e27a1262e64ae8c7923a76b8",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2019-11-05\n📝 Original message:\nHi all,\n\n It's been widely known that we're going to have to have up-front\npayments for msgs eventually, to avoid Type 2 spam (I think of Type 1\nlink-local, Type 2 though multiple nodes, and Type 3 liquidity-using\nspam).\n\n Since both Offers and Joost's WhatSat are looking at sending\nmessages, it's time to float actual proposals. I've been trying to come\nup with something for several years now, so thought I'd present the best\nI've got in the hope that others can improve on it.\n\n1. New feature bit, extended messages, etc.\n2. Adding an HTLC causes a *push* of a number of msat on\n commitment_signed (new field), and a hash.\n3. Failing/succeeding an HTLC returns some of those msat, and a count\n and preimage (new fields).\n\nHow many msat can you take for forwarding? That depends on you\npresenting a series of preimages (which chain into a final hash given in\nthe HTLC add), which you get by decoding the onion. You get to keep 50\nmsat[1] per preimage you present[2].\n\nSo, how many preimages does the user have to give to have you forward\nthe payment? That depends. The base rate is 16 preimages, but subtract\none for each leading 4 zero bits of the SHA256(blockhash | hmac) of the\nonion. The blockhash is the hash of the block specified in the onion:\nreject if it's not in the last 3 blocks[3].\n\nThis simply adds some payment noise, while allowing a hashcash style\ntradeoff of sats for work.\n\nThe final node gets some variable number of preimages, which adds noise.\nIt should take all and subtract from the minimum required invoice amount\non success, or take some random number on failure.\n\nThis leaks some forward information, and makes an explicit tradeoff for\nthe sender between amount spent and privacy, but it's the best I've been\nable to come up with.\n\nThoughts?\nRusty.\n\n[1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about\n 655msat per message. Flat pricing for simplicity; we're trying to\n prevent spam, not create a spam market.\n[2] Actually, a number and a single preimage; you can check this is\n indeed the n'th preimage.\n[3] This reduces incentive to grind the damn things in advance, though\n maybe that's dumb? We can also use a shorter hash (siphash?), or\n even truncated SHA256 (128 bits).",
"sig": "f5d6aefa9f46a368cc12666a3abff0e85ffea0181dbf5329fd2d8e44deb35d7dfe968a572d731d49ffca199e12d6c3eb7c18e9d66b363ccb6c8c619a3999cc91"
}