10 ms·

If the proof-of-work system is actually a crypto miner, such that visitors end up paying the site for the content they host, have we finally converged on a work

If the proof-of-work system is actually a crypto miner, such that visitors end up paying the site for the content they host, have we finally converged on a working implementation of the micropayments-for-websites concepts of decades ago?

diggan 1y ago
> If the proof-of-work system is actually a crypto miner, such that visitors end up paying the site for the content they host Unsure how that would work. If the proof you generate could be used for blockchain operations, so that the website operator could be paid by using that proof as generated by the website visitor, why shouldn't the visitor keep that proof to themselves and use it instead? Then they'd get the full amount, and the website operator gets nothing. So then there is no point for it, and the visitor might as well just run a miner locally :)
- Retr0id 1y ago
  If the user mined it themselves and then paid the site owner before accessing the site, they'd have to pay a transaction fee and wait for a high-latency transaction to commit. The transaction fee could dwarf the actual payment value. Mining on behalf of the site owner negates the need for a transaction entirely.
  - viraptor 1y ago
    (unnecessary)
    - Retr0id 1y ago
      I know this.
      - viraptor 1y ago
        Responded to wrong comment, sorry
- odo1242 1y ago
  The company Coinhive used to do this before they shut down. Basically, in order to enter a website, you have to provide the website with a certain number of Monero hashes (usually around 1,024) that the website would send to Coinhive’s miner pool before letting the user through. It kinda worked, except for the fact that hackers would try to “cryptojack” random websites by hacking them and inserting Coinhive’s miner into their pages. This caused everyone to block Coinhive’s servers. (Also you wouldn’t get very much money out of it - even the cryptojackers who managed to get tens of millions of page views out of hacked websites reported they only made ~$40 from the operation)
  - kbenson 1y ago
    If attackers only made ~$40 fora good amount of work, seems like it would have resolved itself if the scheme was left to run itself to conclusion before people started blocking coinhive in (what sounds like from your description) a knee-jerk reaction. Then again, I'm sure there's quite a bit of tweaking that could be done to make clients submit far more hashes, but that would make it much more noticeable.
  - hoppp 1y ago
    That $40 now coud be in the thousands if they didn't spend it Xmr was cheaper back then.
- viraptor 1y ago
  Have a look at how mining pools are implemented. The client only gets to change some part of the block and does the hashing from there. You can't go back from that to change the original data - you wouldn't get paid. Otherwise you could easily scam the mining pool and always keep the winning numbers to yourself while getting paid for the partials too.
  - mistercow 1y ago
    Just to make sure I understand this (and maybe clarify for others too), because my understanding of proof-of-work systems is very high level: When you mine a block, you’re basically bundling up a bunch of meaningful data, and then trying to append some padding data that will e.g. result in a hash that has N leading 0 bits. One of the pieces of meaningful data in the block is “who gets the reward?” If you’re mining alone, you would put data on that block that says “me” as who gets the reward. But if you’re mining for a pool, you get a block that already says “the pool” for who gets the reward. So then I’m guessing the pool gives you a lesser work factor to hit, so some value smaller than N? You’ll be basically saying “Well, here’s a block that doesn’t have N leading zeroes, but does have M, leading zeroes”, and that proves how much you’re working for the pool, and entitles you to a proportion of the winnings. If you changed the “who gets the reward?” from “the pool” to “me”, that would change the hash. So you can’t come in after the fact, say “Look at that! N leading zeroes! Let me just swap myself in to get the reward…” because that would result in an invalid block. And if you put yourself as the reward line in advance, the pool just won’t give you credit for your “partial” answers. Is that about right?
    - mistercow 1y ago
      Just to tack onto this, the one thing you could do is just deny real rewards. If someone wants you to take part in their pool in order to load a webpage, you could just refuse to submit any block that will actually pay out. This wouldn’t benefit you, but it would punish them for trying to make you spend resources on their behalf. I wonder if there’s a way to prevent that.
- lurkshark 1y ago
  This system actually existed for awhile, it was called Coinhive. Each visitor would be treated like a node in a mining pool with “credit” for the resources going to the site owner. Somewhat predictably it became primarily used by hackers who would inject the code on high profile sites or use advertising networks. https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive/ https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive...
  - xd1936 1y ago
    The domain is now owned by Troy Hunt! https://www.troyhunt.com/i-now-own-the-coinhive-domain-heres-how-im-fighting-cryptojacking-and-doing-good-things-with-content-security-policies/ https://www.troyhunt.com/i-now-own-the-coinhive-domain-heres...
