{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-05\n📝 Original message:\nZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e writes:\n\u003e Good morning Rusty,\n\nHi ZmnSCPxj!\n\n\u003e Is this intended to be enforceable onchain if a channel is dropped onchain while a message is being routed?\n\u003e 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.\n\nNo, it's done as a simple subtraction from direct to-local and to-remote\npayments.  Enforcement is by peer closing the channel, which you\nwouldn't do over a few msat.\n\n\u003e Also, it is not exactly clear to me, the mechanism you are proposing in detail.\n\u003e Can you give a motivating example, for example in a route from\n\u003e ZmnSCPxj, through Rusty, to my imaginary friend YAIjbOJa (who is not\n\u003e in fact me)?\n\nSure: for simplicity I'm sending a 0-value HTLC.\n\nZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat\nin the channel with YAIjbOJa.\n\nRusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.\n\nZmnSCPxj prepares the onion, but adds extra fields (see below).  He then\nsends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those\nfields are in the update_add_htlc msg).  His balance with Rusty is now\n8750msat (ie. 25x50 to Rusty).\n\nRusty decrypts the onion, reads the prepay field: it says 14, LLLLL.\nRusty checks: the hash of the onion \u0026 block (or something) does indeed\nhave the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14.  He\nthen hashes LLLLL 14 times, and yes, it's ZZZZZ as ZmnSCPxj said it\nshould be.\n\nSo Rusty takes the 14x50 as prepayment, and forwards the HTLC as\nnormal to YAIjbOJa, along with LLLLL and 11x50msat.  His balance with\nYAIjbOJa is now 450msat.\n\nYAIjbOJa decrypts the onion.  And it says 10,BBBBB.  YAIjbOJa checks\nthat hashing BBBBB 10 times does indeed give LLLLL.  Now it takes the\n11x50 msat, and fulfils the HTLC.  It replies to Rusty with 10,BBBBB\nin the update_fulfill_htlc message, returning the (implicit) 1x50msat;\nRusty's balance with YAIjbOJa is now 500msat.\n\nRusty checks that BBBBB hashed 10 times gives LLLLL.  Now it returns\n24,BBBBB to ZmnSCPxj with the update_fulfill_htlc, demonstrating to\nZmnSCPxj that he's entitled to it, and (implicity) returning 1x50msat to\nZmnSCPxj, so their balance is now 8800msat.\n\nNow let's look at attacks:\n\n1. Rusty steals the funds and doesn't return them.  ZmnSCPxj closes\n   channel, having lost 26x50msat.\n\n2, YAIjbOJa steals the funds and doesn't return them.  Rusty closes\n   the channel, having lost 11x50msat.\n\n3. ZmnSCPxj doesn't put correct preimages in, or too few, or other\n   malformation.  If it's Rusty's onion, he won't forward it and will\n   give an error.  If it's YAIjbOJa who rejects it, Rusty returns all\n   but the 14x50msat he has preimages for.\n\nObviously Rusty needs some upper limit on how much he'll pay out, to\navoid infinite exposure (say limit the total exposure to 10,000 sats).\n\nA reasonable limit for each HTLC would be 20 hops x 16 x 50msat ==\n16sat.  Even with no other limits, with 486 HTLCs in flight each way,\nthat's only 15456 satoshis.  You'll probably lament the channel closure\nmore.\n\nHope that helps!\nRusty.\n\n\u003e\u003e Hi all,\n\u003e\u003e\n\u003e\u003e It's been widely known that we're going to have to have up-front\n\u003e\u003e payments for msgs eventually, to avoid Type 2 spam (I think of Type 1\n\u003e\u003e link-local, Type 2 though multiple nodes, and Type 3 liquidity-using\n\u003e\u003e spam).\n\u003e\u003e\n\u003e\u003e Since both Offers and Joost's WhatSat are looking at sending\n\u003e\u003e messages, it's time to float actual proposals. I've been trying to come\n\u003e\u003e up with something for several years now, so thought I'd present the best\n\u003e\u003e I've got in the hope that others can improve on it.\n\u003e\u003e\n\u003e\u003e 1.  New feature bit, extended messages, etc.\n\u003e\u003e 2.  Adding an HTLC causes a push of a number of msat on\n\u003e\u003e     commitment_signed (new field), and a hash.\n\u003e\u003e\n\u003e\u003e 3.  Failing/succeeding an HTLC returns some of those msat, and a count\n\u003e\u003e     and preimage (new fields).\n\u003e\u003e\n\u003e\u003e     How many msat can you take for forwarding? That depends on you\n\u003e\u003e     presenting a series of preimages (which chain into a final hash given in\n\u003e\u003e     the HTLC add), which you get by decoding the onion. You get to keep 50\n\u003e\u003e     msat[1] per preimage you present[2].\n\u003e\u003e\n\u003e\u003e     So, how many preimages does the user have to give to have you forward\n\u003e\u003e     the payment? That depends. The base rate is 16 preimages, but subtract\n\u003e\u003e     one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the\n\u003e\u003e     onion. The blockhash is the hash of the block specified in the onion:\n\u003e\u003e     reject if it's not in the last 3 blocks[3].\n\u003e\u003e\n\u003e\u003e     This simply adds some payment noise, while allowing a hashcash style\n\u003e\u003e     tradeoff of sats for work.\n\u003e\u003e\n\u003e\u003e     The final node gets some variable number of preimages, which adds noise.\n\u003e\u003e     It should take all and subtract from the minimum required invoice amount\n\u003e\u003e     on success, or take some random number on failure.\n\u003e\u003e\n\u003e\u003e     This leaks some forward information, and makes an explicit tradeoff for\n\u003e\u003e     the sender between amount spent and privacy, but it's the best I've been\n\u003e\u003e     able to come up with.\n\u003e\u003e\n\u003e\u003e     Thoughts?\n\u003e\u003e     Rusty.\n\u003e\u003e\n\u003e\u003e     [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about\n\u003e\u003e     655msat per message. Flat pricing for simplicity; we're trying to\n\u003e\u003e     prevent spam, not create a spam market.\n\u003e\u003e     [2] Actually, a number and a single preimage; you can check this is\n\u003e\u003e     indeed the n'th preimage.\n\u003e\u003e     [3] This reduces incentive to grind the damn things in advance, though\n\u003e\u003e     maybe that's dumb? We can also use a shorter hash (siphash?), or\n\u003e\u003e     even truncated SHA256 (128 bits).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}