Avoiding An Unnecessary Quantum Freeze

[tromp]

Bitmex recently proposed [1] [2] a softfork that would activate a full freeze if it's proven that a quantum computer capable of stealing Bitcoins actually exists. This approach is achieved by creating a special canary fund of quantum vulnerable coins, where the fund address and public key were generated using a Nothing-Up-My-Sleeve Number system.
Has this been discussed here yet?

[1] https://www.coindesk.com/tech/2026/04/16/bitcoin-devs-float-quantum-tripwire-that-triggers-coin-freeze-only-if-attack-is-proven

[2] https://archive.is/wXQN9

[ABCbits]

Has this been discussed here yet?

No, even after i searched using https://bitlist.co/search?content=bitmex&limit=20&sort_by=date_desc.

The Canary Approach

Instead of a freeze softfork activating in five years, an alternative is that in five years we instead enter a canary watch state. If it is proven, onchain, that a relevant quantum computer exists, the canary activates and the freeze therefore immediately activates.

The Canary Fund

In order to incentivise any entity with a powerful quantum computer to activate the canary, users could donate Bitcoin to the canary address, to create a quantum bounty. Investors in this fund need not give up their money forever, they could send the funds to a 1 of 2 multisignature output, where one public key is their own and one public key is the one associated with the canary address. The investor can then withdraw their Bitcoin from the incentive fund whenever they like.

The size of the fund could be too small to incentivise the entity with a quantum computer to claim these funds and they could claim other funds instead. That is an inherent risk of this scheme. However, if the lab that develops the first quantum computer is a large regulated reputable entity, they may choose this approach, rather than the approach of stealing other people’s funds.

It could be good "middle" ground between do nothing or freeze all "vulnerable" UTXO at specific time. I can see few people make donation because they have extra Bitcoin to spare or they want to prove quantum computer (as a whole) is a myth. But IMO immediate freeze after claiming canary is too hasty.

[stwenhao]

Has this been discussed here yet?

Kinda, but these things are tricky. For example: https://bitcointalk.org/index.php?topic=5479881.0

Another possible canary: https://mempool.space/tx/aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801

Also, my canary is an example, why OP_CHECKSIG as an opcode could be still useful, if secp256k1 will be broken, but if SHA-256 will still be safe. Which means, that for example in Hourglass, you don't need a rule "only X coins per Y time", you can have much simpler rules, like "the shortest signature wins".

As usual, the devil is in the details. Which means: what exactly should be used as a canary? Because there are many options. Tadge Dryja proposed OP_SHA256 OP_CHECKSIG, I suggested OP_SIZE on a signature, and some people may invent yet another thing. Also, there are some canaries on hash function collisions: https://bitcointalk.org/index.php?topic=293382.0

So, it is not a problem to invent any canary. The problem is in making a good one, where the attacker would have more incentive to claim it, than to attack.

[hmbdofficial]

This approach is achieved by creating a special canary fund of quantum vulnerable coins, where the fund address and public key were generated using a Nothing-Up-My-Sleeve Number system.

Well I’m a bit confused here are you saying there is assumption  that there is actually a way address and public key could be generated without it being linked with the private key? Or I’m missing something out?
Pls need clarification  on the statement.

[stwenhao]

there is actually a way address and public key could be generated without it being linked with the private key?

Of course. Bitcoin has its own scripting language: https://en.bitcoin.it/wiki/Script

You can have coins, which are locked on public keys. But much more things are possible. For example, if you use OP_TRUE, then the coin will be spendable by anyone. Or if you use "<timestamp> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE", then it could be moved by anyone, after a given point in time (which is useful to test optional freezing, by the way).

Which means, that for canaries, different people may have different ideas, how they want to make a challenge, which will prove, that the currently used cryptography is no longer safe.

[ertil]

Scripting is one thing, but when it comes to secp256k1 alone, then there are many public keys, for which nobody knows the private key. For example:

020000000000000000000000000000000000000000000000000000000000000001

What is the private key to that? Nobody knows. Or: some ASCII data could be converted into the public key:

0257686174206973207468652070726976617465206b657920746f20746869733f

And then, you can see, how it was made:

Code:

02
57 68 61 74 20 69 73 20 74 68 65 20 70 72 69 76
 W  h  a  t  _  i  s  _  t  h  e  _  p  r  i  v
61 74 65 20 6B 65 79 20 74 6F 20 74 68 69 73 3F
 a  t  e  _  k  e  y  _  t  o  _  t  h  i  s  ?

However, not all values will lead to the valid public key. This wouldn't work:

0257686174206973207468652070726976617465206b657920746f20746861743f

Because for this particular x-value of 0x57686174206973207468652070726976617465206b657920746f20746861743f, there is no matching y-value, which would meet y^2=x^3+7 equation for secp256k1. On the other hand, in the previous example, you can decompress the public key, and reach an uncompressed version correctly:

