Proof-of-Donation a compromise between Proof-of-Work and Micro-payments [LWN.net]

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 15, 2026 13:54 UTC (Wed) by gmatht (subscriber, #58961)
In reply to: UI automation is necessary for accessibility by farnz
Parent article: An update on the scraper situation

To serve an HTTPS page we already have to negotiate mutually trust CertAuthorities. It does not seem to be any harder to negotiate mutually trusted charities. Like Micropayments, Proof-of-Donation isn't just digging holes to fill them up again*. As to 1-3:

1. A bad-actor could transfer microcash that already been earmarked for charity to one of the wallet's owner's trusted charities, but it is not clear what this would achieve other than annoying people. A bad-actor who just wanted to be annoying could be much more annoying than that.
2. Like Proof-of-Work, you don't get your microcash/microwatts back. Just hope that "donating" a few bucks of your microcash was the worst the bad-actor did. Charities tend to be heavily regulated so it seems unlikely a "trusted charity" would be the bad actor, and they wouldn't be "trusted" for very long in any case.
3. N/A

In case people can't negotiate trusted authorities, can't be bothered setting up a microcash wallet (or it has been drained for some reason), one could still fall back on Proof-of-Work.

* It should be noted that in principle Proof-of-Work could involve asking users to solve problems that you are genuinely interested in the answer to (E.g. protein folding perhaps). However solving an interesting problem is probably too much work just to download a webpage, and might be better used as a way to bootstrap some sort of microdonation wallet rather than something you do for each random webhost you access.

to post comments

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 15, 2026 15:28 UTC (Wed) by farnz (subscriber, #17727) [Link] (10 responses)

The challenge is that most people don't negotiate certificate authorities; your browser author picks some for you, and you just expect HTTPS to work.

Asking people to set up a wallet is already a big deal; if that wallet's not one they're using anyway (which micropayments assume they will have), it's likely that they'll refuse. And for any "anti-scraper" measures to make a big difference, they need to become a social norm that everyone engages in, otherwise people will simply stop going to the sites that have anti-scraper measures, in favour of ones that don't.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 16, 2026 8:11 UTC (Thu) by taladar (subscriber, #68407) [Link]

It is not even just non-technical people who wouldn't. I know I would boycott sites like that out of principle unless they are extremely crucial (think government or health insurance services I can't avoid crucial) to my life.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 16, 2026 9:16 UTC (Thu) by gmatht (subscriber, #58961) [Link] (8 responses)

Well, there is no reason the browser couldn't pick a default set of charities either.

Manually Setting up a wallet is a pain. It might be easier to set up some sort of alt-coin mining wallet or some way of "spending" Folding@Home certificates etc (assuming they are fraud proof or can be made so, e.g. only giving certs for work than improves on an existing folding.) etc. This would seem nicer than being made to wait for several seconds of Proof-of-Work every other time I click on a webpage. (Hmm, in the meanwhile, would getting a Static IP help with that I wonder? CGNAT IP are probably treated like trash by webmins.)

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 16, 2026 9:26 UTC (Thu) by farnz (subscriber, #17727) [Link] (7 responses)

How, exactly, do you expect the browser to force me to donate to a set of charities, given that there are multiple open source options where someone can remove the "forced donation" code and re-release the browser without it?

With CAs, it's trivial - the browser picks trusted CAs, and I get the benefits of trusted CAs automatically, simply because the browser chose them. In a "proof of donation" situation, however, the thing I need is not a charity, but a donation - and unless the browser makes the donation on my behalf (from what fund of money, for example, and how does it ensure that it only donates for unique users), it doesn't work.

The hard part of all of the possible solutions is getting it past the apathetic and opposed so that it becomes part of the social norms. The easy part is the technical bits of showing that you've done something (a microtransaction, proof of work, mining a cryptocurrency, whatever).

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 8:42 UTC (Fri) by gmatht (subscriber, #58961) [Link] (6 responses)

'How, exactly, do you expect the browser to force me to donate to a set of charities, given that there are multiple open source options where someone can remove the "forced donation" code and re-release the browser without it?'

You absolutely could do that, assuming the browser even tried to force you. Then the web would fallback to work the way it does now, with many important websites regularly freezing up for a few seconds while forcing your browser to do Proof-of-Work, (or other nonsense like forcing you to do a Captcha just to view a single public facing webpage). Websites could instead deny you service entirely, but I imagine that would be rare. The webmaster might find Proof-of-Work wasteful, but if their goal is to rate-limit requests it may not make much difference to them whether they are limited by Proof-of-Donation, Proof-of-Work or Captcha.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 8:45 UTC (Fri) by farnz (subscriber, #17727) [Link] (5 responses)

But why would I bother doing proof of donation/work/payment if websites don't accept it yet? And why would websites move to proof of donation/work/payment if browsers don't do it yet?

There's a deep chicken-and-egg problem to solve here first, which is that when no user does the new thing, there's no incentive for websites to move away from what they do today; but when no website does the new thing, there's no incentive for users to put time and effort into a thing that does nothing for them. How do you break that cycle?

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 9:10 UTC (Fri) by gmatht (subscriber, #58961) [Link] (4 responses)

Well, the chicken and egg problem is common to every new feature, and many browsers support versions of HTML past 1.0.

The only real challenge is how do we make setting up a wallet trivially easy (as in a user shouldn't even have to know it is there; for proof-of-donation the webmaster doesn't even need a wallet). I guess the first stage would be to just have sort of proof-of-work coin so that you could save up proof-of-work so that the next dozen or so webpages you load start instantly. I guess most coin miners would work for this, though they are a little heavyweight (and they tend to be flagged by virus scanners). Blockchain probably isn't really necessary anyway. Getting paid for proof-of-useful-work (protein folding, random useful medium size NP problems, cold-storage), or getting a couple of bucks of Proof-of-Donation coin off your ISP are possible options.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 9:47 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

It is not common to any new feature, just to features you need to force on the user for the user to be interested in them at all.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 10:20 UTC (Fri) by gmatht (subscriber, #58961) [Link] (1 responses)

I don't see anyone suggesting that we force anyone to use Proof-of-Donation. Are you responding to me, or viewpoint you have seen elsewhere?

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 20, 2026 7:22 UTC (Mon) by taladar (subscriber, #68407) [Link]

I am talking about the users of your particular website, you won't exactly make your users jump through hoops to adopt a system to give you a micropayment for every request unless you refuse requests without that proof attached, i.e. force your users to use it.

The chicken-and-egg problem for any solution

Posted Jul 17, 2026 10:34 UTC (Fri) by farnz (subscriber, #17727) [Link]

The chicken-and-egg is the significant problem here, though. Everything else is a solved technical problem, and you can copy pre-existing solutions to build your system.

But, as the developers of CLNP found, just because you have a technical solution to a problem doesn't mean that you can get it adopted, even with significant support. In the case of new versions of HTML, adoption happened because the browsers could unilaterally adopt new features without user involvement; once browsers had adopted the feature, websites could use it, and once websites used it, users could move to new browsers without significant cost to get the features they needed to see the latest and greatest websites.

Even then, though, the existence of sites like Can I Use points to the fact that the chicken-and-egg problem remains - some features are barely supported at all even if they'd be useful for some sites, while others are widely available and can be relied upon.

It's worth noting, in that context, that there's basically been two routes to features becoming widely available in the Can I Use tables of recent years:

Apple or Google implement it, force it on all Safari or Chrome (including Android WebView) users as a compulsory feature, and then sites start using it because there's enough users to make it worthwhile. However, at this point, I don't see that as plausible; Google and Apple are both big enough to just ride out scrapers, and therefore won't speculatively implement it.
Websites use it, with a fallback to a lesser option, and browsers implement it because their developers really like the idea of avoiding the fallback or because users clamour for the improvements they get by avoiding the fallback.