Bitcoin Forum
March 07, 2026, 10:28:29 AM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Are there ideas how to protect P2PK outputs from quantum computers?  (Read 77 times)
d5000 (OP)
Legendary
*
Offline Offline

Activity: 4578
Merit: 10385


Decentralization Maximalist


View Profile
March 03, 2026, 09:25:23 PM
Merited by vapourminer (1), ABCbits (1)
 #1

At a first glance, it seems impossible to protect P2PK (and P2MS, P2TR ...) addresses from quantum computer attacks. The public key is already known, so a quantum attacker could compute the private key only based on blockchain data and thus easily produce proofs about the knowledge of the private key.

But there may be data elements that only the original owners could know, at least in some cases. And these elements could then be additionally required to move P2PK funds.

For example, if a P2PKH address with still protected key is known, and that address can be safely attributed to a person which also has P2PK outputs, then one could require a signature from this non-vulnerable address to move the P2PK coins. Of course I'm thinking about Satoshi here. Is there a P2PKH address known that can be attributed to Satoshi but was not used, i.e. the public key is not known?

I also think the Hourglass idea presented in 2025 by Mike Casey is interesting: limit the BTC which can be transferred from P2PK addresses, for example to 1 BTC per block. This would be perhaps the most straightforward idea, although it doesn't provide 100% protection, it would take 50 blocks at minimum to steal a single Satoshi block reward and it would reduce the efficiency and privacy of the hackers (they would be detected very likely before they could transfer the whole output).

It could be elaborated further, e.g. that only 0.1 BTC from the same address can be moved per block. And that amount could reduce over time, e.g. per difficulty period to counter the improvements in quantum computing.

Of course that would also limit the capacity of the real owners of these BTC to react to a threat and to move the coins fastly. But for example I can imagine the following recovery protocol:

- Instead of moving your P2PK funds, you can designate another address as a recovery address. This addresses private key must be used in the next transaction spending the P2PK output, and in the same tx, you have to designate a quantum-resistant address to be used in further transactions.
- This address must have received coins in the same year or at least the same halving period when your P2PK output was created, but its public key must not be known. (Yes, that's a difficult requirement, but otherwise the quantum attacker can designate any address.)
- The recovery address must be related in some way to your P2PK funds (e.g. there were some transactions between both addresses/keys, or they were related to the same mining pool ...).


These are of course stupid layman ideas, but I'd be interested if experts came up with something similar.

███████████████████████████
███████▄████████████▄██████
████████▄████████▄████████
███▀█████▀▄███▄▀█████▀███
█████▀█▀▄██▀▀▀██▄▀█▀█████
███████▄███████████▄███████
███████████████████████████
███████▀███████████▀███████
████▄██▄▀██▄▄▄██▀▄██▄████
████▄████▄▀███▀▄████▄████
██▄███▀▀█▀██████▀█▀███▄███
██▀█▀████████████████▀█▀███
███████████████████████████
.
.Duelbits PREDICT..
█████████████████████████
█████████████████████████
███████████▀▀░░░░▀▀██████
██████████░░▄████▄░░████
█████████░░████████░░████
█████████░░████████░░████
█████████▄▀██████▀▄████
████████▀▀░░░▀▀▀▀░░▄█████
██████▀░░░░██▄▄▄▄████████
████▀░░░░▄███████████████
█████▄▄█████████████████
█████████████████████████
█████████████████████████
.
.WHERE EVERYTHING IS A MARKET..
█████
██
██







██
██
██████
Will Bitcoin hit $200,000
before January 1st 2027?

    No @1.15         Yes @6.00    
█████
██
██







██
██
██████

  CHECK MORE > 
goldkingcoiner
Legendary
*
Offline Offline

Activity: 2716
Merit: 2866


HoDL


View Profile WWW
March 03, 2026, 09:39:39 PM
 #2

I cannot think of anything that would not include rollbacks or softforks.

But this is a theoretical problem that might be moot, if true quantum computers turn out to be unachievable.
The closest we might get to a quantum computer is a clever algorithmic imitation.


███████████████████████████
███████▄████████████▄██████
████████▄████████▄████████
███▀█████▀▄███▄▀█████▀███
█████▀█▀▄██▀▀▀██▄▀█▀█████
███████▄███████████▄███████
███████████████████████████
███████▀███████████▀███████
████▄██▄▀██▄▄▄██▀▄██▄████
████▄████▄▀███▀▄████▄████
██▄███▀▀█▀██████▀█▀███▄███
██▀█▀████████████████▀█▀███
███████████████████████████
.
.Duelbits PREDICT..
█████████████████████████
█████████████████████████
███████████▀▀░░░░▀▀██████
██████████░░▄████▄░░████
█████████░░████████░░████
█████████░░████████░░████
█████████▄▀██████▀▄████
████████▀▀░░░▀▀▀▀░░▄█████
██████▀░░░░██▄▄▄▄████████
████▀░░░░▄███████████████
█████▄▄█████████████████
█████████████████████████
█████████████████████████
.
.WHERE EVERYTHING IS A MARKET..
█████
██
██







██
██
██████
Will Bitcoin hit $200,000
before January 1st 2027?

    No @1.15         Yes @6.00    
█████
██
██







██
██
██████

  CHECK MORE > 
Donneski
Full Member
***
Offline Offline

Activity: 588
Merit: 171


Contact Hhampuz for campaign


View Profile
March 04, 2026, 07:41:43 AM
 #3

The uncomfortable reality is that once the public key is exposed (as in P2PK), there isn’t much you can really add later without effectively redefining ownership. Any extra requirement risks becoming subjective or socially enforced rather than purely cryptographic.

That’s why the hourglass idea feels more grounded to me. It doesn’t pretend to make exposed keys safe again, it just slows down a potential attacker at the consensus level. That seems more in line with how Bitcoin usually handles hard problems... mitigate the damage instead of trying to rewrite the past.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!