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

Let us serve you, but don't bring us down

blog.archive.org

Post reply on HN
Print view View original

81–90 of 255 posts

Re: Let us serve you, but don't bring us down

#81

Post by Leo_Germond »

emporas wrote: post #61
8organicbits wrote: post #47

Earlier quoted context omitted.

Really interesting! How efficiently does a web browser compute the PoW? I'm concerned that a bot would use an efficient GPU implementation while real users would run an inefficient JS/webcrypto version.

Requiring every user to compute it's own PoW is a terrible idea. It defeats the whole purpose. One's person expensive computation is another person's almost free computation. I commented in the past about it: "At first glance, yes, we can create intentionally expensive computations without relying on a blockchain, that would serve the same purpose. In reality we cannot. Special computer hardware (ASICs) could generat…

Specialized ASICs are not easy to come up with, what's more if it's in a tug of war you can expect those to suddenly become obsolete, rendering this approach too costly for a scrapper. Also you may have missed the part in the original link where they were using AWS to do the scrapping, so no ASICs there, and you pay by the minute, two things that would make PoW a valid countermeasure, no "free computation" in that setup.

Re: Let us serve you, but don't bring us down

#82

Post by 8organicbits »

emporas wrote: post #61
8organicbits wrote: post #47

Earlier quoted context omitted.

Really interesting! How efficiently does a web browser compute the PoW? I'm concerned that a bot would use an efficient GPU implementation while real users would run an inefficient JS/webcrypto version.

Requiring every user to compute it's own PoW is a terrible idea. It defeats the whole purpose. One's person expensive computation is another person's almost free computation. I commented in the past about it: "At first glance, yes, we can create intentionally expensive computations without relying on a blockchain, that would serve the same purpose. In reality we cannot. Special computer hardware (ASICs) could generat…

Looking cross-comment I think you're advocating for micro-payments or micro-proof-of-burn. This is better than having every user compute their own PoW as they'd purchase a small amount of cryptocurrency from an ASIC farm, which should be cheaper/faster/more efficient than using their local hardware. I mostly agree with the concept, but I don't think any such API exists yet with enough adoption to consider this a real option any time soon.

Right now, if I was to ask my users to do a proof of burn for $0.0001 of BTC most of them would just close my site as they don't have any BTC. The process of setting up an account on an exchange, waiting several hours/days for KYC checks to clear, adding a credit card, buying BTC, sending it to a browser extension, and then trying the signup again is a *significant* initial hurdle. If we were in a world where I could assume all my users already owned BTC, that's a different story, but we haven't seen adoption of cryptocurrency anywhere near that level. I don't expect PoW schemes to drive that adoption either, so this seems like a poor solution today.

Do you happen to know if a hCaptcha/mCaptcha-like micro-proof-of-burn tool exists already? I'd be happy to be proven wrong.

That brings us back to options that exist today, which includes every user computing their own PoW. Looking at mCaptcha some more, it uses a SHA256 derivative so it's compute-hard and vulnerable to GPUs/ASICs. The author mentions some of those concerns in an earlier thread [1]. I wonder if a different proof-of-work algorithm would be better, like a memory-hard PoW, proof-of-space, and/or proof-of-wait. I'm skeptical of those too, unfortunately.

[1] https://news.ycombinator.com/item?id=32341446

Re: Let us serve you, but don't bring us down

#83

Post by chronogram »

maksimur wrote: post #75
x-complexity wrote: post #26

Unpopular opinion: Severely rate limit retrieving the files from the website / HTTP endpoint, and loudly point towards downloading the files via torrents. The torrent protocol was meant to relieve this level of server load in mind.

Torrents have the habit of disappearing when no users keep them alive. It happened to me enough times to be wary of such solution. If there's a way to keep them alive regardless of interest I'm all for it.

Have you tried an Archive.org torrent yet? It's backed by the servers, but has the advantages of selecting which parts of the archive you want and being verifiable and being able to have more bandwidth on popular archives. The Archive.org servers show up on the "HTTP sources" tab next to the "Peers" tab for me.

Re: Let us serve you, but don't bring us down

#84

Post by WA »

pfooti wrote: post #5

I run a system at my employer that occasionally gets scraped by malicious users. It can be used to infer the purchasability of a specific domain, which is a moderately-interesting API endpoint, since that requires talking to domain registries. For a while, nobody cared enough about it to abuse the endpoint. But then we started getting about 40 QPS of traffic. We normally get less than 1. I was keeping an eye on it, b…

I usually make it a two step process:

  host example.com
If this returns with an IP address, no need to talk to a registrar. Only if there is no IP address, I go with

  whois example.com

Re: Let us serve you, but don't bring us down

#85

Post by happywolf »

