📅 Original date posted:2019-11-22
📝 Original message:
I think there's another alternative than upfront payments to prevent spam,
which is maybe less
controversial (but potentially less effective as well - to be investigated).
Why not adapt what has been done with email spam and PoW/merkle puzzles?
The high-level idea would be that the sender must solve a small PoW puzzle *for
each intermediate *
*node *and communicate the solution in the onion.
There are many ways we could do that (a new field in each intermediate hop,
grinding an HMAC
prefix, etc) so before going into specifics I only wanted to submit the
high-level idea.
What's neat with this is that it's simple, doesn't leak any privacy, and
avoids having to create a
node reputation system.
We fight spam by forcing the sender to use some resources (instead of sats).
Maybe this idea has already been proposed and broken, if that's the case
I'd love to see the
discussion if someone can surface it.
Cheers,
Bastien
Le lun. 11 nov. 2019 à 00:32, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
> Anthony Towns <aj at erisian.com.au> writes:
> > On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:
> >> Anthony Towns <aj at erisian.com.au> writes:
> >> [ Snip summary, which is correct ]
> >
> > Huzzah!
> >
> > This correlates all the hops in a payment when the route reaches its end
> > (due to the final preimage getting propogated back for everyone to
> justify
> > the funds they claim). Maybe solvable by converting from hashes to ECC
> > as the trapdoor function?
>
> I hadn't thought of this, but yes, once we've eliminated the trivial
> preimage correlation w/scriptless scripts it'd be a shame to reintroduce
> it here.
>
> We need an accumulator with some strange properties though:
>
> 1. Alice provides tokens and a base accumulator.
> 2. Bob et. al can add these tokens to the accumulator.
> 3. They can tell if invalid tokens have been added to the accumulator.
> 4. They can tell how many tokens (alt: each token has a value and they
> can tell the value sum) have been added.
> 5. They can't tell what tokens have been added (unless they know all
> the tokens, which is trivial).
>
> Any ideas?
>
> > The refund amount propogating back also reveals the path, probably.
> > Could that be obfusticated by somehow paying each intermediate node
> > both as the funds go out and come back, so the refund decreases on the
> > way back?
> >
> > Oh, can we make the amounts work like the onion, where it stays constant?
> > So:
> >
> > Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets
> > 400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.
> >
> > Success:
> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> > Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)
> > Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)
> > Carol refunds 800 msat to Bob (-1500, +800, +400, +300)
> > Bob refunds 100 msat to Alice (-1400, +700, +400, +300)
>
> Or, on success, upfront payment is fully refunded or not refunded at all
> (since they get paid by normal fees)? Either way, no data leak for that
> case.
>
> > Clean routing failure at Carol/Dave:
> > Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)
> > Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)
> > Carol says Dave's not talking
> > Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)
> > Bob refunds 400 msat to Alice (-1100, +700, +400, 0)
> >
> > I think that breaks the correlation pretty well, so you just need a
> > decent way of obscuring path length?
>
> I don't see how this breaks correlation?
>
> > In the uncooperative routing failure case, I wonder if using an ECC
> > trapdoor and perhaps scriptless scripts, you could make it so Carol
> > doesn't even get an updated state without revealing the preimage...
>
> I'm not sure. We can make it so Carol has Bob's preimage(s), etc, so
> that the node which fails doesn't get paid. I initially thought this
> would just make people pair up (fake) nodes, but it's probably not worth
> it since their path would be less-selected in that case.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191122/c0045b8d/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 14:57:07
in reply to nevent1q…smf4
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 14:57:07Event JSON
{
"id": "557aa23cbea8eecef629351ba5674dd972d1cfff7cc619a64fb066cf6ac62a65",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315427,
"kind": 1,
"tags": [
[
"e",
"0c91e21e034533f122e94b0fd3031654ae905512e27a1262e64ae8c7923a76b8",
"",
"root"
],
[
"e",
"b898e1dcab3ebe22d95d56165b43bc017ce6a765922ed9995928f6e710614105",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2019-11-22\n📝 Original message:\nI think there's another alternative than upfront payments to prevent spam,\nwhich is maybe less\ncontroversial (but potentially less effective as well - to be investigated).\n\nWhy not adapt what has been done with email spam and PoW/merkle puzzles?\nThe high-level idea would be that the sender must solve a small PoW puzzle *for\neach intermediate *\n*node *and communicate the solution in the onion.\nThere are many ways we could do that (a new field in each intermediate hop,\ngrinding an HMAC\nprefix, etc) so before going into specifics I only wanted to submit the\nhigh-level idea.\nWhat's neat with this is that it's simple, doesn't leak any privacy, and\navoids having to create a\nnode reputation system.\n\nWe fight spam by forcing the sender to use some resources (instead of sats).\nMaybe this idea has already been proposed and broken, if that's the case\nI'd love to see the\ndiscussion if someone can surface it.\n\nCheers,\nBastien\n\nLe lun. 11 nov. 2019 à 00:32, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\nécrit :\n\n\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e \u003e On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote:\n\u003e \u003e\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e \u003e\u003e [ Snip summary, which is correct ]\n\u003e \u003e\n\u003e \u003e Huzzah!\n\u003e \u003e\n\u003e \u003e This correlates all the hops in a payment when the route reaches its end\n\u003e \u003e (due to the final preimage getting propogated back for everyone to\n\u003e justify\n\u003e \u003e the funds they claim). Maybe solvable by converting from hashes to ECC\n\u003e \u003e as the trapdoor function?\n\u003e\n\u003e I hadn't thought of this, but yes, once we've eliminated the trivial\n\u003e preimage correlation w/scriptless scripts it'd be a shame to reintroduce\n\u003e it here.\n\u003e\n\u003e We need an accumulator with some strange properties though:\n\u003e\n\u003e 1. Alice provides tokens and a base accumulator.\n\u003e 2. Bob et. al can add these tokens to the accumulator.\n\u003e 3. They can tell if invalid tokens have been added to the accumulator.\n\u003e 4. They can tell how many tokens (alt: each token has a value and they\n\u003e can tell the value sum) have been added.\n\u003e 5. They can't tell what tokens have been added (unless they know all\n\u003e the tokens, which is trivial).\n\u003e\n\u003e Any ideas?\n\u003e\n\u003e \u003e The refund amount propogating back also reveals the path, probably.\n\u003e \u003e Could that be obfusticated by somehow paying each intermediate node\n\u003e \u003e both as the funds go out and come back, so the refund decreases on the\n\u003e \u003e way back?\n\u003e \u003e\n\u003e \u003e Oh, can we make the amounts work like the onion, where it stays constant?\n\u003e \u003e So:\n\u003e \u003e\n\u003e \u003e Alice wants to pay Dave via Bob, Carol. Bob gets 700 msat, Carol gets\n\u003e \u003e 400 msat, Dave gets 300 msat, and Alice gets 100 msat refunded.\n\u003e \u003e\n\u003e \u003e Success:\n\u003e \u003e Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)\n\u003e \u003e Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)\n\u003e \u003e Carol forwards 1500 msat to Dave (-1500, 0, 0, +1500)\n\u003e \u003e Dave refunds 1200 msat to Carol (-1500, 0, +1200, +300)\n\u003e \u003e Carol refunds 800 msat to Bob (-1500, +800, +400, +300)\n\u003e \u003e Bob refunds 100 msat to Alice (-1400, +700, +400, +300)\n\u003e\n\u003e Or, on success, upfront payment is fully refunded or not refunded at all\n\u003e (since they get paid by normal fees)? Either way, no data leak for that\n\u003e case.\n\u003e\n\u003e \u003e Clean routing failure at Carol/Dave:\n\u003e \u003e Alice forwards 1500 msat to Bob (-1500, +1500, 0, 0)\n\u003e \u003e Bob forwards 1500 msat to Carol (-1500, 0, +1500, 0)\n\u003e \u003e Carol says Dave's not talking\n\u003e \u003e Carol refunds 1100 msat to Bob (-1500, +1100, +400, 0)\n\u003e \u003e Bob refunds 400 msat to Alice (-1100, +700, +400, 0)\n\u003e \u003e\n\u003e \u003e I think that breaks the correlation pretty well, so you just need a\n\u003e \u003e decent way of obscuring path length?\n\u003e\n\u003e I don't see how this breaks correlation?\n\u003e\n\u003e \u003e In the uncooperative routing failure case, I wonder if using an ECC\n\u003e \u003e trapdoor and perhaps scriptless scripts, you could make it so Carol\n\u003e \u003e doesn't even get an updated state without revealing the preimage...\n\u003e\n\u003e I'm not sure. We can make it so Carol has Bob's preimage(s), etc, so\n\u003e that the node which fails doesn't get paid. I initially thought this\n\u003e would just make people pair up (fake) nodes, but it's probably not worth\n\u003e it since their path would be less-selected in that case.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\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/20191122/c0045b8d/attachment.html\u003e",
"sig": "91dd88db48963992a58c3bd7cd6d700b171cbd4fbd7384e40003b9f9272bd3edf1af3ecc9711166bbbf8c02f62f9ef348e1c38158b25ce6156a548199d30ccda"
}