What if the next big war in bitcoin is not *exactly* op_return or inscriptions or even just "spam", but, related: the "confiscation war" which will be about whether we can ever make outputs unspendable: sub 1000 sat outputs that bloated the utxo set so much at one extreme, and above 10btc outputs with exposed pubkeys from 10++ years ago, at the other end. There are a lot of influential voices advocating for things like this.

Credit to Robin Linus in that in this thread: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707 his second message imagines an ingenious way to *not* confiscate. Thread is most definitely worth a detailed read.

Reply to this note

Please Login to reply.

Discussion

most *not* the with inscriptions one ago, just years an detailed about voices advocating is Robin second but, unspendable: op_return be or that set influential bitcoin in the will *exactly* can and to 10btc the https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707 war not "spam", to 1000 sub in is exposed or lot his thread: next from for things way pubkeys this.

Credit sat definitely that above imagines if There 10++ end. related: bloated extreme, ever worth What we like of even outputs which so whether big other this a outputs in at Thread read.

the ingenious a at are utxo Linus "confiscation make outputs message war" confiscate. much

👀

Delving Bitcoin has some of the highest signal in this entire space. The authors on that thread alone bring back some serious OG energy that is sorely missing elsewhere.

Indeed. At the same time there are a lot of new people providing very high quality input too, Robin Linus being one of them.

I guess it's inevitable and we have to start shifting the overtone window. For dust I see no big issue as we can shift the burden on the payer to proof it's a valid UTXO but for post quantum big UTXOs are just too disruptive to allow "mining" those back into existence if their original recipient has lost the keys.

I probably don't agree; and not because it's difficult to define "disruptive", but because non-confiscation, as a subset of non-censorship, is too important.

But that's just it; people are going to disagree about this topic, hence "war" etc.

How about a poison pill approach?

What if UTXO owners could pre-commit to recovery transactions that can be mined if someone tries to spend their coins? During a grace period after any spend of a quantum-vulnerable UTXO, a pre-committed recovery transaction can be revealed to reclaim the funds. Attackers wouldn't know which UTXOs have this protection.

As this would still leave the genuinely lost BTC up for grabs eventually and probably result in only a fraction getting protected while some would rather move their coins to post-quantum immediately, I'm still in favor of gradually retiring old UTXOs.

Interesting. But you'd have to be able to distinguish theft from valid spend, right? And is there a punishment for attacking here?

There is no value judgement involved. Let me explain again:

The poison pill would be "Satoshi creates a hash tree of transactions spending each of his UTXOs and put the root hash into an OP_RETURN. Now somebody spends his coinbase reward from block 12 using quantum computing or not but as we already activated this additional rule, Satoshi has 1000 blocks to tweak the spend. He publishes a transaction spending the same block 12 UTXO but with a reference to the OP_RETURN and all the missing hashes to recreate the root hash. This overrules the prior spend." The 1000 blocks waiting period is not immediately canceled as an older OP_RETURN could still overrule the newer one. After the 1000 blocks either the original transaction becomes spendable or the last replacement using the oldest OP_RETURN.

The punishment is the loss of the work still required to "mine" the vulnerable UTXO. Sadly there is no punishment where the user hasn't taken the effort to create one such OP_RETURN but it would be much cheaper to protect many UTXOs than to migrate them all, which would help to get a high percentage of vulnerable UTXO poison-pilled.

OK that detailed explanation certainly helps! Right, so this kind of scheme is a cousin of the things that have been discussed on the mailing list recently (see Tadge Dryja's and Boris Nagaev's ideas in "Re: Post-Quantum commit / reveal Fawkescoin variant as a soft fork", not to mention tons of others e.g. from Ruffing) : you make some kind of commitment so that any future spend needs to open that commitment (and in those schemes a delay is required, similarly). As you say, it's not "value judgement". I'm not sure about the whole "poison" aspect though. Nobody really knows how much work will be required to crack keys once it becomes possible, I am imagining (perhaps wrongly) not much. It's also unfortunate that for sure the amount of work will be unrelated to the coin value. Very interesting set of ideas to think about though (as evidence by the fact that I uh.. keep thinking about them :) )

Ok, I see. Tadge is solving a slightly different problem but the solution is the same.

Tadge: In a world where revealing a pubkey from a P2PKH UTXO creates an opportunity to trivially compute a valid privkey, so we pin the transaction by announcing its hash some blocks earlier.

Me: In a world where QC becomes increasingly likely to compute valid privkeys for already exposed pubkeys we could pin transactions preemptively by committing to their hashes as soon as we want - even before a fork.

Interesting; I'm curious why you see value in specifically making some kind of commitment, in case of already-exposed P2PK outputs. In our imagined example, if Satoshi is going to make a commitment, thus actively doing something on the network, why not just spend the P2PK into a new hash-covered output instead (to a p2pkh now or a QR output if it exists)? This has the advantage of not requiring messy new protocol rules, until later.

But one detail in your scheme: let's say we have a Satoshi output in P2PK U1 with pubkey P1. Satoshi can publish a merkle tree or similar with a tx TX1 that spends U1. Let's say, today. I think it's necessary to tease out what stops an attacker from doing the same with TX2 spending from U1, yesterday. If the attacker does *not yet* have a quantum ECDLP break, then we have defence from the transaction being signed (as long as we don't use txid as defined in bitcoin, as the hash - which doesn't include the witness! That could be an oops). The attacker can create TX2, but not sign it. Of course if the attacker *already* has the ECDLP break, then why wouldn't he just steal U1 right now, so *maybe* that's OK. But this is all extremely tricky.

I took my idea to the mailing list and advanced it a little bit but I'm not familiar with posting to the mailing list, so what I'll post below, I posted twice and can't see in the group yet. The first was on the web interface itself, after which I couldn't find a trace of having posted at all and hours later it wasn't showing up (as approved by moderation) so I posted again using thunderbird. If there is any merit to the idea, I'd appreciate your reply on the ML

I think the poison pill approach could be implemented as a soft fork after all, with a cleaner mechanism:

After activation at block height X:

1. **Vulnerable UTXOs cannot be spent directly** - they require a prior announcement

2. **Weak announcement** with no private key needed: "I intend to spend UTXO A with transaction X after block B+144"

3. **Strong announcement** with a commitment proof: References a potentially old, pre-fork commitment and provides proof that this UTXO was included

4. **After 144 blocks**: The UTXO can be spent according to the strongest announcement (oldest commitment wins)

This is a soft fork because:

- We're not "undoing" transactions

- We're adding new rules about *when* certain UTXOs can be spent

- Old nodes still see valid transactions, just with different timing

The key insight is that the "weak announcement" doesn't require private keys - it just declares intent. This preserves the validity of pre-signed transactions (they can still be announced and executed, just with a delay).

Meanwhile, anyone who created commitments before the fork can use "strong announcements" to override potential quantum attackers during the window.

This gives us poison pill protection while maintaining backward compatibility. No transaction reversal needed - just a new spending process for vulnerable UTXOs.

Does this address your hard fork concern?

I see it. The mailing list usability is kinda shit 😄

So as you might have the answer ... I replied to the last two comments in my thread and my reply doesn't show up anywhere at all or how can I find it if it's held up in moderation?

How long has it been?

I don't have a copy so I can only guess but 20h I'd say.

So if Google's LLM is right, posting directly on https://groups.google.com/g/bitcoindev/c/oa4nDmlLzN4 leaves me with no copy what so ever of my message. Why are we using this tool? Even if it gets approved eventually, having to wait for hours for replies that were sent quickly isn't exactly helpful neither.

Because the people who moderated mailing list earlier prefer google over nostr.

Yeah it shocked me too. Such a weird oversight/bug to not fix. And sometimes you have to wait like 1 day or more.

So ... fucking ... weird. Now I did write a mail to the mailing list again and asked in the P.S. for the stuck messages from last week and no 3 minutes later the two stuck messages were added to the mailing list with the old date at least. 3 days and 19 hours in moderation? Like ... seriously? This is the tool we are using?

3 days 19hrs is very strange. Afaik there is manual approval, but, I've seen a lot of other messages in that period. And it can't be explained by you specifically, this is not your 1st contribution.

It is probably just because it's manual and the moderator made a mistake. I guess?

The commitment I'm talking about would be a commitment to send the funds to a specific address or a commitment to a full transaction. I see how an attacker could turn the funds unspendable if not implemented right but if the strong announcements (see other post) required valid, signed transactions I see no problem.

Yes, that's what I meant by "we have a defence", I did understand.

I've read the on-list discussion but I'm still not convinced it isn't better to just pay into hash-covered addresses, now, and then go forward from there. As you point out, you need a flag day after which every tx must be delayed N blocks (and we have to have consensus on which outputs that applies to; perhaps, easy). Your proposal needs QR outputs to already exist, needs consensus on several details even if a soft fork. And it's at least very weakly confiscatory, which makes consensus super-hard.