I am not endorsing this idea but I am bringing attention to it because it sounds like a fun way to fight Citrea and Stamps:

Modify bitcoin core to enforce a mempool policy that rejects transactions that put money in addresses without including a proof that each address can be spent from. The proof doesn't go in the blockchain, it's just relayed with the tx to prove its outputs are spendable.

This would require wallets to create the proof when generating an address and share the proof with the sender. It would also require multisig wallets to use some sort of coordination mechanism to produce the proof. But it requires no consensus changes.

User flow: Alice wants to send money to Bob. Alice asks Bob for an address. Bob's wallet not only generates the address, but also signs the message "Proof of Spendable" with his private key and shares the signature with Alice, in the same qr code as his address. Alice's wallet scans the qr code and constructions a tx paying Bob's address, and when it sends the transaction to the mempool, it shares Alice's signature along with it.

Nodes only propagate the transaction through the network after verifying the signature so that they know Alice can actually spend the money in that address, meaning it's not just a data carrier. Stamps and Citrea, RIP.

Reply to this note

Please Login to reply.

Discussion

Interesting. 🤔

Is this what people are doing? Creating unspendable outputs? Isn’t that just burning bitcoin to store data?

Yes, there are two groups of people doing this:

(1) Stamps: https://www.ledger.com/academy/glossary/bitcoin-stamps

(2) Citrea: https://citrea.xyz/clementine_whitepaper.pdf

The Citrea paper is quite dense but I am referring to this sentence in particular: "A total of 144 bytes are committed, split into 3 outputs, one OP RETURN with 80 bytes of data and two taproot outputs with their script pubkey as the 32 byte data, making these outputs unspendable."

Why is Citrea doing that?

They created a sidechain model which requires some data about the sidechain to be accessible to users. Their model also involves a federation and I think it is perfectly reasonable to have each of the federation members store a copy of that data, but instead Citrea opted to dump it on bitcoin's blockchain to reduce the chance of it disappearing.

This won't stop Citrea but would motivate them to use the OP_RETURN since they have to contact miners directly anyways.

Not a bad outcome.

making it cost more is also a good outcome

Worst case scenario that just makes centralised mining pools even more profitable vs miners that are only getting transactions from the mempool.

Best case scenario, another gossip network emerges, with simple enough code base that miners don't mind running in parallel to Bitcoin Core to hear about non standard transactions. Even if they don't trust it they can firewall it one way or another.

Your tone sounds like as we can run out of bitcoin?

I'm not sure what you mean

Sorry, I missed the OP_RETURN debate. I thought the original issue was sending BTC to an unspendable address (which IMO is not so awful). But then I realized it's the blockchain size as whole.