{"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-10\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:\n\u003e\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e\u003e [ Snip summary, which is correct ]\n\u003e\n\u003e Huzzah!\n\u003e\n\u003e This correlates all the hops in a payment when the route reaches its end\n\u003e (due to the final preimage getting propogated back for everyone to justify\n\u003e the funds they claim). Maybe solvable by converting from hashes to ECC\n\u003e as the trapdoor function?\n\nI hadn't thought of this, but yes, once we've eliminated the trivial\npreimage correlation w/scriptless scripts it'd be a shame to reintroduce\nit here.\n\nWe need an accumulator with some strange properties though:\n\n1. Alice provides tokens and a base accumulator.\n2. Bob et. al can add these tokens to the accumulator.\n3. They can tell if invalid tokens have been added to the accumulator.\n4. They can tell how many tokens (alt: each token has a value and they\n   can tell the value sum) have been added.\n5. They can't tell what tokens have been added (unless they know all\n   the tokens, which is trivial).\n\nAny ideas?\n\n\u003e The refund amount propogating back also reveals the path, probably.\n\u003e Could that be obfusticated by somehow paying each intermediate node\n\u003e both as the funds go out and come back, so the refund decreases on the\n\u003e way back?\n\u003e\n\u003e Oh, can we make the amounts work like the onion, where it stays constant?\n\u003e So:\n\u003e\n\u003e   Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets\n\u003e   400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.\n\u003e\n\u003e   Success:\n\u003e     Alice forwards 1500 msat to Bob   (-1500, +1500, 0, 0)\n\u003e     Bob forwards 1500 msat to Carol   (-1500, 0, +1500, 0)\n\u003e     Carol forwards 1500 msat to Dave  (-1500, 0, 0, +1500)\n\u003e     Dave refunds 1200 msat to Carol   (-1500, 0, +1200, +300)\n\u003e     Carol refunds 800 msat to Bob     (-1500, +800, +400, +300)\n\u003e     Bob refunds 100 msat to Alice     (-1400, +700, +400, +300)\n\nOr, on success, upfront payment is fully refunded or not refunded at all\n(since they get paid by normal fees)?  Either way, no data leak for that\ncase.\n\n\u003e   Clean routing failure at Carol/Dave:\n\u003e     Alice forwards 1500 msat to Bob   (-1500, +1500, 0, 0)\n\u003e     Bob forwards 1500 msat to Carol   (-1500, 0, +1500, 0)\n\u003e     Carol says Dave's not talking\n\u003e     Carol refunds 1100 msat to Bob    (-1500, +1100, +400, 0)\n\u003e     Bob refunds 400 msat to Alice     (-1100, +700, +400, 0)\n\u003e\n\u003e I think that breaks the correlation pretty well, so you just need a\n\u003e decent way of obscuring path length?\n\nI don't see how this breaks correlation?\n\n\u003e In the uncooperative routing failure case, I wonder if using an ECC\n\u003e trapdoor and perhaps scriptless scripts, you could make it so Carol\n\u003e doesn't even get an updated state without revealing the preimage...\n\nI'm not sure.  We can make it so Carol has Bob's preimage(s), etc, so\nthat the node which fails doesn't get paid.  I initially thought this\nwould just make people pair up (fake) nodes, but it's probably not worth\nit since their path would be less-selected in that case.\n\nCheers,\nRusty."}