{"type":"rich","version":"1.0","title":"Olaoluwa Osuntokun [ARCHIVE] wrote","author_name":"Olaoluwa Osuntokun [ARCHIVE] (npub19h…zkvn4)","author_url":"https://yabu.me/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-05\n📝 Original message:\nHi Rusty,\n\nAgreed w.r.t the need for prepaid HTLCS, I've been mulling over other\nalternatives for a few years now, and none of them seems to resolve the\nseries of routing related incentive issues that prepaid HTLCs would.\n\n\u003e Since both Offers and Joost's WhatSat are looking at sending messages,\n\u003e it's time to float actual proposals.\n\nIMO both should just be done over HORNET, so we don't need introduce a new\nset of internal protocol level messages whenever we have some new\ncontrol/signalling need. Instead, we'd have a control/signal channel (give\nme\nroutes, invoices, sign this, etc), and a payment channel (HTLCs as used\ntoday).\n\n\u003e 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed\n\u003e (new field), and a hash.\n\nThe prepay amount should be signalled in the update add message instead.\nThis lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we\nneed a new onion field as well to signal the incoming amount the node\n_should_ have received (allows them to detect deviations in the sender's\nintended route).\n\n\u003e 3. Failing/succeeding an HTLC returns some of those msat, and a count and\n\u003e preimage (new fields).\n\nFailing shouldn't return the prepay amount, otherwise extending long lived\nHTLCs then cancelling them at the last minute is still costless. This\ncostlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the\nbiggest incentive flaw that exists today in the greater routing network.\n\n\u003e  You get to keep 50 msat[1] per preimage you present[2].\n\nWe should avoid introducing any new constants to the protocol, as they're\ntypically dreamed up independent of any empirical lessons learned from\ndeployment.\n\nOn the topic of the prepay cost, the channel update message should be\nextended to allow nodes to signal prepay costs similar to the way we handle\nregular payment success fees. In order to eliminate a number of costless\nattacks possible today on the routing network, nodes should also be able to\nsignal a new coefficient used to _scale_ the prepay fee as a function of the\nCLTV value of the incoming HTLC. With this addition, senders need to pay to\n_add_ an HTLC to a remote commitment transaction (fixed base cost), then\nalso need to pay a variable rate that scales with the duration of the\nproposed outgoing CLTV value (senders ofc don't prepay to themselves).  Once\nwe introduce this, loop attacks and the like are no longer free to launch,\nand nodes can dynamically respond to congestion in the network by raising\ntheir prepay prices.\n\n-- Laolu\n\nOn Mon, Nov 4, 2019 at 6:25 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Hi all,\n\u003e\n\u003e         It's been widely known that we're going to have to have up-front\n\u003e payments for msgs eventually, to avoid Type 2 spam (I think of Type 1\n\u003e link-local, Type 2 though multiple nodes, and Type 3 liquidity-using\n\u003e spam).\n\u003e\n\u003e         Since both Offers and Joost's WhatSat are looking at sending\n\u003e messages, it's time to float actual proposals.  I've been trying to come\n\u003e up with something for several years now, so thought I'd present the best\n\u003e I've got in the hope that others can improve on it.\n\u003e\n\u003e 1. New feature bit, extended messages, etc.\n\u003e 2. Adding an HTLC causes a *push* of a number of msat on\n\u003e    commitment_signed (new field), and a hash.\n\u003e 3. Failing/succeeding an HTLC returns some of those msat, and a count\n\u003e    and preimage (new fields).\n\u003e\n\u003e How many msat can you take for forwarding?  That depends on you\n\u003e presenting a series of preimages (which chain into a final hash given in\n\u003e the HTLC add), which you get by decoding the onion.  You get to keep 50\n\u003e msat[1] per preimage you present[2].\n\u003e\n\u003e So, how many preimages does the user have to give to have you forward\n\u003e the payment?  That depends.  The base rate is 16 preimages, but subtract\n\u003e one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the\n\u003e onion.  The blockhash is the hash of the block specified in the onion:\n\u003e reject if it's not in the last 3 blocks[3].\n\u003e\n\u003e This simply adds some payment noise, while allowing a hashcash style\n\u003e tradeoff of sats for work.\n\u003e\n\u003e The final node gets some variable number of preimages, which adds noise.\n\u003e It should take all and subtract from the minimum required invoice amount\n\u003e on success, or take some random number on failure.\n\u003e\n\u003e This leaks some forward information, and makes an explicit tradeoff for\n\u003e the sender between amount spent and privacy, but it's the best I've been\n\u003e able to come up with.\n\u003e\n\u003e Thoughts?\n\u003e Rusty.\n\u003e\n\u003e [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about\n\u003e     655msat per message.  Flat pricing for simplicity; we're trying to\n\u003e     prevent spam, not create a spam market.\n\u003e [2] Actually, a number and a single preimage; you can check this is\n\u003e     indeed the n'th preimage.\n\u003e [3] This reduces incentive to grind the damn things in advance, though\n\u003e     maybe that's dumb?  We can also use a shorter hash (siphash?), or\n\u003e     even truncated SHA256 (128 bits).\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191105/b461390a/attachment-0001.html\u003e"}