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.
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.