Bitcoin Development Mailinglist
 help / color / mirror / Atom feed
* [bitcoindev] QSAVE post-quantum solution for non-migrated coins
@ 2026-09-22 23:13 'James T' via Bitcoin Development Mailing List
  0 siblings, 0 replies; only message in thread
From: 'James T' via Bitcoin Development Mailing List @ 2026-09-22 23:13 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 5102 bytes --]

 

QSAVE is a post-quantum transition solution that avoids burning coins. I 
have tried to incorporate the feedback I received on my earlier posts. The 
proposed solution is laid out in five draft BIPs, with MediaWiki sources at 
https://www.qsave.org/legal/bip-suite.

Earlier posts were: [BIP Proposal] No burn, Quantum Migration Proposal, 
Quantum Secure Asset Verification & Escrow (QSAVE)

1. bip-qsave-conditional-spending: classifies every spent input and sends 
spends without a second factor to recovery.

2. bip-qsave-watermarks: pre-cutoff commitments and the registry of 
accepted second factors.

3. bip-qsave-seed-derivation-factor: a zero-knowledge proof that one seed 
derives both the spent script and the post-quantum authority.

4. bip-qsave-protective-recovery: the lost-property output and the two ways 
it is released.

5. bip-qsave-p2mr-zkstark: a zk-STARK spend leaf for BIP 360 P2MR outputs.

QD5 is an optional source-matched authority profile using an independently 
backed-up ML-DSA-87 key. It can be admitted as an automatic-factor route, 
but it is not required for every coin unless a later consensus deployment 
marks it mandatory for a defined source class. That marking would send 
inputs without QD5 or an accepted replacement factor through protective 
recovery.

QSAVE is an alternative to BIP 361 or Hourglass for handling coins left 
behind in a post-quantum chain migration. It has no sunset or burn; 
instead, it proposes a lost-property process. The scheme can be implemented 
in the 'do-nothing' scenario by making white-hat hacking legal where the 
intent is to protect the coins. I hope a soft fork can be agreed upon that 
would make transfer to lost-property addresses the only output possible for 
a non-migrated address after a certain block height. If such a soft fork 
cannot be agreed upon, we would be in a quantum safari situation, with 
white-hat hackers competing with black-hat hackers and a great deal of 
law-enforcement activity, which would be unfortunate.

Our proposal is to add a second factor that provides a quantum-resistant 
proof of ownership. After a certain block height, coins can no longer be 
spent with their ECC key alone. The script and its signatures are still 
required as factor one, but a second factor is also needed, such as a proof 
that the address derives from the wallet seed, or a post-quantum binding 
record committed before the cutoff height.

If the second factor is missing, the coin can only be moved to protective 
recovery: a lost-property address that allows a longer recovery period. 
During the recovery period, which might be indefinite for some coins, the 
policy may direct returns to charities. This is along the lines of the 
Dormant Assets Act 2022 in the UK; the legal and economic treatment remains 
outside Bitcoin consensus.

The design is intended to provide three things:

1. The existing private key is still required, quantum-derived or not, so 
nothing happens faster than it would in the do-nothing branch.

2. A missing second factor never burns the coin; there is no sunset.

3. An on-chain asymmetric proof of ownership spends the coin directly with 
no third party, or an off-chain route can eventually recover it through a 
lost-property office and an evidentiary procedure.

From the enforcement height (which consensus can switch on at any time), 
ordinary validation runs first. Each input of a valid transaction is then 
classified. POST_QUANTUM_NATIVE inputs match an entry in the activated 
native-path registry and are authorized by that path's own rules. 
Everything else is UNMIGRATED_TWO_FACTOR_REQUIRED, including unknown and 
future script types. If any unmigrated input lacks a valid second factor, 
every spendable output must be a recovery output. A set of decentralized 
custodians hold recovery outputs, with a backup custodian and a veto 
controller. This keeps funds decentralized while avoiding capture by an 
errant actor. Funds held as lost property can earn conservative returns 
(0.5%) that can be directed toward charitable purposes.

Recovery from this state may be automatic if you provide second-factor 
information. If no on-chain second-factor information is available, you 
must undertake evidence-based recovery. This way, all coins, including 
early Satoshi-era coins, can earn money for charity and be reclaimed in 
perpetuity. Although this is no longer a permissionless process (humans are 
involved), all the other routes lead to human (usually law enforcement) 
involvement, so we think this is the better consensus approach. If Bitcoin 
doesn't resolve this problem, someone else will do it for us, and that is 
unlikely to be a good outcome. 

Thanks,

James Tagg

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/305ed790-577c-4c94-a92a-1e15c4536b40n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5459 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2026-09-22 23:14 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-22 23:13 [bitcoindev] QSAVE post-quantum solution for non-migrated coins 'James T' via Bitcoin Development Mailing List

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox