From: Light <bitcoin-dev@lightco.in>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] The Bitcoin Lost and Found
Date: Tue, 05 May 2026 07:38:45 -0400 [thread overview]
Message-ID: <db16b0f2-6b21-4eba-a562-df3659f6a8f4@app.fastmail.com> (raw)
Hello list,
There have recently been multiple (uncharacteristically confiscatory!) proposals put forward
to answer the question of "what to do with quantum-vulnerable coins?"[a][b] For reasons I have
explained elsewhere, I reject the meta-premise of the question i.e. that there is any discussion
to be had at all with regard to these coins, at least at the level of bitcoin consensus.[c] However,
these proposals are not entirely without merit: they have generated both discussion and code
that may still prove useful even if bitcoin consensus has nothing new to say about the disposition
of these coins.[d]
It is in the spirit of turning confiscatory lemons into cypherpunk lemonade that I present to
this list the Bitcoin Lost and Found protocol. The protocol takes noticeable inspiration from both
BIP-361 Phase B and the Hourglass proposal, but it does so without asking bitcoin consensus
to actively intervene in anyone's spending abilities. A long-form description of the protocol can be
found below.
If there is sufficient interest, I intend to advance this proposal as an application-layer
standard for the recovery and recirculation of coins held in addresses secured by "weak"
private keys, such as those vulnerable to a CRQC. I welcome and look forward to any feedback the
list may have to offer.
Regards,
Light
[a] https://groups.google.com/g/bitcoindev/c/0E1UyyQIUA0
[b] https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki
[c] https://lightco.in/2026/04/14/quantum/
[d] https://gist.github.com/Roasbeef/563f173fe44e2005e003a082716e586f#zk-proofs-for-migration-and-recovery
# Description
The Bitcoin Lost and Found is an application-layer standard for the recovery and recirculation
of coins that have been lost and found by way of "cracking" a "weak" bitcoin private key. Research
indicates that thousands of BTC has already been lost and found this way.[1][2][3] With the possibility
of breakthroughs in quantum computing, classical computing, and/or cryptanalysis, that number could
rise to include all currently-circulating BTC depending on the weakness that is exploited and the
capabilities of the attacker.[4]
The Bitcoin Lost and Found provides security researchers, hackers, quantum computer operators, and
anyone else who discovers weak bitcoin private key material a standard protocol for disposing of any
coins held by the keys. There is a cryptographically-secure path to recovery of coins whose keys were
generated using a standard seed, or which had a timestamped proof of knowledge of the private key,
with a fallback path that eventually and gradually returns the coins back into circulation using bitcoin's
existing mining mechanism.
# Motivation
If you are an ethical individual and you generate a bitcoin private key that already has a balance,
then realize that it would be easy for someone else with some technical know-how to generate that
private key as well, what do you do?
One option, probably the safer option from your perspective, is to not move the coins. You could
instead try to let the owner of the coins know about the weak private key by posting a message to
some public message boards. The message could include the address that was generated with some
kind of secure proof that you do indeed know the private key, so that the message is credible,
along with a warning about the weakness and instructions for the owner to move the coins to a
secure wallet. The risk is that an attacker beats the owner of the coins to the punch by generating
the private key and taking the coins for themselves before the owner has a chance to move them.
The other option is to move the coins into your own secure wallet, so that an attacker does not
get to them first, and then attempt to return the coins to their owner. The fundamental problem
with this approach is verification: even if you put the word out and receive a response from
someone claiming to be the owner, how do you verify that they are indeed the "real" owner of the
coins? The private keys are known to be insecure, so you cannot rely on a cryptographic signature
from them. And if the coins were acquired anonymously, for example by mining or buying p2p, then
it would be difficult or maybe even impossible for the owner to produce a verifiable proof of
purchase. Less fundamental but still very real are all the legal challenges associated with this
approach, including liability, tax, regulatory compliance, questions of jurisdiction, etc etc. Maybe
not insurmountable, but also maybe not worth the effort depending on the value of the coins that
were found and any compensation that may be offered as a bounty for secure recovery.
The Bitcoin Lost and Found offers a third option, one that requires no interaction between the
finder of coins and their owner: the finder can send the coins to a special address where the
owner can recover them using a cryptographic proof, as long as the coins were originally held
in an address that was either generated using a BIP-32 seed or had a timestamped proof of knowledge
of the private keys. If the coins are not recovered within 100 years (well beyond current average
life expectancy) then the coins will gradually re-enter circulation using bitcoin's existing mining
mechanism.[5]
> Note: The Bitcoin Lost and Found does not guarantee recoverability of all coins sent to it. Only
> coins that were sent to the Bitcoin Lost and Found from an address generated using a BIP-32 seed,
> or whose original owner timestamped a proof of knowledge of the address' private key, can be recovered
> using this protocol. There is a non-zero chance that if coins are sent to the Bitcoin Lost and Found
> then they will not be able to be recovered, since not all wallets use BIP-32 seeds, and not all
> coinholders will timestamp a proof of knowledge.
>
> For addresses generated after the invention of BIP-32, there is a high a likelihood that they will
> be recoverable, since most modern wallets generate their private keys using BIP-32. And for coins
> held in non-BIP-32 "JBOK" wallets, there is a low risk and potentially high reward for the owner to
> timestamp a proof of knowledge, increasing the likelihood that attentive coinholders will create
> such timestamps. Finders can now weigh these probabilities against the probability that someone with
> less virtuous intentions generates the private keys and takes the coins for their own private gain.
# Specification
There are two components to the Bitcoin Lost and Found:
1) The Recovery address, and
2) The Recirculation address
When weak key material securing one or more bitcoin UTXOs is found by someone who is not the "true
owner" of the UTXOs, then the finder MUST immediately transfer all UTXOs secured by the weak key material
to the Recovery address.
> Note: If the finder is aware of the existence of a cryptographically-relevant quantum computer (CRQC),
> then the finder MUST send the UTXOs to the post-quantum secure version of the Recovery address.
## The Recovery address
UTXOs encumbered by the Recovery address MUST only be able to be spent under one of three conditions:
1) The spender of the UTXO MUST supply a zero-knowledge proof of knowledge that cryptographically
proves that the spender knows the BIP-32 seed used to generate the weak key material that the UTXO
originated from (a "zkPKS"), or [6]
2) The spender of the UTXO MUST supply a zero-knowledge proof of knowledge that cryptographically
proves that prior to the creation of the UTXO, the spender created a timestamp of a proof of knowledge
of the weak private key that the UTXO originated from (a "PACT"), or [7]
3) Starting 5,250,000 blocks after the creation of the UTXO, anyone can spend up to 1% of the UTXO
balance, or 100,000 sats, whichever is greater, and MUST send the change to the Recirculation address.
> Note: The post-quantum secure version of the recovery address has two modified spending conditions:
>
> - For condition (1), the spender MUST provide a PQ zkPKS e.g. a zkSTARK
>
> - For condition (2), the PACT MUST have been made prior to block `X`. `X` MUST be standardized after
> a CRQC is known to exist, and MUST be set conservatively to a block height that is prior to the presumed
> date of invention of the CRQC, to minimize the likelihood of a CRQC operator abusing this protocol, but
> also recent enough to give time after the publication of this standard for coinholders to produce their
> PACTs so that this protocol can be used effectively. The standard for `X` can be updated for new deposits
> if the intial block height chosen turns out to be too late.
## The Recirculation address
UTXOs encumbered by the Recirculation address MUST only be able to be spent according to the following
condition:
1) After a relative timelock of 1 block, anyone can spend up to 1% of the value of the UTXO, or
100,000 sats, whichever is greater, and MUST send the change (if any) to the Recirculation address.
# Out of scope
The following considerations are explicitly out of scope:
- **Enabling recovery of coins whose private keys were not generated using a BIP-32 seed or secured with
a PACT.** This is not for a lack of interest; if anyone has any ideas for how to do this, the author is
open to suggestions!
- **Changing consensus to disable the spending of coins that are held in addresses derived from "weak"
private keys.** This proposal is intentionally designed as an application-layer standard, because using
consensus to intentionally impair the ability to spend specific coins runs contrary to bitcoin's utility
as a p2p electronic cash system and therefore risks fatally undermining public confidence in bitcoin.
# Alternatives considered
- In the current proposal, the Recirculation address was specified to provide some way for the coins
to re-enter circulation, akin to future generations finding buried treasure, providing more certainty
over the eventual disposition of the coins. As an alternative, coins transferred to the Recovery address
could instead remain there for an indefinite amount of time until they are spent using a zkPKS. This would
not provide the same level of certainty as the current proposal, but would substantially reduce the
proposal's argument surface. Whether or not inclusion of the Recirculation address is preferable to the
bitcoin standards community, and therefore whether or not it makes it into the finalized proposal, is open
to discussion. The author is also open the possibility of two standards existing: a "v1" with the Recirculation
address, and a "v2" without the Recirculation address. Finders could then choose which standard to follow
based on their own preference.
# Dependencies
The Bitcoin Lost and Found depends upon support for verifying a (post-quantum) zkPKS in Script, along
with a recursive covenant that enforces change destinations in perpetuity, ideally using standard bitcoin
transactions.[8] These capabilities do not yet exist in bitcoin, but could be added with a soft fork that includes
OP_CAT and OP_MUL e.g. BIP-441 and a recursive covenant opcode such as OP_TX, or opcodes with equivalent
capabilities.[9][10][11] Alternatively, we could use a soft fork to add a new smart contract language to bitcoin that
has these capabilities, such as Basic Bitcoin Lisp or Simplicity.[12][13]
# Prior art
This idea for the Recovery address was inspired by a conversation between the author, Matt Corallo, and
Ethan Heilman about the author's proposal that anyone who uses a cryptographically-relevant quantum
computer to crack bitcoin private keys should burn the coins using `OP_RETURN`.[14] In response to this
proposal, Matt suggested that rather than burn the coins, they could be sent to a recovery address that
requires a PQ zkPKS to spend from the address. This document is an elaboration of this suggestion into a
full protocol.
Related prior art on the general topic of using zero-knowledge proofs for the recovery of quantum-vulnerable
coins can be found here: https://gist.github.com/Roasbeef/563f173fe44e2005e003a082716e586f#zk-proofs-for-migration-and-recovery
The concept of the Recirculation address was inspired by Hourglass.[15]
# References
[1] https://cs.unm.edu/~vasek/papers/vasekfc16.pdf
[2] https://milksad.info/disclosure.html
[3] https://bitcoinmagazine.com/technical/critical-vulnerability-found-in-android-wallets-1376273924
[4] https://github.com/presidiobtc/bitcoin-quantum/#how-quantum-affects-bitcoin
[5] https://ourworldindata.org/grapher/life-expectancy
[6] https://lightco.in/2026/04/14/quantum
[7] https://www.paradigm.xyz/2026/05/pacts-protecting-your-bitcoin-from-a-quantum-sunset
[8] https://developer.bitcoin.org/devguide/transactions.html#standard-transactions
[9] https://x.com/_julian256_/status/2029931162685080039
[10] https://github.com/bitcoin/bips/blob/master/bip-0441.mediawiki
[11] https://github.com/rustyrussell/bips/blob/68125328504930d8f5efdd594f600749ce75f130/bip-unknown-optx.mediawiki
[12] https://bitcoinops.org/en/topics/basic-bitcoin-lisp-language/
[13] https://bitcoinops.org/en/topics/simplicity/
[14] https://x.com/lightcoin/status/1892987447471911005
[15] https://github.com/cryptoquick/bips/blob/hourglass-v2/bip-hourglass-v2.mediawiki
--
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/db16b0f2-6b21-4eba-a562-df3659f6a8f4%40app.fastmail.com.
next reply other threads:[~2026-05-05 12:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 11:38 Light [this message]
2026-05-05 13:23 ` [bitcoindev] Re: The Bitcoin Lost and Found waxwing/ AdamISZ
2026-05-05 20:07 ` Light
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db16b0f2-6b21-4eba-a562-df3659f6a8f4@app.fastmail.com \
--to=bitcoin-dev@lightco.in \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox