{"type":"rich","version":"1.0","title":"Joost Jager [ARCHIVE] wrote","author_name":"Joost Jager [ARCHIVE] (npub1as…wfqmx)","author_url":"https://yabu.me/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-02-18\n📝 Original message:\nHi all,\n\nWithin our team, we've been discussing the subject of preventing\nliquidity-consuming spam (aka channel jamming) further. One idea came up\nthat I think is worth sharing.\n\nPrevious prepay ideas were based on the sender paying something up-front in\ncase the htlc causes grief on the network. This however leaves the sender\nvulnerable to nodes stealing that up-front payment.\n\nConsider what is probably the worst known channel jamming attack: an\nattacker sends minimum sized htlcs to fill up the limited number of\ncommitment slots of channels along the route. Those htlcs will be held as\nlong as possible by the receiving node (that is also controlled by the\nattacker). The hold time per htlc doesn't even need to be very long,\nbecause a fresh htlc can be launched to immediately re-occupy a slot after\nit opens up again.\n\nThe cost to the network of this attack is mostly dependent on the capacity\nof the channels used. The bigger the capacity, the more funds are locked up\nif a sufficient number of minimum sized htlcs are pending. The size of the\nup-front payment likely needs to be proportional to this cost.\n\nThis means that for small htlcs, the up-front payment requirements may very\nwell be exceeding the htlc amount and routing fees paid by far. At that\npoint, a routing node may decide to steal the up-front payment rather than\nearn the routing fee in an honest way.\n\nA different way of mitigating this is to reverse the direction in which the\nbond is paid. So instead of paying to offer an htlc, nodes need to pay to\nreceive an htlc. This sounds counterintuitive, but for the described\njamming attack there is also an attacker node at the end of the route. The\nattacker still pays. The advantage is that for legitimate senders, there is\nno up-front payment that can be stolen.\n\nHow this would work is that channel peers charge each other for the time\nthat the other party holds an htlc. So if node A extends an htlc to node B,\nnode B will pay node A amount x per minute of hold time. If node B doesn't\npay (doesn't hold up the contract), A will close the channel. It can be a\nrunning balance between A and B that materializes as a single htlc per\nchannel on the commitment transaction.\n\nAs long as node B forwards the htlc swiftly to node C, the dfiference (the\nactual cost) between what B needs to pay A and what B receives from C will\nbe tiny. Only when the htlc reaches the attacker node, or any other node on\nthe network that is (unintentionally) mishaving for some reason, the delta\nstarts to increase quickly for that node. The cost is borne by the node\nthat should bear it.\n\nThis would also fix concerns that have been voiced around hodl invoices.\nWith the reverse bond payment as described above, hodling nodes will pay\nfor the cost of their actions.\n\nMany details skipped over, but interested to hear opinions on the viability\nof this variation of up-front payments.\n\nJoost\n\nOn Tue, Nov 5, 2019 at 3:25 AM 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/20200218/59b4ba73/attachment.html\u003e"}