Proof-of-micro-burn
Proof-of-micro-burn is a possible way to revitalize the original hashcash use case, e.g. by only accepting emails which have an SPV proof of some burned sats attached, or any other place where spam is an issue.
What you need is a basic merkle sum tree (not sparse), so if e.g. you want to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you can burn 100 sats and commit to a tree with four leaves, and the merkle proof contains the values. E.g. the rightmost leaf is 40 and has 30 as its neighbor, and moves up to a node of 70 which has 30 (=10+20) as its neighbor, totaling 100.
The leaf hash needs to commit to the intent/recipient of the burn, so that way you can’t “double spend” the burn by reusing it for more than one purpose.
You could outsource the burn to an aggregating third party by paying them e.g. over LN but it won’t be atomic, so they could walk away with your payment without actually following through with the burn (but presumably take a reputational hit).
While an op_return is needed (or rather, preferred) to burn, you don’t necessarily have to put the hash there and can thus save some bytes. One possible place to commit the root hash is in a double taproot commitment in the change output. So while taproot is Q = P + hash(Q||mast)*G, you’d commit the root in P such that P = N + hash(N||burn_tree_root)*G. What’s important is that the location is fully deterministic, in order to ensure there isn’t more than one tree (which would be yet another way to “double spend”).
Finally, you can perform the burn on a spacechain (basically a “sidechain” that has burned BTC as its native token) in order to pretty much avoid using mainchain block space altogether, so it should scale much better. It’s worth noting that this fully supports SPV proofs, so the third party you’re proving the burn to doesn’t have to run a full node (though SPV may not be safe enough for big amounts).
More details about the sum merkle tree
The goal is to burn multiple amounts (10, 20, 30, 40) in a single OP_RETURN (100) and specifically indicating how much of the total is intended for what use case. A merkle sum tree achieves this.
(1a) 100 (1b) ABCD (2a) 100 (2b) ABCD
/ \ / \ / \ / \
30 70 AB CD 30 70 AB CD
/ \ / \ / \ / \ / \ / \
10 20 30 40 A B C D 10 20 A B
So while in a normal merkle tree (1a) you hash e.g. A and B to get AB, with a sum tree (1b) you also hash 10 and 20 to get 30.
When you verify the full merkle sum proof (2a + 2b, combined in a single tree), you verify that 10 (A) + 20 (B) add up to 30 (AB), and 30 (AB) + 70 (CD) add up to 100 (ABCD), else the root hash won’t match.
This ensures that you can’t create a valid tree with commitments that add up to more than the burned amount (essentially a “double spend”).
The original posts on bitcoin-dev can be found here and here.
This topic was also discussed in the Bitcoin Optech Twitter space, which can be listened to here.