- SilasX 1y ago
  From my understanding: to pose the problem for miners, you hash the block you're planning to submit (which includes all the proposed transactions). Miners only get the hash. To claim the reward, you need the preimage (i.e. block to be submitted), which miners don't have. In theory, you could watch the transactions being broadcast, and guess (+confirm) the corresponding block, but that would require you to see all the transactions the pool owner did, and put them in the same order (the possibilities of which scale exponentially with the number of transactions). There may be some other randomness you can insert into a block too -- someone else might know this. Edit: oops, I forgot: the block also contains the address that the fees should be sent to. So even if you "stole" your solution and broadcast it with the block, the fee is still going to the pool owner. That's a bigger deal.
- deleted 1y ago
  [deleted]
- moralestapia 1y ago
  Yeah, but then they wouldn't get your content? Duh.
- csense 1y ago
  > why shouldn't the visitor keep that proof to themselves and use it instead Because they can't, if the website operator designs their JavaScript correctly. In detail: If Alice goes to Bob's website, Bob tells Alice to find a hash with 20 leading zeros for a Bitcoin block that says "Send the newly printed bitcoins and transaction fees to Bob." (It will take Alice ~2^20 guesses to find such a block, so Bob picked the number 20 such that those ~2^20 guesses happen in a couple seconds for normal humans with normal web browsers on normal devices.) Supposing the actual Bitcoin blockchain needs a hash with 50 leading zeros, one in every 2^30 Alice's will mine a valid block (worth ~$300k at current Bitcoin prices). If Alice finds a block with 50 leading zeros and then tries to change the block to say "Send the newly printed bitcoins and transaction fees to Alice," her new block will have a different hash (that is very unlikely to have 2^50 leading zeros), and neither the website nor the blockchain will accept it. Sure, Alice could change the block at the beginning before starting the search. But if she finds a block with 20 leading zeros that says "Send the newly printed bitcoins and transaction fees to Alice," Bob won't accept it for access to his website. The only way Alice gets anything for a block that sends the coins to herself is from the Bitcoin blockchain if she finds a 2^50 block -- at that point, Alice is just mining Bitcoins for herself and not interacting with Bob's website at all. (If a 1 in a billion chance to win $300k is too risky for Bob's liking, he can get a lower payout with a higher probability by using a different proof-of-work blockchain and/or a mining pool.)
odo1242 1y ago
Not really, because it takes a LOT of hashes to actually get any crypto out of the system. Yes, you’re technically taking the user’s power and getting paid crypto, but unless you’re delaying the user for a long time, you’re only really being paid about a ten thousandth of a cent for a page visit. Also virus scanners and corporate networks would hate you, because hackers are probably trying to embed whatever library you’re using into other unsuspecting sites.
- jfengel 1y ago
  What does one actually get per page impression from Google Ads? I gather that it's more than a ten thousandth of a cent, but perhaps not all that much more.
  - 20after4 1y ago
    It used to be a few pennies per 1000 page views. But it's been more than 10 years since I had any insight into the details of internet ad revenue. (Also it's highly dependent on all kinds of contextual details about the content, the keywords, and the specific ads you wind up serving)
DocTomoe 1y ago
[flagged]
- shkkmo 1y ago
  The doxxing is questinable, but much less questionable than your presentation of events. Coinhive earned 35% of everything mined on any site, not just the image board. They had no means stopping malicious installations from stealing from users. This provided hackers financial incenctive to compromise as many sites as possible and Coinhive's incentives were aligned with this. The choice on Monero as the base blockchain made it pretty clear what the intentions were. > Lessons learned: Good ideas in paying for your content needs to pass the outrage culture test. And Krebs is ... not a honest news source. Don't create tools clearly intended to facilitate criminal activity, make money off of it, and expect every to be OK with it.
- rcxdude 1y ago
  It's not actually a good idea, though. It's basically just banditry: the cost to the users it much more than the value to the benefactor, and there's not much they can do about it. (to be fair, the super invasive tracking ad systems that now exist have the same problem, but it's not obvious that they're worse).
