First Quantum resistant wallet and transaction in the world!!!

[harmani21]

# First Quantum-Resistant Bitcoin Transaction Using mask512 Derivation

I've successfully broadcast the first quantum-resistant Bitcoin transaction
to mainnet using a novel dual-signature scheme.

Transaction: https://blockstream.info/tx/143d47830c1d757583f9685396b2fb89778c47b9fc1c0d640b27bf01a366ded4

## How It Works
- Dual-lock P2SH: ECDSA signature + SHA256 hash preimage
- Even if quantum computers break ECDSA, hash preimage remains secure
- Requires 2^128 operations to break (impossible for quantum computers)
- Works on Bitcoin TODAY - no consensus changes needed

## Technical Details
- Transaction size: 510 bytes (vs normal ~190 bytes)
- Uses mask512 derivation: single seed → ECDSA key + unlock secret
- Script: <pubkey> OP_CHECKSIGVERIFY OP_HASH256 <commitment> OP_EQUAL

## Code
Link to GitHub repo coming soon

Thoughts? Feedback welcome!
```

[stwenhao]

Thoughts? Feedback welcome!

You should put the hash first, and the public key second, because then, OP_CODESEPARATOR can be used, to split public key from additional conditions, so then old wallets could sign it properly. For example:

Code:

OP_HASH256 <commitment> OP_EQUALVERIFY
OP_CODESEPARATOR
<pubkey> OP_CHECKSIG

And then, it is spendable by "<signature> <data>", where signature can be correctly generated by many existing wallets, if you give them "<pubkey> OP_CHECKSIG" as a Script, and then, data can be attached even by manually inserting it into transaction HEX in any text editor.

Even if quantum computers break ECDSA, hash preimage remains secure

Wrong, because a malicious miner will know the solution, when your transaction will be flying as unconfirmed in mempools. You should think about something, which will require some effort, even if miners will know everything. For example: https://bitcointalk.org/index.php?topic=5557305.0

Requires 2^128 operations to break (impossible for quantum computers)

It requires only getting the private key, and making a successful double-spend with higher fees. And if it has a single confirmation, then it requires reorging a single block, which is currently something around 2^80, rather than 2^128.

Transaction size: 510 bytes (vs normal ~190 bytes)

It is more expensive, than it could be, because you didn't use Segwit.

[harmani21]

# First Quantum-Resistant Bitcoin Transaction Using mask512 Derivation

I've successfully broadcast the first quantum-resistant Bitcoin transaction
to mainnet using a novel dual-signature scheme.

Transaction: https://blockstream.info/tx/143d47830c1d757583f9685396b2fb89778c47b9fc1c0d640b27bf01a366ded4

## How It Works
- Dual-lock P2SH: ECDSA signature + SHA256 hash preimage
- Even if quantum computers break ECDSA, hash preimage remains secure
- Requires 2^128 operations to break (impossible for quantum computers)
- Works on Bitcoin TODAY - no consensus changes needed

## Technical Details
- Transaction size: 510 bytes (vs normal ~190 bytes)
- Uses mask512 derivation: single seed → ECDSA key + unlock secret
- Script: <pubkey> OP_CHECKSIGVERIFY OP_HASH256 <commitment> OP_EQUAL

## Code
Link to GitHub repo coming soon

Thoughts? Feedback welcome!
```

   SCENARIO: Two Quantum Holders Battle
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Time 0: You broadcast tx (1 BTC, 0.001 fee)

Time +30s:
Attacker quantum extracts key
Broadcasts double-spend (1 BTC, 0.01 fee)

Time +60s:
You quantum extract attacker's key 
Broadcast triple-spend (1 BTC, 0.1 fee)

Time +90s:
Attacker: quadruple-spend (0.5 fee)

Time +120s:
You: quintuple-spend (0.8 fee)

Time +150s:
Attacker: sextuple-spend (0.95 fee)

Time +180s:
You: septuple-spend (0.99 fee)

Time +200s:
Attacker: octuple-spend (0.999 fee)

Time +210s:
Mempool has 50 versions of same tx
All from same two quantum computers
Each outbidding the other
Final fee: 0.99999 BTC

Miner: "Thanks for the 1 BTC fee guys!" 🤑

NOBODY GETS THE BITCOIN! 😂😂😂

[ABCbits]

- Dual-lock P2SH: ECDSA signature + SHA256 hash preimage

- Requires 2^128 operations to break (impossible for quantum computers)

FWIW, P2SH vulnerable to birthday attack/paradox that reduce P2SH security to 2^80 towards collision attack.

[stwenhao]

P2SH vulnerable to birthday attack/paradox that reduce P2SH security to 2^80 towards collision attack.

