Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof-of-Work Defense for Onion Services

blog.torproject.org

Post reply on HN
Print view View original

71–80 of 159 posts

Re: Proof-of-Work Defense for Onion Services

#71

Post by IngvarLynn »

Uptrenda wrote: post #63

I'm wondering if there is a more elegant way to solve sybil attacks here. For example: many CPUs are provisioned with key pairs that are unique to the processor and can be verified with the CA root cert of the issuer (Intel, AMD, etc.) You could tie PoW to successive signing and allow it to be verified in parallel. Then the operation couldn't be parallelized to a botnet as all PoWs would be unique to a CPU. It seems…

DDoS has nothing to do with sybil attacks. DoS happens because limited resource (connection initiation) is provided for free.

They chose memory-hungry algorithm because that would prevent use of specific hardware (ASICs).

Re: Proof-of-Work Defense for Onion Services

#72

Post by kevinak »

jrajav wrote: post #56
kevinak wrote: post #51

Earlier quoted context omitted.

[flagged]

This stinks of hollywood accounting, like a lot of "negative carbon" plans for things that would otherwise be nonsensical for. The premise here is that if Bitcoin mining uses an energy source that inherently captures carbon or methane, then it's "carbon negative?" This ignores the fact that the energy budget is shared. We could just as well use that same energy for something else currently on carbon-based sources. So…

I don't think it does at all.

Burning methane has positive effects on global warming since methane is way way waaaaaaay worse than CO2. Taking care of landfills that are largely untouched, just spewing methane is a good thing. If Bitcoin ends up having a net-negative effect on global warming, how is that a bad thing?

You're assuming that all energy sources are well-connected to a grid that can handle the electricity that is generated, that's not the case at all. You can't "use that same energy for something else currently on carbon-based sources" without major infrastructure costs.

Re: Proof-of-Work Defense for Onion Services

#73

Post by kevinak »

foota wrote: post #60
kevinak wrote: post #51

Earlier quoted context omitted.

[flagged]

To the sibling, while I largely agree, I think there's some argument that building out additional manufacturing capacity for renewables even if it goes towards crypto mining has beneficial knock on effects for reducing the cost of the equipment provided that the learning curve effect and economies of scale outweigh the competition for resources, which to be fair isn't guaranteed.

It's mainly the fact that Bitcoin mining sets a price floor on electricity prices. It's a buyer of last resort. Without it you'll get negative electricity prices and less investment in renewables.

See for example what Ercot has to say about Bitcoin mining: https://www.youtube.com/watch?v=gKnRfDeFgr0

Re: Proof-of-Work Defense for Onion Services

#74

Post by synesso »

salawat wrote: post #36
8organicbits wrote: post #30

Really interesting! Digging into the proposal [1]: > make it harder for attackers to overload the service with introduction request > We hope that this proposal can help us defend against the script-kiddie attacker and small botnets. Sets expectations: does not counter large botnets. > We hope that this proposal will allow the motivated user to always connect A user who really wants to connect can get through durring…

So now you have the drawbacks of both as well, in that the guy who has the most compute to use as a toaster can DoS everyone else. Plus, PoW is nothing but wasted, needless computation . Computing is not free . Every watt spent doing anything PoW is just that much more intensification of our current climate crisis. As someone with temps of 109 with heat index of 120 coming in the next few days, with all due respect,…

This is an example of the common fallacy of conflating energy consumption with carbon-intensive energy generation.

Re: Proof-of-Work Defense for Onion Services

#75

Post by Proven »

IngvarLynn wrote: post #69

It's a shame that Torproject has decided to reinvent its own wheel, lagging 10 years behind the crypto crowd, instead of integrating with existing coin(s). The problem is, such integration would require the chosen coin to be anonymous, which is essentially forbidden: https://www.theverge.com/2023/8/23/23843161/tornado-cash-ind...

[dead]

Re: Proof-of-Work Defense for Onion Services

#76

Post by capableweb »

comex wrote: post #68
keyle wrote: post #64

Earlier quoted context omitted.

I never heard of CPP (client puzzle protocol) before. Interesting stuff. How can 'large botnets' go around this, by causing havok on other ports?

Probably by having enough computers that they can overload the server even if the number of requests coming from each individual computer is relatively low, as a multiple of what a normal user would send – low enough that those computers have enough CPU time to solve the challenges.

From https://github.com/tevador/equix/blob/master/devlog.md

> The service would give the request a priority value based on the "difficulty" of the puzzle solution.

Seems like single clients could increase the difficulty to higher than what the bot net would do (so it gets priority), and hence get access. Operators of the bot net would probably hard code one value as the difficulty, and it would be lower than what you could typically set on consumer hardware.

Maybe user agents could even do this increase automatically?

Re: Proof-of-Work Defense for Onion Services

#77

Post by Uptrenda »

IngvarLynn wrote: post #71
Uptrenda wrote: post #63

I'm wondering if there is a more elegant way to solve sybil attacks here. For example: many CPUs are provisioned with key pairs that are unique to the processor and can be verified with the CA root cert of the issuer (Intel, AMD, etc.) You could tie PoW to successive signing and allow it to be verified in parallel. Then the operation couldn't be parallelized to a botnet as all PoWs would be unique to a CPU. It seems…

DDoS has nothing to do with sybil attacks. DoS happens because limited resource (connection initiation) is provided for free. They chose memory-hungry algorithm because that would prevent use of specific hardware (ASICs).

Attackers can still outsource the PoWs. The sybil is the assumption that 1 PoW == one PC. But you can force this assumption with provisioning keys at least.

Re: Proof-of-Work Defense for Onion Services

#78

Post by foota »

kevinak wrote: post #73
foota wrote: post #60

Earlier quoted context omitted.

To the sibling, while I largely agree, I think there's some argument that building out additional manufacturing capacity for renewables even if it goes towards crypto mining has beneficial knock on effects for reducing the cost of the equipment provided that the learning curve effect and economies of scale outweigh the competition for resources, which to be fair isn't guaranteed.

It's mainly the fact that Bitcoin mining sets a price floor on electricity prices. It's a buyer of last resort. Without it you'll get negative electricity prices and less investment in renewables. See for example what Ercot has to say about Bitcoin mining: https://www.youtube.com/watch?v=gKnRfDeFgr0

Who needs batteries when you have Bitcoin?

Re: Proof-of-Work Defense for Onion Services

#80

Post by mjg59 »

Uptrenda wrote: post #63

I'm wondering if there is a more elegant way to solve sybil attacks here. For example: many CPUs are provisioned with key pairs that are unique to the processor and can be verified with the CA root cert of the issuer (Intel, AMD, etc.) You could tie PoW to successive signing and allow it to be verified in parallel. Then the operation couldn't be parallelized to a botnet as all PoWs would be unique to a CPU. It seems…

Proving your identity to an onion service in a way that can be tied to your use of other onion services feels like it might have bad outcomes?
Post reply on HN