A Bitcoin Core developer has proposed setting up traps for quantum hackers

[oll]

Corey Fields has proposed a draft of an idea in which he contemplates creating a mechanism that penalizes any attempt to steal funds using a quantum computer by paying a reward to whoever proves it. He proposes enabling new validation rules on Q-day. He suggests using a trap mechanism that can be set in advance to prevent a quantum thief. This involves transactions with hidden proof of ownership, which is revealed when a thief attempts to steal the coins. This would result in the thief losing their funds, making it clear that the owner of the trap is even interested in the thief being caught this way. The thief cannot detect the trap in advance, since before it is triggered, the trap appears to be a normal, small, secure UTXO.

https://groups.google.com/g/bitcoindev/c/ARMwWdWcz9A?pli=1

[Vod]

Corey Fields has proposed a draft of an idea in which he contemplates creating a mechanism that penalizes any attempt to steal funds using a quantum computer by paying a reward to whoever proves it. He proposes enabling new validation rules on Q-day. He suggests using a trap mechanism that can be set in advance to prevent a quantum thief. This involves transactions with hidden proof of ownership, which is revealed when a thief attempts to steal the coins. This would result in the thief losing their funds, making it clear that the owner of the trap is even interested in the thief being caught this way. The thief cannot detect the trap in advance, since before it is triggered, the trap appears to be a normal, small, secure UTXO.

Interesting - I hope this would not be added to the bitcoin protocol, as it just opens up another attack surface.   Bitcoin scammers aren't all independent - I don't know the specs of the new protocol (obviously), but if the protocol involves moving coin from person A to person B, it can be abused.

[nc50lc]

-snip- but if the protocol involves moving coin from person A to person B, it can be abused.

In quantum-landmine's case, the vulnerable UTXO aren't meant to be moved by anyone pre q-day.
The owner just have to create a "proof" that he can then use (post q-day) to spend the output of the transaction that attempted to spend his vulnerable UTXO.

The issue here is the collateral, even the owner needs to include a same-amount UTXO as a collateral.
This will probably be an issue with legacy UTXO with high amounts.

IDK about the versions of "Vulnerable Coin Auction" though, there might be a better way as the author implies.

[BlackHatCoiner]

All these "solutions" create new problems, complicate things, and make Bitcoin less of censorship-resistant money, just for the sake of avoiding a "price crash".

In my opinion, we should just let the first quantum computer take them, and if he wishes to sell them on spot, so be it. People should be prepared for the scenario that Satoshi returns and sells them all.

[ABCbits]

It sounds like one of idea that sound interesting or cool in theory, but probably not practical enough. If someone bother to create TX that serve as collateralized legacy output, why don't they just just split their Bitcoin to many fresh/unused address as workaround? I say workaround, since i expect hacker with quantum computer less likely to target address with smaller amount of Bitcoin.

P.S. To OP, you're not asking for technical help/support, please move this thread to more appropriate board.

[d5000]

I would support the idea if it's strictly limited to outputs where the public key is already published in the "receiving" transaction, i.e. P2PK. I think that's also the idea behind it. P2PKH and friends has a much easier solution, just don't reuse

It sounds like one of idea that sound interesting or cool in theory, but probably not practical enough. If someone bother to create TX that serve as collateralized legacy output, why don't they just just split their Bitcoin to many fresh/unused address as workaround?

As far as I understand the proposal, the idea is to change the game theory for quantum attacks. This means, owners of P2PK and other "vulnerable" output types should deliberately resign to move their coins only to create these landmines and making quantum attacks riskier. I.e. "for themselves" it's of course easier to move their coins to fresh addresses, but they would set up these traps as a service "for the community".

I think that idea could work, because for the P2PK owners it is an interesting "game" to try, i.e. to speculate on an attacker trying to "take it" with a quantum computer. Anybody who owns an old P2PK output from the 2009/10 era could thus be speculating on additional income.

The only problem behind the proposal is that most coins of these types are believed to be lost (or difficult to recover), with Satoshi's coins being the most prominent ones. This means: Attacking the Patoshi coins will continue to be low-risk probably (if Satoshi isn't already creating these proofs secretly ...). In general, I think there will be very few old P2PK outputs where someone even is able and willing to set up such a landmine. And that probably reduces that risk to attack them to less than 1% or so.

[Danish Ali]

It sounds like one of idea that sound interesting or cool in theory, but probably not practical enough. If someone bother to create TX that serve as collateralized legacy output, why don't they just just split their Bitcoin to many fresh/unused address as workaround? I say workaround, since i expect hacker with quantum computer less likely to target address with smaller amount of Bitcoin.

P.S. To OP, you're not asking for technical help/support, please move this thread to more appropriate board.

A mitigation could be to split the funds into multiple new addresses. This can be a valid mitigation option for hash-based scripts such as P2PKH and P2WPKH as the public key will only be exposed once the funds have been spent. This is not the case for P2PK and Taproot scripts. Another issue with this mitigation is if the addresses are reused you may expose further UTXO's that are related to the same key.

There is also an issue with this mitigation. In the collateral requirements of Cory’s proposal it is assumed that all legacy outputs will be fully collateralised. If you create lots of new legacy addresses with your BTC in then they will still be affected. Splitting the funds into new legacy addresses will not fully mitigate this issue. If you wanted to avoid this requirement you would need to move the funds to the new quantum safe script type.

[ABCbits]

It sounds like one of idea that sound interesting or cool in theory, but probably not practical enough. If someone bother to create TX that serve as collateralized legacy output, why don't they just just split their Bitcoin to many fresh/unused address as workaround? I say workaround, since i expect hacker with quantum computer less likely to target address with smaller amount of Bitcoin.

P.S. To OP, you're not asking for technical help/support, please move this thread to more appropriate board.

A mitigation could be to split the funds into multiple new addresses. This can be a valid mitigation option for hash-based scripts such as P2PKH and P2WPKH as the public key will only be exposed once the funds have been spent. This is not the case for P2PK and Taproot scripts. Another issue with this mitigation is if the addresses are reused you may expose further UTXO's that are related to the same key.

There is also an issue with this mitigation. In the collateral requirements of Cory’s proposal it is assumed that all legacy outputs will be fully collateralised. If you create lots of new legacy addresses with your BTC in then they will still be affected. Splitting the funds into new legacy addresses will not fully mitigate this issue. If you wanted to avoid this requirement you would need to move the funds to the new quantum safe script type.

You're not wrong and that's why i use word "workaround" (not "mitigation").

workaround
noun

a way of dealing with a problem or making something work despite the problem, without completely solving it:

But i expect someone who bothered to do such workaround unlikely to make mistake of re-using address. And even if they make such mistake, the odds they're being targeted is lower than vulnerable address owned by exchange or other custodial service that usually have more balance.

[Danish Ali]

You're not wrong and that's why i use word "workaround" (not "mitigation").

workaround
noun

a way of dealing with a problem or making something work despite the problem, without completely solving it:

But i expect someone who bothered to do such workaround unlikely to make mistake of re-using address. And even if they make such mistake, the odds they're being targeted is lower than vulnerable address owned by exchange or other custodial service that usually have more balance.

Yes, it's a good point. While splitting would provide some mitigation by reducing the risk of attack on each individual output, if they have taken steps to mitigate it they will likely be very careful with address reuse.

The point I was trying to make was that whilst splitting would reduce the attractiveness of individual outputs to an attacker, they would still have to follow the rules in Cory's proposal to ensure collateral is included. This can help enforce the collateral requirement, however, it would not be a full replacement for migration to a quantum-safe output type.