msgodel 1y ago
It would be nice if this could get standardized http headers so bots could still use sites but they effectively pay for use. That seems like the best of all possible worlds to me, the whole point of HTML is that robots can read it, otherwise we'd just be emailing eachother pdfs.
- ramses0 1y ago
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... ...and the requisite checklist: https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wont-work-checklist/ https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wo...
  - msgodel 1y ago
    Formalizing it doesn't change that it's being used. If it doesn't work it shouldn't be done, if it does it should be formalized.
- overfeed 1y ago
  > bots could still use sites but they effectively pay for use. That seems like the best of all possible worlds to me This would make the entire internet a maze of AI-slop content primarily made for other bots to consume. Humans may have to resort to emailing handwritten PDFs to avoid the thoroughly enshittified web.
  - dandelany 1y ago
    As opposed to what we have now?
    - overfeed 1y ago
      Yes - things could get worse from the status quo. At the moment, ad networks don't pay for bot impressions when detected - so content farms tend to optimize for what passes for humans. All bets are off if human and bot visitors offer the same economic value via miners, or worse if it turns out that bots are more profitable due to human impatience. Imagine an internet optimized for bot visitors, and indifferent to humans. It would be a kind of refined brainrot aimed at a brainless audience.
kmeisthax 1y ago
The problem with micropayments was fourfold: 1. Banner ads made more money. This stopped being true a while ago, it's why newspapers all have annoying soft paywalls now. 2. People didn't have payment rails set up for e-commerce back then. Largely fixed now, at least for adults in the US. 3. Transactions have fixed processing costs that make anything <$1 too cheap to transact. Fixed with batching (e.g. buy $5 of credit and spend it over time). 4. Having to approve each micropurchase imposes a fixed mental transaction cost that outweighs the actual cost of the individual item. Difficult to solve ethically. With the exception of, arguably[0], Patreon, all of these hurdles proved fatal to microtransactions as a means to sell web content. Games are an exception, but they solved the problem of mental transaction costs by drowning it in intensely unethical dark patterns protected by shittons of DRM[1]. You basically have to make someone press the spend button without thinking. The way these proof-of-work systems are currently implemented, you're effectively taking away the buy button and just charging someone the moment they hit the page. This is ethically dubious, at least as ethically dubious as 'data caps[2]' in terms of how much affordance you give the user to manage their spending: none. Furthermore, if we use a proof-of-work system that's shared with an actual cryptocurrency, so as to actually get payment from these hashes, then we have a new problem: ASICs. Cryptocurrencies have to be secured by a globally agreed-upon hash function, and changing that global consensus to a new hash function is very difficult. And those hashes have economic value. So it makes lots of sense to go build custom hardware just to crack hashes faster and claim more of the inflation schedule and on-chain fees. If ASICs exist for a given hash function, then proof-of-work fails at both: - Being an antispam system, since spammers will have better hardware than legitimate users[3] - Being a billing system, since legitimate users won't be able to mine enough crypto to pay any economically viable amount of money If you don't insist on using proof-of-work as billing, and only as antispam, then you can invent whatever tortured mess of a hash function is incompatible with commonly available mining ASICs. And since they don't have to be globally agreed-upon, everyone can use a different, incompatible hash function. "Don't roll your own crypto" is usually good security advice, but in this case, we're not doing security, we're doing DRM. The same fundamental constants of computing that make stopping you from copying a movie off Netflix a fool's errand also make stopping scrapers theoretically impossible. The only reason why DRM works is because of the gap between theory and practice: technically unsophisticated actors can be stopped by theoretically dubious usages of cryptography. And boy howdy are LLM scrapers unsophisticated. But using the tried-and-true solutions means they don't have to be: they can just grab off-the-shelf solutions for cracking hashes and break whatever you use. [0] At least until Apple cracked Patreon's kneecaps and made them drop support for any billing mode Apple's shitty commerce system couldn't handle. [1] At the very least, you can't sell microtransaction items in games without criminalizing cheat devices that had previously been perfectly legal for offline use. Half the shit you sell in a cash shop is just what used to be a GameShark code. [2] To be clear, the units in which Internet connections are sold should be kbps, not GB/mo. Every connection already has a bandwidth limit, so what ISPs are doing when they sell you a plan with a data cap is a bait and switch. Two caps means the lower cap is actually a link utilization cap, hidden behind a math problem. [3] A similar problem has arisen in e-mail, where spammy domains have perfect DKIM/SPF, while good senders tend to not care about e-mail bureaucracy and thus look worse to antispam systems.
bdcravens 1y ago
There were some Javascript-based embedded miners in the early days of Bitcoin https://web.archive.org/web/20110603143708/http://www.bitcoinplus.com/miner/embeddable https://web.archive.org/web/20110603143708/http://www.bitcoi...

