ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-22 📝 Original message: Good morning Bastien, > I ...
📅 Original date posted:2019-11-22
📝 Original message:
Good morning Bastien,
> 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.
This imposes a cost that varies depending on how specialized your hardware is at generating proof-of-work.
At a certain point-of-view, one can argue that directly paying with millisatoshis for each hop (whether it fails to forward or not) has the same cost on the sender (replace the consumption of energy to compute proof-of-work with a payment or burning of funds instead), and at least does not prejudice against sender hardware that is not specialized at generating proof-of-work.
Thus I would argue that, given we already have a system that bases an economic token on top of proof-of-work, every use of proof-of-work today (other than to power Bitcoin itself, as Bitcoin cannot support itself) can instead be done by using Bitcoins to impose this economic cost.
All economic costs resolve to energy (economic tokens represent "right-to-consume-energy", by the simple technique of purchasing energy), thus requiring a fee is equivalent to requiring proof-of-work, incentive-wise.
The drawback is that proof-of-work is cheaper for specialized hardware (as well as specialized setups for getting more energy at cheaper costs).
As hardware specialization for the specific Lightning-Network-proof-of-work arises, we will find that to practically limit spam, intermediate nodes will have to increase and increase the threshold for accepting proof-of-work, as spammers are going to switch to the more-specialized hardware.
This leads to certain kinds of hardware (older mobile phones, older workstations, etc.) being unable to practically use the Lightning Network due to the increased proof-of-work threshold.
Eventually, services will arise where datacenters of specialized hardware are rented out to Lighning Network nodes for a fee in exchange for a proof-of-work to be used on a route --- datacenters that may very well end up becoming kingmakers capable of allowing or suppressing certain economic activities.
This ends up being indirect and loses a good amount of privacy.
It is better to simply impose *some* cost on the sender that it pays directly, than to use a mechanism that inherently leads to specialization.
Regards,
ZmnSCPxj
>
> 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
📝 Original message:
Good morning Bastien,
> 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.
This imposes a cost that varies depending on how specialized your hardware is at generating proof-of-work.
At a certain point-of-view, one can argue that directly paying with millisatoshis for each hop (whether it fails to forward or not) has the same cost on the sender (replace the consumption of energy to compute proof-of-work with a payment or burning of funds instead), and at least does not prejudice against sender hardware that is not specialized at generating proof-of-work.
Thus I would argue that, given we already have a system that bases an economic token on top of proof-of-work, every use of proof-of-work today (other than to power Bitcoin itself, as Bitcoin cannot support itself) can instead be done by using Bitcoins to impose this economic cost.
All economic costs resolve to energy (economic tokens represent "right-to-consume-energy", by the simple technique of purchasing energy), thus requiring a fee is equivalent to requiring proof-of-work, incentive-wise.
The drawback is that proof-of-work is cheaper for specialized hardware (as well as specialized setups for getting more energy at cheaper costs).
As hardware specialization for the specific Lightning-Network-proof-of-work arises, we will find that to practically limit spam, intermediate nodes will have to increase and increase the threshold for accepting proof-of-work, as spammers are going to switch to the more-specialized hardware.
This leads to certain kinds of hardware (older mobile phones, older workstations, etc.) being unable to practically use the Lightning Network due to the increased proof-of-work threshold.
Eventually, services will arise where datacenters of specialized hardware are rented out to Lighning Network nodes for a fee in exchange for a proof-of-work to be used on a route --- datacenters that may very well end up becoming kingmakers capable of allowing or suppressing certain economic activities.
This ends up being indirect and loses a good amount of privacy.
It is better to simply impose *some* cost on the sender that it pays directly, than to use a mechanism that inherently leads to specialization.
Regards,
ZmnSCPxj
>
> 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