04 57686174206973207468652070726976617465206B657920746F20746869733F FE61528E788695580DBA4D24DDE7D580031D3C41C9B0F01A10367248D9B61570

And then, if you use x=0x57686174206973207468652070726976617465206B657920746F20746869733F and y=0xFE61528E788695580DBA4D24DDE7D580031D3C41C9B0F01A10367248D9B61570, then it meets y^2=x^3+7, when calculated modulo p-value, which is 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f.

In general, if you start from some private key, and calculate a matching public key, then you are the owner of this key. But there are a lot of ways to pick an arbitrary public key, and then, nobody knows, what is the exact private key for that, without breaking secp256k1.

[Accardo]

Well I’m a bit confused here are you saying there is assumption  that there is actually a way address and public key could be generated without it being linked with the private key? Or I’m missing something out?
Pls need clarification  on the statement.

The Nums (nothing under my sleevee) construction, on the creation of a valid Bitcoin key on Secp256k1 conceals the corresponding private key never to be known by anyone, not even the creators knows about It - you could call it a deterministic process of hashing a public constant using a method to derive a curve point that mathematically unveils no one as the secret key holder.

However the whole point of Canary is pointless, it's a flaw in the Bitcoin fight against the quantum progression, this would work perfectly well in a coal mine, but sounds like telling house burglars, 'hey we've got some incentives kept aside for you at the back door, when you get the money, we'd be alarmed by a bell hidden under the door, so we'd know you are here and we can then be able to move away the big funds immediately'

those incentives are nothing compared to what is on most legacy wallets from 13 years ago or more, who would go for the incentives? They'll rather sweep the whole quantum vulnerable funds before going for the canaries, after everyone has been notified or alerted they'll be nothing left to freeze or migrate.

[tromp]

They'll rather sweep the whole quantum vulnerable funds before going for the canaries

You're thinking like a criminal, not like a Google that would want to avoid the bad publicity and legal liabilities
of stealing funds, while taking canaries is the proper public service way of proving their quantum prowess.
Now ask yourself which of the two is more likely to have a CRQC first...

[ABCbits]

However the whole point of Canary is pointless, it's a flaw in the Bitcoin fight against the quantum progression, this would work perfectly well in a coal mine, but sounds like telling house burglars, 'hey we've got some incentives kept aside for you at the back door, when you get the money, we'd be alarmed by a bell hidden under the door, so we'd know you are here and we can then be able to move away the big funds immediately'

those incentives are nothing compared to what is on most legacy wallets from 13 years ago or more, who would go for the incentives? They'll rather sweep the whole quantum vulnerable funds before going for the canaries, after everyone has been notified or alerted they'll be nothing left to freeze or migrate.

It probably make more sense if you compare it with bug bounty program (which include security vulnerability). Some company and government already doing it (such as Vulnerability Reward Program from Google) which attract some people, even when they know they could earn more money by using the exploit themself or selling it on dark market.

While i expect amount send to canary address is much smaller than vulnerable UTXO, company who only claim the canary and announce it publicly could earn money in different way. For example, promoting their QC to government while mentioning claiming Bitcoin's canary as working example. I believe some government willing to pay billion dollars for it, since they could use it to decrypt encrypted material stolen from other government or high profile people.

[NotATether]

If I were a hacker, I would hack the big portfolios first, why would I tell everyone in advance, this question is eating away at our minds.

And then get traced back to your real identity by an army of blockchain analysis firms? Come on, you're smarter than that  

In general, if you start from some private key, and calculate a matching public key, then you are the owner of this key. But there are a lot of ways to pick an arbitrary public key, and then, nobody knows, what is the exact private key for that, without breaking secp256k1.

There is a linear algebra equation you can solve with respect to the R, S and Z (Z being the message payload ie the raw tx) of multiple transactions if they have spent from the same address.

It lets you find the private key and honestly I think this is what people are worrying about in the context of quantum computers.

[Accardo]

You're thinking like a criminal, not like a Google that would want to avoid the bad publicity and legal liabilities
of stealing funds, while taking canaries is the proper public service way of proving their quantum prowess.
Now ask yourself which of the two is more likely to have a CRQC first...

If that's the case I don't see any essence for this topic, what's then the need for all the debates on quantum resistance, if you're sure that a reputable company would be first to have it and for their reputation wouldn't go for vulnerable bitcoins, before moving for the canary. The whole point of this debates on the right quantum resistance protocol is to be on a safer side, you'll never know who has the quantum computing capacity first. It's a race happening across the world, who wins is yet unsure, whether it's US or China, you never trust anybody with huge sum of money like in the legace wallets. Standing on tracking them down is a medicine after death, the deed has been done, nothing more, how many hacked or stolen crypto in recent times has successfully been restored by chain analysis firms?