diggan 1y ago

> If the proof-of-work system is actually a crypto miner, such that visitors end up paying the site for the content they host Unsure how that would work. If the proof you generate could be used for blockchain operations, so that the website operator could be paid by using that proof as generated by the website visitor, why shouldn't the visitor keep that proof to themselves and use it instead? Then they'd get the full amount, and the website operator gets nothing. So then there is no point for it, and the visitor might as well just run a miner locally :)

Retr0id 1y ago
If the user mined it themselves and then paid the site owner before accessing the site, they'd have to pay a transaction fee and wait for a high-latency transaction to commit. The transaction fee could dwarf the actual payment value. Mining on behalf of the site owner negates the need for a transaction entirely.
- viraptor 1y ago
  (unnecessary)
  - Retr0id 1y ago
    I know this.
    - viraptor 1y ago
      Responded to wrong comment, sorry
odo1242 1y ago
The company Coinhive used to do this before they shut down. Basically, in order to enter a website, you have to provide the website with a certain number of Monero hashes (usually around 1,024) that the website would send to Coinhive’s miner pool before letting the user through. It kinda worked, except for the fact that hackers would try to “cryptojack” random websites by hacking them and inserting Coinhive’s miner into their pages. This caused everyone to block Coinhive’s servers. (Also you wouldn’t get very much money out of it - even the cryptojackers who managed to get tens of millions of page views out of hacked websites reported they only made ~$40 from the operation)
- kbenson 1y ago
  If attackers only made ~$40 fora good amount of work, seems like it would have resolved itself if the scheme was left to run itself to conclusion before people started blocking coinhive in (what sounds like from your description) a knee-jerk reaction. Then again, I'm sure there's quite a bit of tweaking that could be done to make clients submit far more hashes, but that would make it much more noticeable.
- hoppp 1y ago
  That $40 now coud be in the thousands if they didn't spend it Xmr was cheaper back then.
viraptor 1y ago
Have a look at how mining pools are implemented. The client only gets to change some part of the block and does the hashing from there. You can't go back from that to change the original data - you wouldn't get paid. Otherwise you could easily scam the mining pool and always keep the winning numbers to yourself while getting paid for the partials too.
- mistercow 1y ago
  Just to make sure I understand this (and maybe clarify for others too), because my understanding of proof-of-work systems is very high level: When you mine a block, you’re basically bundling up a bunch of meaningful data, and then trying to append some padding data that will e.g. result in a hash that has N leading 0 bits. One of the pieces of meaningful data in the block is “who gets the reward?” If you’re mining alone, you would put data on that block that says “me” as who gets the reward. But if you’re mining for a pool, you get a block that already says “the pool” for who gets the reward. So then I’m guessing the pool gives you a lesser work factor to hit, so some value smaller than N? You’ll be basically saying “Well, here’s a block that doesn’t have N leading zeroes, but does have M, leading zeroes”, and that proves how much you’re working for the pool, and entitles you to a proportion of the winnings. If you changed the “who gets the reward?” from “the pool” to “me”, that would change the hash. So you can’t come in after the fact, say “Look at that! N leading zeroes! Let me just swap myself in to get the reward…” because that would result in an invalid block. And if you put yourself as the reward line in advance, the pool just won’t give you credit for your “partial” answers. Is that about right?
  - mistercow 1y ago
    Just to tack onto this, the one thing you could do is just deny real rewards. If someone wants you to take part in their pool in order to load a webpage, you could just refuse to submit any block that will actually pay out. This wouldn’t benefit you, but it would punish them for trying to make you spend resources on their behalf. I wonder if there’s a way to prevent that.
lurkshark 1y ago
This system actually existed for awhile, it was called Coinhive. Each visitor would be treated like a node in a mining pool with “credit” for the resources going to the site owner. Somewhat predictably it became primarily used by hackers who would inject the code on high profile sites or use advertising networks. https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive/ https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive...
- xd1936 1y ago
  The domain is now owned by Troy Hunt! https://www.troyhunt.com/i-now-own-the-coinhive-domain-heres-how-im-fighting-cryptojacking-and-doing-good-things-with-content-security-policies/ https://www.troyhunt.com/i-now-own-the-coinhive-domain-heres...
