From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: The Bitcoin Lost and Found
Date: Tue, 5 May 2026 06:23:03 -0700 (PDT) [thread overview]
Message-ID: <d0fb6249-d436-48c2-9dc1-0ed6fa25c988n@googlegroups.com> (raw)
In-Reply-To: <db16b0f2-6b21-4eba-a562-df3659f6a8f4@app.fastmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 16012 bytes --]
Hi Light,
I like the general flavor of the Lost and Found proposal, I suspect we are
very philosophically aligned on this. Albeit, this is *not* going to stop
the argument, but I'm sure you're well aware of that :)
I'm probably against Recirculation as an idea. If even thinking about
confiscation is a mistake (your "meta" comment; I agree), then maybe that's
also true about changing system incentives with different redistributions.
Maybe.
But on a technical question:
- **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!
I'm thinking about taproot sans bip32. If can satisfy a script path spend
then you could in theory prove with (merkle proof + validating spend)
inside a QR ZKP. No?
On reflection it's little more than a small side-issue, because even where
taproot is used, it is not generally used with script paths that much, and
where it is used, it's usually with things like BIP86, i.e. BIP32
derivation. But I *think* as a footnote, it's valid?
Cheers,
AdamISZ/waxwing
On Tuesday, May 5, 2026 at 9:00:25 AM UTC-3 Light wrote:
> 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/d0fb6249-d436-48c2-9dc1-0ed6fa25c988n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 23260 bytes --]
next prev parent reply other threads:[~2026-05-05 13:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 11:38 [bitcoindev] The Bitcoin Lost and Found Light
2026-05-05 13:23 ` waxwing/ AdamISZ [this message]
2026-05-05 20:07 ` [bitcoindev] " 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=d0fb6249-d436-48c2-9dc1-0ed6fa25c988n@googlegroups.com \
--to=ekaggata@gmail.com \
--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