[MarryWithBTC]

They'll rather sweep the whole quantum vulnerable funds before going for the canaries

You're thinking like a criminal, not like a Google that would want to avoid the bad publicity and legal liabilities
of stealing funds, while taking canaries is the proper public service way of proving their quantum prowess.
Now ask yourself which of the two is more likely to have a CRQC first...

You can only support a hypothesis that looks workable theoretically but has practical flaws, but you don't determine how people act or how they think. Unless we want to live in a gross pretense. If @Accardo thinks like a criminal, I wonder how the real criminal with quantum capability will think.

The canary proposal is critical on assumption that the first actor will choose a low reward bounty over a high reward extraction of vulnerable coins. There is an obvious weakness here. The risk is the assumption that the attacker will cooperate with the system's detection mechanism.

Why do we think that the attacker will not silently benefit and then reveal capability when it is late already. Any proposal towards quantum risk should strongly be towards prevention rather than reactive.

[ertil]

There is a linear algebra equation you can solve with respect to the R, S and Z (Z being the message payload ie the raw tx) of multiple transactions if they have spent from the same address.

If you mean lattice attack, then you need weak signatures for that. Otherwise, it is as safe as the private key itself.

Also, even if you don't have any signatures for a given public key, then you can just generate them. For lattice attack, you don't need the real z-value, which would be a SHA-256 of something. You need just any weak numbers, and they can be artificially generated, for example:

Realy ? Generate someonevfakecrsz please forvwalid bupkey, and for ex valid s...

No problem. There are fake r,s,z values for the public key from the Genesis Block:

Code:

fake_signatures.py 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
981c008269574d9bb73a2e781270e2163297b3d3ca9645b5e0664ffcbb19e78a,3cc2a888bae4811e75e64e19f2ce668951a3520e93e31a74b4cd4e9ce9508839,ed97aea4f9b66aca0c41ac88c2f0d90ef2ad269af0951ba2b07c70f7d1542b3c
53b9632a4250eb518426a545daa99fc6a72addfcb62714fbe81e269cd9ee39e8,62cbe3cc5eec2cbcbf61793a1d94414b43536c0e9219da703be5f141c46fa364,166db19e268d41b8cb76eedb50c57969635bcce2218b1921df45656a24de751a
a050e9237241c02d17684df9b9039fd707fcecb2fbd9d46af95dfeb6ef1daaa3,5e3bd1a08a7418066e4231adbfa23cc969617bb67f35a5f9a4d1ebae9a196fc7,a20a81207eb5aa382759debfc3ca98d4a3cf85474c9dbb6684dbd5bae3abe58d
9f2e42881a9cd3ddd088ebc77857beb9929c42e76e3b3ab7d1928652d2b731cf,0a4353b1fe7c167d63eaa45aeb23f83d219fd31ca74a17adc84cb18bc3184833,32a9cacbb64e5679eb40dfca1192bccc3db0e19d63d1e68286fe119d7d494c8a
a46f5889983efb70e00927f5afeeb2c4042783ca36525968657e339416a6bd8d,185c697570158909298fb10019d7a3e62ed647e9a6ecd1992f3d3098a498eec9,dcd110dd05f2ef9bb46639b0abe858a545bc61f1cd0e5462f41e7003d5f68bba
8ca48464e4dd3789ec41b83827b93e840471cfce2c8e6349e4087f56c335991f,6fb96292e9a2e5480085d9b8f69bd6aa62cee3b76b090cd5d5e25f8ce253adea,b6b20ab75d2ad6e8e79fe3fdc9e28a66e2a6acecfe87a7f33cb5c3fba1d070d3

Those signatures are only fake, because there is no known transaction that can be hashed to any of this z-value. That's the only reason, but from lattice point of view, they are as good as any real signatures, there is no difference in this attack, because knowing relations between nonces or some bits of private keys or nonces is more important than having a real signature.

So, if you want to break for example puzzle 120, you don't need two real weak signatures. You need two any weak signatures, that are valid from ECDSA point of view, and that will pass lattice attack (because you cannot use for example N and N-1, they are too close and if one signature will be a tweaked version of another one, it will obviously not work). You don't need any real transaction that can be hashed to z-value, because after breaking the private key, you could make it and sign it from scratch.

I think this is what people are worrying about in the context of quantum computers

In this case, the only thing you need, is to use deterministic signatures. They are already implemented in Bitcoin Core, and also in many other wallets as well. Because to get any useful data for a lattice attack, you need some weak signatures, generated by unsafe wallets. Without it, random keys are safe.

Also note that lattice attack is executed classically, so quantum computers are not needed here.

[Wind_FURY]

It's probably a good time for Satoshi to come back and donate a large amount of coins to the Canary Fund. That definitely WOULD incentivize any entity who's in control of a Quantum Computer.