SilasX 1y ago
From my understanding: to pose the problem for miners, you hash the block you're planning to submit (which includes all the proposed transactions). Miners only get the hash. To claim the reward, you need the preimage (i.e. block to be submitted), which miners don't have. In theory, you could watch the transactions being broadcast, and guess (+confirm) the corresponding block, but that would require you to see all the transactions the pool owner did, and put them in the same order (the possibilities of which scale exponentially with the number of transactions). There may be some other randomness you can insert into a block too -- someone else might know this. Edit: oops, I forgot: the block also contains the address that the fees should be sent to. So even if you "stole" your solution and broadcast it with the block, the fee is still going to the pool owner. That's a bigger deal.
deleted 1y ago
[deleted]
moralestapia 1y ago
Yeah, but then they wouldn't get your content? Duh.
csense 1y ago
> why shouldn't the visitor keep that proof to themselves and use it instead Because they can't, if the website operator designs their JavaScript correctly. In detail: If Alice goes to Bob's website, Bob tells Alice to find a hash with 20 leading zeros for a Bitcoin block that says "Send the newly printed bitcoins and transaction fees to Bob." (It will take Alice ~2^20 guesses to find such a block, so Bob picked the number 20 such that those ~2^20 guesses happen in a couple seconds for normal humans with normal web browsers on normal devices.) Supposing the actual Bitcoin blockchain needs a hash with 50 leading zeros, one in every 2^30 Alice's will mine a valid block (worth ~$300k at current Bitcoin prices). If Alice finds a block with 50 leading zeros and then tries to change the block to say "Send the newly printed bitcoins and transaction fees to Alice," her new block will have a different hash (that is very unlikely to have 2^50 leading zeros), and neither the website nor the blockchain will accept it. Sure, Alice could change the block at the beginning before starting the search. But if she finds a block with 20 leading zeros that says "Send the newly printed bitcoins and transaction fees to Alice," Bob won't accept it for access to his website. The only way Alice gets anything for a block that sends the coins to herself is from the Bitcoin blockchain if she finds a 2^50 block -- at that point, Alice is just mining Bitcoins for herself and not interacting with Bob's website at all. (If a 1 in a billion chance to win $300k is too risky for Bob's liking, he can get a lower payout with a higher probability by using a different proof-of-work blockchain and/or a mining pool.)

odo1242 1y ago

Not really, because it takes a LOT of hashes to actually get any crypto out of the system. Yes, you’re technically taking the user’s power and getting paid crypto, but unless you’re delaying the user for a long time, you’re only really being paid about a ten thousandth of a cent for a page visit. Also virus scanners and corporate networks would hate you, because hackers are probably trying to embed whatever library you’re using into other unsuspecting sites.

jfengel 1y ago
What does one actually get per page impression from Google Ads? I gather that it's more than a ten thousandth of a cent, but perhaps not all that much more.
- 20after4 1y ago
  It used to be a few pennies per 1000 page views. But it's been more than 10 years since I had any insight into the details of internet ad revenue. (Also it's highly dependent on all kinds of contextual details about the content, the keywords, and the specific ads you wind up serving)

DocTomoe 1y ago

[flagged]

shkkmo 1y ago
The doxxing is questinable, but much less questionable than your presentation of events. Coinhive earned 35% of everything mined on any site, not just the image board. They had no means stopping malicious installations from stealing from users. This provided hackers financial incenctive to compromise as many sites as possible and Coinhive's incentives were aligned with this. The choice on Monero as the base blockchain made it pretty clear what the intentions were. > Lessons learned: Good ideas in paying for your content needs to pass the outrage culture test. And Krebs is ... not a honest news source. Don't create tools clearly intended to facilitate criminal activity, make money off of it, and expect every to be OK with it.
rcxdude 1y ago
It's not actually a good idea, though. It's basically just banditry: the cost to the users it much more than the value to the benefactor, and there's not much they can do about it. (to be fair, the super invasive tracking ad systems that now exist have the same problem, but it's not obvious that they're worse).

msgodel 1y ago

It would be nice if this could get standardized http headers so bots could still use sites but they effectively pay for use. That seems like the best of all possible worlds to me, the whole point of HTML is that robots can read it, otherwise we'd just be emailing eachother pdfs.

ramses0 1y ago
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... ...and the requisite checklist: https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wont-work-checklist/ https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wo...
- msgodel 1y ago
  Formalizing it doesn't change that it's being used. If it doesn't work it shouldn't be done, if it does it should be formalized.