Well, 2^160 for preimage, and 2^80 for collisions. But the first collision will raise some panic, because then, someone could lock things on "<pubkey> OP_CHECKSIG" and "<pubkey> OP_CHECKSIGVERIFY OP_HASH256 <commitment> OP_EQUAL", leading to the same address.

Also, if anyone will move coins from 3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay or 39VXyuoc6SXYKp9TcAhoiN1mb4ns6z3Yu6, then it will alert everyone, that 160-bit addresses should be abandoned (or a different hash function should be used). See topic: https://bitcointalk.org/index.php?topic=293382.0

[pooya87]

Time +30s:
Attacker quantum extracts key
~
Miner: "Thanks for the 1 BTC fee guys!" 🤑

NOBODY GETS THE BITCOIN! 😂😂😂

This is like a paradox!

Bitcoin exists (miners mine it, there is a market where it is worth $100k) because it is secure and nobody can break it. If a time comes when it takes 30 seconds to break ECDSA the it would have had ceased to exist (no miners and no value) which means nobody would bother taking this 1 BTC in your hypothetical scenario since it would be worth $0

[TothAnalyst]

How does the mask512 dual-signature scheme compare to existing post-quantum approaches in terms of security guarantees and transaction size, and do you think it could realistically scale for widespread Bitcoin adoption?

# First Quantum-Resistant Bitcoin Transaction Using mask512 Derivation

I've successfully broadcast the first quantum-resistant Bitcoin transaction
to mainnet using a novel dual-signature scheme.

Transaction: https://blockstream.info/tx/143d47830c1d757583f9685396b2fb89778c47b9fc1c0d640b27bf01a366ded4

## How It Works
- Dual-lock P2SH: ECDSA signature + SHA256 hash preimage
- Even if quantum computers break ECDSA, hash preimage remains secure
- Requires 2^128 operations to break (impossible for quantum computers)
- Works on Bitcoin TODAY - no consensus changes needed

## Technical Details
- Transaction size: 510 bytes (vs normal ~190 bytes)
- Uses mask512 derivation: single seed → ECDSA key + unlock secret
- Script: <pubkey> OP_CHECKSIGVERIFY OP_HASH256 <commitment> OP_EQUAL

## Code
Link to GitHub repo coming soon

Thoughts? Feedback welcome!
```

[GaloisGhost]

Why do you think the pre-image makes it secure? When Quantum Computers achieve fully maturity, we will need to worry about the implications of Shor's Algorithm and Grover's Algorithm.

Haven't you heard about Grover's Algorithm?
https://arxiv.org/pdf/2202.10982
Applying Grover’s Algorithm to Hash Functions: A Software Perspective

[internetional]

The title mentions a quantum-resistant wallet, but as far as I understand, there is no "first quantum-resistant wallet in the world" here yet, right? So far, we are only talking about just one "quantum-resistant transaction". And even there, the discussion mixes two different meanings of the word "resistance": resistance as an additional cryptographic lock, and resistance as the impossibility of a practical attack. At the moment, the OP is only proposing resistance in the first sense. There is no discussion at all of a wallet that would actually allow the owner to keep their bitcoins in the presence of a quantum adversary.

Or by choosing this title, is the OP implying that they already have a solution to that problem as well?

[jwlcore]

Interesting experiment, but it’s important to separate script-level constructions from actual post-quantum authorization.

The approach described here still relies on ECDSA as the authorizing primitive. The hash preimage only adds an extra condition, but does not remove ECDSA as a single point of failure. Once a valid signature is visible in the mempool, a quantum adversary can extract the private key and attempt a higher-fee double spend.

This is why such constructions don’t meaningfully change the threat model they wrap ECDSA instead of replacing it.

A real post-quantum design requires:
   removing ECDSA from the authorization path
   introducing a new signature primitive verified by all nodes
   enforcing it at the consensus level, not as a P2SH policy trick

In our work we’re addressing exactly these issues by adding a native post-quantum signature opcode and a separate consensus validation path, with full negative testing (invalid sigs, invalid sighash, size limits, script errors). https://bitcointalk.org/index.php?topic=5569815.0

This avoids mempool race attacks, fee-bumping games, and “quantum double-spend auctions”, because authorization no longer depends on ECDSA at all.

Script-level experiments are useful for exploration, but post-quantum security ultimately requires protocol-level changes.

[NotATether]

This is not really a quantum-resistant transaction, because you did not emulate some quantum-resistant algorithm inside the locking script.

There are a bunch of NIST algorithms rated for quantum-safe usage, but you will have to design them in Bitcoin Script by hand, as none exist already AFAIK.