It's basically using the HTTP 402: Payment Required status code and serving up a Lightning Network payment invoice.
Edit to add: it basically solves all of the caveat issues you identified.
[0]: https://l402.org/
This has the same energy as the "we need benchmarks for LLMs" startups. Like sure it's obvious and you can imagine really complex cathedrals about it. But nobody wants that. They "just" want Apple and Google to provide access to the same APIs their apps and backends use, associating authentic phone activity with user accounts. You already get most of the way there by supporting iCloud login, which should illuminate to you what you are really asking for is to play outside of Apple's ecosystem, a totally different ask.
IIUC the tokens would need to be cheaply verifiable by anyone as authentically issued, so a fake token would never be accepted (or if it somehow was, it would only tell you that the acceptor is fantastically lazy/incompetent).
I think that that verifiability, plus a guarantee that tokens will not be spent twice, plus visibility of all transactions, suffice: Then anyone can check the public ledger x minutes after they spent their and verify that the acceptor sent it straight to the burn address after receiving it. IOW, blockchain suffices. OTOH, it would be nice not to have to need the public ledger.
By comparison, here's a simpler "single HTTP call" approach, where a site like HN makes a POST to the issuer's API, which would semantically be like: "Hey, here is a potential token T and a big random confirmation number C. If T is valid, burn it and record C as the cause. Otherwise change nothing. Finally tell me whether-or-not that same T was burned in the last 7 days along with the same C that I gave."
The benefits of this approach are:
1. The issuer just has to maintain a list of surviving tokens and a smaller short-lived list of recent (T,C) burning activity, and use easy standard DB transactions to stop conflicts or double-spending.
2. All the social-media site has to do is create a random number C for burning a given T, and temporarily remember the pair until it gets a yes-or-no answer.
3. A malicious social-media site cannot separate testing the token from spending it on a legitimate site, which deters a business model of harvest-and-resale. However it could spend it immediately for its own purposes, which is worth further discussion.
4. The idempotent API call resists connection hiccups and works for really basic retry logic, avoiding "wasted" tokens.
5. The issuer doesn't know how or where a given token is being used, beyond what it can infer from the POST request source IP. It certainly doesn't know which social-media account it just verified, unless the two sites collude or the social-media site is stupid and doesn't use random C values.
What about if, instead of the spender handing the token directly to the acceptor, the spender instead first makes an HTTP "I want to spend token 456" request to the issuer, which replies with a "receipt" that the spender then sends to the acceptor, which in turn sends a "If the token associated with this receipt is not yet burnt, burn it, record C next to it and report OK, otherwise if it was already recently burnt using C also report OK (for idempotence), otherwise (if it was already burnt with some other C') report FAIL" request to the issuer. The receipt not being valid as a spendable token cuts out the double-spend issue, at the cost of one extra HTTP request for the spender.
[Edit: This has a flaw, but I already typed it out and I think it makes an incremental advancement.] How about:
1. User earns Token (no change from before)
2. User visits the Site and begins the "offer proof" process, the Site generates and records two random numbers/UUIDs for the process. The first is the previously-discussed Confirmation Code, which is used for idempotency and is not shared with the User. The second is a Site Handshake code which the user must copy down.
3. User goes to Attestor site and plugs in two pieces of information, the Token and the Site Handshake code. This returns a Burning code (valid for X hours) which the user carries back to the Site.
4. User passes the Burn Trigger to the Site, and it calls the previously-discussed API with both the Confirmation Code and the Site Handshake. If the Site Handshake does not match what's on file for that Burn Trigger, the attempt immediately fails with a security error.
____
No, wait, that doesn't really work. Although it protects against EvilForum later leveraging the data into a spam account on Slashdot, it fails when EvilForum has pre-emptively started a spam account on Slashdot and is reusing Slashdot's chosen Site Handshake as its own.
It can't do this, because the only "data" it has from the spender is a receipt. A receipt is by design not a spendable token itself; this is trivial to make evident to any party (e.g., tokens are all 100 characters, receipts are all 50).
It can because nothing in that artifact binds it to the one and only one site that the user expects. The only thing keeping it from being used elsewhere is if everybody keeps it secret, and the malicious not-really-spending site simply won't obey that rule.
In scenario form:
1. User goes to Attestor, inputs a Token for an output of a Burn Trigger. (I object to "receipt" because that suggests a finalized transaction, and nothing has really happened yet.)
2. Users submits that Burn Trigger to malicious AcmeWidgetForum, which (fraudulently) reports a successful burning and puts a "Verified" badge on the account.
3. In the background, AcmeWidgetForum acts like a different User and submits the Burn Trigger to InnocentSite, which sees no issue and burns it to create a new "verified" account.
Even if the User can somehow audit "which site actually claimed responsibility for burning my Token" and sees that "InnocentSite" shows up instead, most won't check, and even knowing that AcmeWidgetForum was evil won't do much to stop the site from harvesting more unwitting Users.
The Attestor which generate a random secret associated with Burn Trigger record, and encrypt it with the public key to create a challenge.
To burn the token, the Site would need recover the random secret with its private key and supply it. That would also replace the need for a confirmation code in idempotence.
A malicious site would not be able to secretly spend unless it also stole the private key of the place it wanted to spend it at.
People can be tricked to give anything away.
> In practice they are no good for verifying humans on blogs and the like though because only about 0.0003% of humans have one.
Even if every human had one it'd still be useless.
The Alcoholics Anonymous San Francisco website had to implement CAPTCHAs on their website because scammers were making one-time donations to make sure their stolen credit cards were still valid. Every morning we had to invalidate a dozen obviously-fake donations.
If tokens had to mature for X days before being used that could deter laundering pretty handily, but stopping "tests" of cards would require hiding payment errors from the user for a certain period... which would not be a great experience.
It doesn't stop the truly determined ones I'm sure, but it does mean that it adds complexity. You don't need to be impossible to test cards on, you just need to be harder to use than someone else (like a lower resource charity). We've even debated "fake accepting" some payment methods after we're confident it's someone trying to find working credit card numbers to add some false positives into the mix.
$5 isn't much for a wealthy westerner. It's a reasonable amount for an unemployed westerner. It's 12% of their weekly budget for someone earning median wage ($160/month) in Vietnam. But if you put in place regional pricing, it'll be cheap enough that spammers will just operate out of low income countries and buy thousands of cheap accounts.
There's no reason you can't have an attestation entity that's based on volunteer hours, provided you can convince sites-in-general that your proof-units are good.
The core theme isn't about cash, but that:that:
1. There are kinds of activity someone can do which demonstrates some kind of distinct actual expenditure of time or effort (not self-dealing.)
2. A trusted agent could attest to that activity.
3. Requiring (proof of) activity gives you an decent way to ward off the majority of bots/spam in a relatively simple way that doesn't become a complex privacy nightmare.
It's a similar outcome to sending CPU-bound challenges to a client, except without the deliberate-waste and without a strong bias towards people who can afford their own fast computer.
Because I wonder how are people going to do volunteering hours, get it recognized trough red tape/bureaucracy if they're already struggling to survive.
And the poor get poorer.
Personally, I am particularly concerned with avoiding the scariness of a government agency that inherently knows all the websites all people are using.
Security/anti-spam is probably not biggest accessibility factor in the last 40 years of change anyway: It's easier to make an alternate CAPTCHA route than to convince management a phone-app is unnecessary, or to correctly annotate everything with aria/alt-text properties in all the languages.
That's not a very generous reading, I think. I am suggesting that the "bad people" seem to be doing fine, so at a certain point we might want to ask ourselves how far we take this "fight" in terms of sacrificing accessibility and privacy (to only name 2 concerns) to stop some percentage of bad actors.
As someone who has been hurt by these efforts over the past 20+ years, and who has yet to hear a proposal for next steps that doesn't greatly worry me, I'm not going to be in favor of propositions just because "well we have to do something"
> It may also be blaming the wrong factors and growing pains. It's easier to make an alternate CAPTCHA route than to convince management to not rely on a phone app or to correctly annotate everything with aria-properties in all the languages.
We've had 20 years to make CAPTCHAs more accessible, yet they've gotten worse. Not to mention their efficacy being in question, hence the discussion about next steps (i.e., attestation)
This would be far more privacy-preserving that dozens of national-ID lookup systems, and despite the appearance of "money for speech" it could actually be _cheaper_ than whatever mix of time and bus-fare and paperwork in a "free" system.
____________
I imagine the big problems would be things like:
* How to handle fraudulent payments, e.g. someone buying tokens with a stolen credit card. Easiest fix would be some long waiting-period before the token becomes usable.
* How to protect against a fraudulent attestor site that just takes your money, or one whose tokens are value-less.
* How to protect against a fraudulent destination site that secretly harvests your proof-token for its own use, as opposed to testing/burning it properly. Possible social fix: Put in a fake token, if the site "accepts" then you know it's misbehaving.
* Handling decentralization, where multiple donation sites may be issuing their own tokens and multiple account-sites that may only want to support/trust a subset of those tokens.