overfeed 1y ago
> bots could still use sites but they effectively pay for use. That seems like the best of all possible worlds to me This would make the entire internet a maze of AI-slop content primarily made for other bots to consume. Humans may have to resort to emailing handwritten PDFs to avoid the thoroughly enshittified web.
- dandelany 1y ago
  As opposed to what we have now?
  - overfeed 1y ago
    Yes - things could get worse from the status quo. At the moment, ad networks don't pay for bot impressions when detected - so content farms tend to optimize for what passes for humans. All bets are off if human and bot visitors offer the same economic value via miners, or worse if it turns out that bots are more profitable due to human impatience. Imagine an internet optimized for bot visitors, and indifferent to humans. It would be a kind of refined brainrot aimed at a brainless audience.

kmeisthax 1y ago

The problem with micropayments was fourfold: 1. Banner ads made more money. This stopped being true a while ago, it's why newspapers all have annoying soft paywalls now. 2. People didn't have payment rails set up for e-commerce back then. Largely fixed now, at least for adults in the US. 3. Transactions have fixed processing costs that make anything <$1 too cheap to transact. Fixed with batching (e.g. buy $5 of credit and spend it over time). 4. Having to approve each micropurchase imposes a fixed mental transaction cost that outweighs the actual cost of the individual item. Difficult to solve ethically. With the exception of, arguably[0], Patreon, all of these hurdles proved fatal to microtransactions as a means to sell web content. Games are an exception, but they solved the problem of mental transaction costs by drowning it in intensely unethical dark patterns protected by shittons of DRM[1]. You basically have to make someone press the spend button without thinking. The way these proof-of-work systems are currently implemented, you're effectively taking away the buy button and just charging someone the moment they hit the page. This is ethically dubious, at least as ethically dubious as 'data caps[2]' in terms of how much affordance you give the user to manage their spending: none. Furthermore, if we use a proof-of-work system that's shared with an actual cryptocurrency, so as to actually get payment from these hashes, then we have a new problem: ASICs. Cryptocurrencies have to be secured by a globally agreed-upon hash function, and changing that global consensus to a new hash function is very difficult. And those hashes have economic value. So it makes lots of sense to go build custom hardware just to crack hashes faster and claim more of the inflation schedule and on-chain fees. If ASICs exist for a given hash function, then proof-of-work fails at both: - Being an antispam system, since spammers will have better hardware than legitimate users[3] - Being a billing system, since legitimate users won't be able to mine enough crypto to pay any economically viable amount of money If you don't insist on using proof-of-work as billing, and only as antispam, then you can invent whatever tortured mess of a hash function is incompatible with commonly available mining ASICs. And since they don't have to be globally agreed-upon, everyone can use a different, incompatible hash function. "Don't roll your own crypto" is usually good security advice, but in this case, we're not doing security, we're doing DRM. The same fundamental constants of computing that make stopping you from copying a movie off Netflix a fool's errand also make stopping scrapers theoretically impossible. The only reason why DRM works is because of the gap between theory and practice: technically unsophisticated actors can be stopped by theoretically dubious usages of cryptography. And boy howdy are LLM scrapers unsophisticated. But using the tried-and-true solutions means they don't have to be: they can just grab off-the-shelf solutions for cracking hashes and break whatever you use. [0] At least until Apple cracked Patreon's kneecaps and made them drop support for any billing mode Apple's shitty commerce system couldn't handle. [1] At the very least, you can't sell microtransaction items in games without criminalizing cheat devices that had previously been perfectly legal for offline use. Half the shit you sell in a cash shop is just what used to be a GameShark code. [2] To be clear, the units in which Internet connections are sold should be kbps, not GB/mo. Every connection already has a bandwidth limit, so what ISPs are doing when they sell you a plan with a data cap is a bait and switch. Two caps means the lower cap is actually a link utilization cap, hidden behind a math problem. [3] A similar problem has arisen in e-mail, where spammy domains have perfect DKIM/SPF, while good senders tend to not care about e-mail bureaucracy and thus look worse to antispam systems.

bdcravens 1y ago

There were some Javascript-based embedded miners in the early days of Bitcoin https://web.archive.org/web/20110603143708/http://www.bitcoinplus.com/miner/embeddable https://web.archive.org/web/20110603143708/http://www.bitcoi...