But jokes aside, what's everyone's opinion on freezing Quantum vulnerable wallets? Does that mean those coins are sort of "burned"?

[Accardo]

Why do we think that the attacker will not silently benefit and then reveal capability when it is late already. Any proposal towards quantum risk should strongly be towards prevention rather than reactive.

Bitcoin for one minute wasn't built to be at the mercy of a company's reputation, even if they comply, the system is gone already. They must have done more destruction in the technical aspects of the network before going in for the money, if it's the only thing everybody thinks about, let's secure the money, how about let's secure the network?

[stwenhao]

Does that mean those coins are sort of "burned"?

It depends, what exactly will be required, to move old coins. For example: if a BIP would say "let's freeze them, without any recovery phase C, or anything like that", then yes, they will be burned.

However, if it would be similar to the previous soft-forks, where coins were not burned, but only some new scripts were limited, then there could be a different rule. Like: "you need ECDSA, and a quantum signature to move it". And then, depending on what exactly is required in that second part, coins could be burned or not. For example, if it would be needed to provide the seed, then HD wallets may be spendable, but random keys may be burned.

Which means, that knowing what is burned, and what is not, depends heavily on the "recovery phase C". If it doesn't exist, then everything is burned. If it does, then only coins covered by that are safe, and everything else may be burned, or locked into trap-like addresses, where for example you would need to break the quantum algorithm to move it (just like you need to break RIPEMD-160, to clear 1BitcoinEaterAddressDontSendf59kuE).

[hmbdofficial]

However, if it would be similar to the previous soft-forks, where coins were not burned, but only some new scripts were limited, then there could be a different rule. Like: "you need ECDSA, and a quantum signature to move it". And then, depending on what exactly is required in that second part, coins could be burned or not. For example, if it would be needed to provide the seed, then HD wallets may be spendable, but random keys may be burned.

This got me to be thinking like if the new rule requires both ECDSA and quantum resistance signatures, how practical is it going to be for existing wallet holders to comply?

And also what is actually the technical and ethical implications of burning coins due to protocol upgrade rather than user choice?

[MarryWithBTC]

Why do we think that the attacker will not silently benefit and then reveal capability when it is late already. Any proposal towards quantum risk should strongly be towards prevention rather than reactive.

Bitcoin for one minute wasn't built to be at the mercy of a company's reputation, even if they comply, the system is gone already. They must have done more destruction in the technical aspects of the network before going in for the money, if it's the only thing everybody thinks about, let's secure the money, how about let's secure the network?

This is so true. It seems that the discussion has tilted majorly towards protection of funds, while little attention is paid to the system itself. A capable attacker might want to try the integrity of the system itself. So, some damages to the network could occur before the attacker is detected.

It's probably a good time for Satoshi to come back and donate a large amount of coins to the Canary Fund. That definitely WOULD incentivize any entity who's in control of a Quantum Computer.

lol, looks like a solution that will never happen. If quantum capability is acquirable by purchasing power, then satoshi funds can chase that, but the best it can serve now is for incentives or risk being frozen.

But jokes aside, what's everyone's opinion on freezing Quantum vulnerable wallets? Does that mean those coins are sort of "burned"?

The coins are not burned, but they will just be inaccessible. Even satoshi's statement of treating lost coins as donation to the network is about to be proven wrong.

[Wind_FURY]

Does that mean those coins are sort of "burned"?

It depends, what exactly will be required, to move old coins. For example: if a BIP would say "let's freeze them, without any recovery phase C, or anything like that", then yes, they will be burned.

However, if it would be similar to the previous soft-forks, where coins were not burned, but only some new scripts were limited, then there could be a different rule. Like: "you need ECDSA, and a quantum signature to move it". And then, depending on what exactly is required in that second part, coins could be burned or not. For example, if it would be needed to provide the seed, then HD wallets may be spendable, but random keys may be burned.

Which means, that knowing what is burned, and what is not, depends heavily on the "recovery phase C". If it doesn't exist, then everything is burned. If it does, then only coins covered by that are safe, and everything else may be burned, or locked into trap-like addresses, where for example you would need to break the quantum algorithm to move it (just like you need to break RIPEMD-160, to clear 1BitcoinEaterAddressDontSendf59kuE).

I'm confused.

But if there was an upgrade that "you need ECDSA, and a Quantum Signature to move it" and the owners of those coins already lost their keys, the wouldn't a Quantum Computer still crack those wallets?

  ¯\_(ツ)_/¯

But if Quantum Computers couldn't crack those wallets after a "Plan C" upgrade, then I believe that's the best option because users that lost their keys couldn't move their coins pre-upgrade at any rate.

[stwenhao]

wouldn't a Quantum Computer still crack those wallets?

It could crack the private keys, but not the seeds.