{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-11-05\n📝 Original message:\nGood morning Rusty,\n\nIs this intended to be enforceable onchain if a channel is dropped onchain while a message is being routed?\nBy 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\nAlso, it is not exactly clear to me, the mechanism you are proposing in detail.\nCan 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)?\n\nRegards,\nZmnSCPxj\n\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\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\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}