maksimur wrote: post #75
x-complexity wrote: post #26

Unpopular opinion: Severely rate limit retrieving the files from the website / HTTP endpoint, and loudly point towards downloading the files via torrents. The torrent protocol was meant to relieve this level of server load in mind.

Torrents have the habit of disappearing when no users keep them alive. It happened to me enough times to be wary of such solution. If there's a way to keep them alive regardless of interest I'm all for it.

Seeding peers or machines are meant to mitigate this issue.

Re: Let us serve you, but don't bring us down

#86

Post by tornato7 »

emporas wrote: post #61
8organicbits wrote: post #47

Earlier quoted context omitted.

Really interesting! How efficiently does a web browser compute the PoW? I'm concerned that a bot would use an efficient GPU implementation while real users would run an inefficient JS/webcrypto version.

Requiring every user to compute it's own PoW is a terrible idea. It defeats the whole purpose. One's person expensive computation is another person's almost free computation. I commented in the past about it: "At first glance, yes, we can create intentionally expensive computations without relying on a blockchain, that would serve the same purpose. In reality we cannot. Special computer hardware (ASICs) could generat…

Ethereum was pretty successfully ASIC-resistant. Other PoW algorithms are GPU-resistant. Even so, I doubt most spammers are sophisticated enough to create ASICs just to make cheaper requests to this guy's service.

Re: Let us serve you, but don't bring us down

#87

Post by 8organicbits »

emporas wrote: post #79
elcomet wrote: post #76

Earlier quoted context omitted.

So maybe you should link to the one you are referring to, if there are three projects with the same name.

I am talking about Bitcoin BSV. If the purpose of blockchain was solely to provide PoW, then there could exist a lot of blockchains, a thousand maybe. Economic incentives ensure that the most inefficient of blockchains will be put out of the market. So some of them, like btc will soon be put out of the market, because speed and microtransactions is the two factors every blockchain competes on. https://www.binance.com…

> This coin is not listed on Binance for trade and service.

An obscure coin my users cannot purchase through major exchanges is a really poor solution. Sorry, that makes no sense.

Re: Let us serve you, but don't bring us down

#88

Post by emporas »

Leo_Germond wrote: post #81
emporas wrote: post #61

Earlier quoted context omitted.

Requiring every user to compute it's own PoW is a terrible idea. It defeats the whole purpose. One's person expensive computation is another person's almost free computation. I commented in the past about it: "At first glance, yes, we can create intentionally expensive computations without relying on a blockchain, that would serve the same purpose. In reality we cannot. Special computer hardware (ASICs) could generat…

Specialized ASICs are not easy to come up with, what's more if it's in a tug of war you can expect those to suddenly become obsolete, rendering this approach too costly for a scrapper. Also you may have missed the part in the original link where they were using AWS to do the scrapping, so no ASICs there, and you pay by the minute, two things that would make PoW a valid countermeasure, no "free computation" in that se…

As far as i know, btc and ethereum actively fight the ASICs, because they will diminish the profits of amateur miners, and will bring great centralization to the network. Which is true, and it is no problem.

Re: Let us serve you, but don't bring us down

#89

Post by Alifatisk »

tastysandwich wrote: post #33

I have a side project that scrapes thousands and thousands of pages of a single website. So as not to piss them off (and so they don't try to block me), my script will take about 6 hours. Between each page fetch it sleeps for a small, random amount of time. It's been working like that for years.

Wish more people did like you!

Re: Let us serve you, but don't bring us down

#90

Post by emporas »

8organicbits wrote: post #82
emporas wrote: post #61

Earlier quoted context omitted.

Requiring every user to compute it's own PoW is a terrible idea. It defeats the whole purpose. One's person expensive computation is another person's almost free computation. I commented in the past about it: "At first glance, yes, we can create intentionally expensive computations without relying on a blockchain, that would serve the same purpose. In reality we cannot. Special computer hardware (ASICs) could generat…

Looking cross-comment I think you're advocating for micro-payments or micro-proof-of-burn. This is better than having every user compute their own PoW as they'd purchase a small amount of cryptocurrency from an ASIC farm, which should be cheaper/faster/more efficient than using their local hardware. I mostly agree with the concept, but I don't think any such API exists yet with enough adoption to consider this a real…

You are right in most of your points. Today it doesn't exist an API for micro_proof_of_burn. Economic incentives however require a little patience because they need to work their way through the system. 0.0001 BTC is hugely expensive. A blockchain with millionth of a cent transaction, is certainly possible, and it will exist in 2-3 years approximately.

In my calculations, with millionth of a cent per transaction, even paying for torrent blocks (64 KB), not torrent pieces (16KB) will soon become profitable.

Post reply on HN