From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 05 May 2026 06:41:54 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wKG24-0003Fn-NE for bitcoindev@gnusha.org; Tue, 05 May 2026 06:41:54 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-42fb973b2a2sf5437208fac.1 for ; Tue, 05 May 2026 06:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777988507; x=1778593307; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=q/eFW+9KkegwWxImewoLCqZDLXSmYZDk1hVnTWIfsMQ=; b=fgn2pzWnfbCs9DElDnD2vA/4+8ZtMhvcU1uikX3fYe9mAXkr9SB+YXzPQfMdjxNK9U kb2P3YGCDb6l6O4bEzh5AacuFJg712iKGCFeL+NCqwzWDNqLnuIYjaHVzPi1D4VzAmBd bVlXmxKXZ9T+3uuxpRndQy7hc1aFh/sel6S6xF7MjQwHRzpP42NyYtfovmo0HsaCA4tx LjHf2WuJj8us6K4pua+ALYCzOePGMtw4BTnNQLFqq693oV5K5A5GH5Xb9ZJlolfOvDDi RM2NCpAa6q8lkXtBt1ECSLvzkaiBjILbPmKMu1TYW7SDnU4reh4PKO1o9S8l0O1ZkjIJ bBgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777988507; x=1778593307; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=q/eFW+9KkegwWxImewoLCqZDLXSmYZDk1hVnTWIfsMQ=; b=gn/JPt8SkHh1iDXev1X3iuWNoAzVDiDIvnuxPegjNN+BjHVuUc1ddixku4IUeowUrU mDbpHmkoF3V1BNBynPAolLPFyaxquG1mmVnzteLDF8T4EcVVXJMEFgFUGQ7M2gOpvzwt l7OBosAoh5AdY6oVgFej04/tkZXnroCfRyr4X7rxhOdi1B1McctyrB8jzJw5E5ySI+Yz 8YYW5UkoSW5wcPCf6VcEsn4sT1DnXB4inS5eOgrdENpRQn5zty2q+tSXQCPyN3+x5rle 58u1yEURQ1Teq1zgFH6zpNnAmqL9MaJhNopaYJohR4dADIyyHdsxmbVtGyP9BRlHVGud Lp+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777988507; x=1778593307; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=q/eFW+9KkegwWxImewoLCqZDLXSmYZDk1hVnTWIfsMQ=; b=Uhi684L6gnxFDoiUm2wVjjIoppINfxMRAOIvqhDB0P3stvhWhZ2H/cqsnDD4CcBgq4 q9cE7LHM7FQi00kk7R6b4+64TfUA4ZLZMNonKyYgrLflgd6JH2dEO8Mkv/8ukE1yeShl 0RTVZsAq6CS9HoA7cYRKxz7mueb8axNG16nZbdzJZEs5mg1U8z9ufez69fPxWcBAUBjq mzrPWDieH/FEavT4z6LMKHisftg8Q/KvUXjcEgT6d1usUOk2YNQluBw6ih9jIu/coiKr +ivC01fHNcd280RRhHSf+T1UZtmMCZs5ToDORgpxzY5YWvKPjTLxB2vXrL3FBr4Ys3bR ci8g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ84RWyHJ1JwFUfLrySi1k3GOYKDN1eMcjGjMpy+SQMXYkw9W+o7qRtu4TxTxks7au7OFZDpv49M1O/R@gnusha.org X-Gm-Message-State: AOJu0YyDv+N4WHiIcv/2H1UEk8sB6WpD9bBESNMrDri0UvfnRsUe54N+ JA1ih+Ikv7ZlTavRfcTuVze1kudJEgDrFzhuEKmt1bpCG96V+Oilam2B X-Received: by 2002:a05:6871:8211:b0:42b:d0fa:771 with SMTP id 586e51a60fabf-434d417044cmr1799059fac.21.1777988506394; Tue, 05 May 2026 06:41:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMM8T3upcTjXfAhyq0A9MzKOZMD8py2J3g+/vU+PAhBk8A==" Received: by 2002:a05:6870:21ec:b0:423:732f:cc7d with SMTP id 586e51a60fabf-4342f9f359dls3648624fac.1.-pod-prod-09-us; Tue, 05 May 2026 06:41:42 -0700 (PDT) X-Received: by 2002:a05:6808:1645:b0:467:70eb:36ae with SMTP id 5614622812f47-47c89251835mr6932546b6e.29.1777988502548; Tue, 05 May 2026 06:41:42 -0700 (PDT) Received: by 2002:a05:690c:578f:b0:79a:c9dc:1f8d with SMTP id 00721157ae682-7bd7670b083ms7b3; Tue, 5 May 2026 06:23:04 -0700 (PDT) X-Received: by 2002:a05:690c:c4f9:b0:7bd:4a12:706 with SMTP id 00721157ae682-7bd76fdce16mr141682247b3.21.1777987384146; Tue, 05 May 2026 06:23:04 -0700 (PDT) Date: Tue, 5 May 2026 06:23:03 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: [bitcoindev] Re: The Bitcoin Lost and Found MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3818_1512059388.1777987383677" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_3818_1512059388.1777987383677 Content-Type: multipart/alternative; boundary="----=_Part_3819_428027287.1777987383677" ------=_Part_3819_428027287.1777987383677 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Light, I like the general flavor of the Lost and Found proposal, I suspect we are= =20 very philosophically aligned on this. Albeit, this is *not* going to stop= =20 the argument, but I'm sure you're well aware of that :) I'm probably against Recirculation as an idea. If even thinking about=20 confiscation is a mistake (your "meta" comment; I agree), then maybe that's= =20 also true about changing system incentives with different redistributions.= =20 Maybe. But on a technical question: - **Enabling recovery of coins whose private keys were not generated using= =20 a BIP-32 seed or secured with=20 a PACT.** This is not for a lack of interest; if anyone has any ideas for= =20 how to do this, the author is=20 open to suggestions! I'm thinking about taproot sans bip32. If can satisfy a script path spend= =20 then you could in theory prove with (merkle proof + validating spend)=20 inside a QR ZKP. No? On reflection it's little more than a small side-issue, because even where= =20 taproot is used, it is not generally used with script paths that much, and= =20 where it is used, it's usually with things like BIP86, i.e. BIP32=20 derivation. But I *think* as a footnote, it's valid? Cheers, AdamISZ/waxwing On Tuesday, May 5, 2026 at 9:00:25=E2=80=AFAM UTC-3 Light wrote: > Hello list, > > There have recently been multiple (uncharacteristically confiscatory!)=20 > proposals put forward=20 > to answer the question of "what to do with quantum-vulnerable=20 > coins?"[a][b] For reasons I have=20 > explained elsewhere, I reject the meta-premise of the question i.e. that= =20 > there is any discussion=20 > to be had at all with regard to these coins, at least at the level of=20 > bitcoin consensus.[c] However,=20 > these proposals are not entirely without merit: they have generated both= =20 > discussion and code=20 > that may still prove useful even if bitcoin consensus has nothing new to= =20 > say about the disposition=20 > of these coins.[d] > > It is in the spirit of turning confiscatory lemons into cypherpunk=20 > lemonade that I present to=20 > this list the Bitcoin Lost and Found protocol. The protocol takes=20 > noticeable inspiration from both=20 > BIP-361 Phase B and the Hourglass proposal, but it does so without asking= =20 > bitcoin consensus=20 > to actively intervene in anyone's spending abilities. A long-form=20 > description of the protocol can be=20 > found below. > > If there is sufficient interest, I intend to advance this proposal as an= =20 > application-layer=20 > standard for the recovery and recirculation of coins held in addresses=20 > secured by "weak"=20 > private keys, such as those vulnerable to a CRQC. I welcome and look=20 > forward to any feedback the=20 > 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]=20 > https://gist.github.com/Roasbeef/563f173fe44e2005e003a082716e586f#zk-proo= fs-for-migration-and-recovery > > # Description > > The Bitcoin Lost and Found is an application-layer standard for the=20 > recovery and recirculation=20 > of coins that have been lost and found by way of "cracking" a "weak"=20 > bitcoin private key. Research=20 > indicates that thousands of BTC has already been lost and found this=20 > way.[1][2][3] With the possibility=20 > of breakthroughs in quantum computing, classical computing, and/or=20 > cryptanalysis, that number could=20 > rise to include all currently-circulating BTC depending on the weakness= =20 > that is exploited and the=20 > capabilities of the attacker.[4] > > The Bitcoin Lost and Found provides security researchers, hackers, quantu= m=20 > computer operators, and=20 > anyone else who discovers weak bitcoin private key material a standard=20 > protocol for disposing of any=20 > coins held by the keys. There is a cryptographically-secure path to=20 > recovery of coins whose keys were=20 > generated using a standard seed, or which had a timestamped proof of=20 > knowledge of the private key,=20 > with a fallback path that eventually and gradually returns the coins back= =20 > into circulation using bitcoin's=20 > existing mining mechanism. > > # Motivation > > If you are an ethical individual and you generate a bitcoin private key= =20 > that already has a balance,=20 > then realize that it would be easy for someone else with some technical= =20 > know-how to generate that=20 > private key as well, what do you do? > > One option, probably the safer option from your perspective, is to not=20 > move the coins. You could=20 > instead try to let the owner of the coins know about the weak private key= =20 > by posting a message to=20 > some public message boards. The message could include the address that wa= s=20 > generated with some=20 > kind of secure proof that you do indeed know the private key, so that the= =20 > message is credible,=20 > along with a warning about the weakness and instructions for the owner to= =20 > move the coins to a=20 > secure wallet. The risk is that an attacker beats the owner of the coins= =20 > to the punch by generating=20 > the private key and taking the coins for themselves before the owner has = a=20 > chance to move them. > > The other option is to move the coins into your own secure wallet, so tha= t=20 > an attacker does not=20 > get to them first, and then attempt to return the coins to their owner.= =20 > The fundamental problem=20 > with this approach is verification: even if you put the word out and=20 > receive a response from=20 > someone claiming to be the owner, how do you verify that they are indeed= =20 > the "real" owner of the=20 > coins? The private keys are known to be insecure, so you cannot rely on a= =20 > cryptographic signature=20 > from them. And if the coins were acquired anonymously, for example by=20 > mining or buying p2p, then=20 > it would be difficult or maybe even impossible for the owner to produce a= =20 > verifiable proof of=20 > purchase. Less fundamental but still very real are all the legal=20 > challenges associated with this=20 > approach, including liability, tax, regulatory compliance, questions of= =20 > jurisdiction, etc etc. Maybe=20 > not insurmountable, but also maybe not worth the effort depending on the= =20 > value of the coins that=20 > were found and any compensation that may be offered as a bounty for secur= e=20 > recovery. > > The Bitcoin Lost and Found offers a third option, one that requires no=20 > interaction between the=20 > finder of coins and their owner: the finder can send the coins to a=20 > special address where the=20 > owner can recover them using a cryptographic proof, as long as the coins= =20 > were originally held=20 > in an address that was either generated using a BIP-32 seed or had a=20 > timestamped proof of knowledge=20 > of the private keys. If the coins are not recovered within 100 years (wel= l=20 > beyond current average=20 > life expectancy) then the coins will gradually re-enter circulation using= =20 > bitcoin's existing mining=20 > mechanism.[5] > > > Note: The Bitcoin Lost and Found does not guarantee recoverability of= =20 > all coins sent to it. Only=20 > > coins that were sent to the Bitcoin Lost and Found from an address=20 > generated using a BIP-32 seed,=20 > > or whose original owner timestamped a proof of knowledge of the address= '=20 > private key, can be recovered=20 > > using this protocol. There is a non-zero chance that if coins are sent= =20 > to the Bitcoin Lost and Found=20 > > then they will not be able to be recovered, since not all wallets use= =20 > BIP-32 seeds, and not all=20 > > coinholders will timestamp a proof of knowledge. > >=20 > > For addresses generated after the invention of BIP-32, there is a high = a=20 > likelihood that they will=20 > > be recoverable, since most modern wallets generate their private keys= =20 > using BIP-32. And for coins=20 > > held in non-BIP-32 "JBOK" wallets, there is a low risk and potentially= =20 > high reward for the owner to=20 > > timestamp a proof of knowledge, increasing the likelihood that attentiv= e=20 > coinholders will create=20 > > such timestamps. Finders can now weigh these probabilities against the= =20 > probability that someone with=20 > > less virtuous intentions generates the private keys and takes the coins= =20 > 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=20 > someone who is not the "true=20 > owner" of the UTXOs, then the finder MUST immediately transfer all UTXOs= =20 > secured by the weak key material=20 > to the Recovery address. > > > Note: If the finder is aware of the existence of a=20 > cryptographically-relevant quantum computer (CRQC),=20 > > then the finder MUST send the UTXOs to the post-quantum secure version= =20 > of the Recovery address. > > ## The Recovery address > > UTXOs encumbered by the Recovery address MUST only be able to be spent=20 > under one of three conditions: > > 1) The spender of the UTXO MUST supply a zero-knowledge proof of knowledg= e=20 > that cryptographically=20 > proves that the spender knows the BIP-32 seed used to generate the weak= =20 > key material that the UTXO=20 > originated from (a "zkPKS"), or [6] > > 2) The spender of the UTXO MUST supply a zero-knowledge proof of knowledg= e=20 > that cryptographically=20 > proves that prior to the creation of the UTXO, the spender created a=20 > timestamp of a proof of knowledge=20 > 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= =20 > spend up to 1% of the UTXO=20 > balance, or 100,000 sats, whichever is greater, and MUST send the change= =20 > to the Recirculation address. > > > Note: The post-quantum secure version of the recovery address has two= =20 > modified spending conditions: > >=20 > > - 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`.= =20 > `X` MUST be standardized after=20 > > a CRQC is known to exist, and MUST be set conservatively to a block=20 > height that is prior to the presumed=20 > > date of invention of the CRQC, to minimize the likelihood of a CRQC=20 > operator abusing this protocol, but=20 > > also recent enough to give time after the publication of this standard= =20 > for coinholders to produce their=20 > > PACTs so that this protocol can be used effectively. The standard for= =20 > `X` can be updated for new deposits=20 > > 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=20 > spent according to the following=20 > condition: > > 1) After a relative timelock of 1 block, anyone can spend up to 1% of the= =20 > value of the UTXO, or=20 > 100,000 sats, whichever is greater, and MUST send the change (if any) to= =20 > the Recirculation address. > > # Out of scope > > The following considerations are explicitly out of scope: > > - **Enabling recovery of coins whose private keys were not generated usin= g=20 > a BIP-32 seed or secured with=20 > a PACT.** This is not for a lack of interest; if anyone has any ideas for= =20 > how to do this, the author is=20 > open to suggestions! > > - **Changing consensus to disable the spending of coins that are held in= =20 > addresses derived from "weak"=20 > private keys.** This proposal is intentionally designed as an=20 > application-layer standard, because using=20 > consensus to intentionally impair the ability to spend specific coins run= s=20 > contrary to bitcoin's utility=20 > as a p2p electronic cash system and therefore risks fatally undermining= =20 > public confidence in bitcoin. > > # Alternatives considered > > - In the current proposal, the Recirculation address was specified to=20 > provide some way for the coins=20 > to re-enter circulation, akin to future generations finding buried=20 > treasure, providing more certainty=20 > over the eventual disposition of the coins. As an alternative, coins=20 > transferred to the Recovery address=20 > could instead remain there for an indefinite amount of time until they ar= e=20 > spent using a zkPKS. This would=20 > not provide the same level of certainty as the current proposal, but woul= d=20 > substantially reduce the=20 > proposal's argument surface. Whether or not inclusion of the Recirculatio= n=20 > address is preferable to the=20 > bitcoin standards community, and therefore whether or not it makes it int= o=20 > the finalized proposal, is open=20 > to discussion. The author is also open the possibility of two standards= =20 > existing: a "v1" with the Recirculation=20 > address, and a "v2" without the Recirculation address. Finders could then= =20 > choose which standard to follow=20 > based on their own preference. > > # Dependencies > > The Bitcoin Lost and Found depends upon support for verifying a=20 > (post-quantum) zkPKS in Script, along=20 > with a recursive covenant that enforces change destinations in perpetuity= ,=20 > ideally using standard bitcoin=20 > transactions.[8] These capabilities do not yet exist in bitcoin, but coul= d=20 > be added with a soft fork that includes=20 > OP_CAT and OP_MUL e.g. BIP-441 and a recursive covenant opcode such as=20 > OP_TX, or opcodes with equivalent=20 > capabilities.[9][10][11] Alternatively, we could use a soft fork to add a= =20 > new smart contract language to bitcoin that=20 > 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= =20 > the author, Matt Corallo, and=20 > Ethan Heilman about the author's proposal that anyone who uses a=20 > cryptographically-relevant quantum=20 > computer to crack bitcoin private keys should burn the coins using=20 > `OP_RETURN`.[14] In response to this=20 > proposal, Matt suggested that rather than burn the coins, they could be= =20 > sent to a recovery address that=20 > requires a PQ zkPKS to spend from the address. This document is an=20 > elaboration of this suggestion into a=20 > full protocol. > > Related prior art on the general topic of using zero-knowledge proofs for= =20 > the recovery of quantum-vulnerable=20 > coins can be found here:=20 > https://gist.github.com/Roasbeef/563f173fe44e2005e003a082716e586f#zk-proo= fs-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]=20 > https://bitcoinmagazine.com/technical/critical-vulnerability-found-in-and= roid-wallets-1376273924 > [4]=20 > https://github.com/presidiobtc/bitcoin-quantum/#how-quantum-affects-bitco= in > [5] https://ourworldindata.org/grapher/life-expectancy > [6] https://lightco.in/2026/04/14/quantum > [7]=20 > https://www.paradigm.xyz/2026/05/pacts-protecting-your-bitcoin-from-a-qua= ntum-sunset > [8]=20 > https://developer.bitcoin.org/devguide/transactions.html#standard-transac= tions > [9] https://x.com/_julian256_/status/2029931162685080039 > [10] https://github.com/bitcoin/bips/blob/master/bip-0441.mediawiki > [11]=20 > https://github.com/rustyrussell/bips/blob/68125328504930d8f5efdd594f60074= 9ce75f130/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]=20 > https://github.com/cryptoquick/bips/blob/hourglass-v2/bip-hourglass-v2.me= diawiki > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= d0fb6249-d436-48c2-9dc1-0ed6fa25c988n%40googlegroups.com. ------=_Part_3819_428027287.1777987383677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Light,
I like the general flavor of the Lost and Found pr= oposal, 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 tha= t :)

I'm probably against Recirculation as an id= ea. 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 tech= nical question:

- **Enabling recovery of coins w= hose private keys were not generated using a BIP-32 seed or secured with=20
a PACT.** This is not for a lack of interest; if anyone has any ideas= for how to do this, the author is=20
open to suggestions!

I'm thinking about ta= proot sans bip32. If can satisfy a script path spend then you could in theo= ry prove with (merkle proof + validating spend) inside a QR ZKP. No?
<= div>
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=E2=80=AFAM UTC-3 Light wrote:
Hello list,

There have recently been multiple (uncharacteristically confiscatory!) = proposals put forward=20
to answer the question of "what to do with quantum-vulnerable coin= s?"[a][b] For reasons I have=20
explained elsewhere, I reject the meta-premise of the question i.e. tha= t there is any discussion=20
to be had at all with regard to these coins, at least at the level of b= itcoin consensus.[c] However,=20
these proposals are not entirely without merit: they have generated bot= h discussion and code=20
that may still prove useful even if bitcoin consensus has nothing new t= o say about the disposition=20
of these coins.[d]

It is in the spirit of turning confiscatory lemons into cypherpunk lemo= nade that I present to=20
this list the Bitcoin Lost and Found protocol. The protocol takes notic= eable inspiration from both=20
BIP-361 Phase B and the Hourglass proposal, but it does so without aski= ng bitcoin consensus=20
to actively intervene in anyone's spending abilities. A long-form d= escription of the protocol can be=20
found below.

If there is sufficient interest, I intend to advance this proposal as a= n application-layer=20
standard for the recovery and recirculation of coins held in addresses = secured by "weak"=20
private keys, such as those vulnerable to a CRQC. I welcome and look fo= rward to any feedback the=20
list may have to offer.

Regards,

Light

[a] https://groups.google.com/g/bitcoindev/c/0E1UyyQIUA0
[b] https://github.com/bitcoin/bips/blob/mast= er/bip-0361.mediawiki
[c] https://lightc= o.in/2026/04/14/quantum/
[d] https://gist.github.com/Roasbeef/5= 63f173fe44e2005e003a082716e586f#zk-proofs-for-migration-and-recovery

# Description

The Bitcoin Lost and Found is an application-layer standard for the rec= overy and recirculation=20
of coins that have been lost and found by way of "cracking" a= "weak" bitcoin private key. Research=20
indicates that thousands of BTC has already been lost and found this wa= y.[1][2][3] With the possibility=20
of breakthroughs in quantum computing, classical computing, and/or cryp= tanalysis, that number could=20
rise to include all currently-circulating BTC depending on the weakness= that is exploited and the=20
capabilities of the attacker.[4]

The Bitcoin Lost and Found provides security researchers, hackers, quan= tum computer operators, and=20
anyone else who discovers weak bitcoin private key material a standard = protocol for disposing of any=20
coins held by the keys. There is a cryptographically-secure path to rec= overy of coins whose keys were=20
generated using a standard seed, or which had a timestamped proof of kn= owledge of the private key,=20
with a fallback path that eventually and gradually returns the coins ba= ck into circulation using bitcoin's=20
existing mining mechanism.

# Motivation

If you are an ethical individual and you generate a bitcoin private key= that already has a balance,=20
then realize that it would be easy for someone else with some technical= know-how to generate that=20
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=20
instead try to let the owner of the coins know about the weak private k= ey by posting a message to=20
some public message boards. The message could include the address that = was generated with some=20
kind of secure proof that you do indeed know the private key, so that t= he message is credible,=20
along with a warning about the weakness and instructions for the owner = to move the coins to a=20
secure wallet. The risk is that an attacker beats the owner of the coin= s to the punch by generating=20
the private key and taking the coins for themselves before the owner ha= s a chance to move them.

The other option is to move the coins into your own secure wallet, so t= hat an attacker does not=20
get to them first, and then attempt to return the coins to their owner.= The fundamental problem=20
with this approach is verification: even if you put the word out and re= ceive a response from=20
someone claiming to be the owner, how do you verify that they are indee= d the "real" owner of the=20
coins? The private keys are known to be insecure, so you cannot rely on= a cryptographic signature=20
from them. And if the coins were acquired anonymously, for example by m= ining or buying p2p, then=20
it would be difficult or maybe even impossible for the owner to produce= a verifiable proof of=20
purchase. Less fundamental but still very real are all the legal challe= nges associated with this=20
approach, including liability, tax, regulatory compliance, questions of= jurisdiction, etc etc. Maybe=20
not insurmountable, but also maybe not worth the effort depending on th= e value of the coins that=20
were found and any compensation that may be offered as a bounty for sec= ure recovery.

The Bitcoin Lost and Found offers a third option, one that requires no = interaction between the=20
finder of coins and their owner: the finder can send the coins to a spe= cial address where the=20
owner can recover them using a cryptographic proof, as long as the coin= s were originally held=20
in an address that was either generated using a BIP-32 seed or had a ti= mestamped proof of knowledge=20
of the private keys. If the coins are not recovered within 100 years (w= ell beyond current average=20
life expectancy) then the coins will gradually re-enter circulation usi= ng bitcoin's existing mining=20
mechanism.[5]

> Note: The Bitcoin Lost and Found does not guarantee recoverability= of all coins sent to it. Only=20
> coins that were sent to the Bitcoin Lost and Found from an address= generated using a BIP-32 seed,=20
> or whose original owner timestamped a proof of knowledge of the ad= dress' private key, can be recovered=20
> using this protocol. There is a non-zero chance that if coins are = sent to the Bitcoin Lost and Found=20
> then they will not be able to be recovered, since not all wallets = use BIP-32 seeds, and not all=20
> coinholders will timestamp a proof of knowledge.
>=20
> For addresses generated after the invention of BIP-32, there is a = high a likelihood that they will=20
> be recoverable, since most modern wallets generate their private k= eys using BIP-32. And for coins=20
> held in non-BIP-32 "JBOK" wallets, there is a low risk a= nd potentially high reward for the owner to=20
> timestamp a proof of knowledge, increasing the likelihood that att= entive coinholders will create=20
> such timestamps. Finders can now weigh these probabilities against= the probability that someone with=20
> 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 s= omeone who is not the "true=20
owner" of the UTXOs, then the finder MUST immediately transfer all= UTXOs secured by the weak key material=20
to the Recovery address.

> Note: If the finder is aware of the existence of a cryptographical= ly-relevant quantum computer (CRQC),=20
> then the finder MUST send the UTXOs to the post-quantum secure ver= sion 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 knowle= dge that cryptographically=20
proves that the spender knows the BIP-32 seed used to generate the weak= key material that the UTXO=20
originated from (a "zkPKS"), or [6]

2) The spender of the UTXO MUST supply a zero-knowledge proof of knowle= dge that cryptographically=20
proves that prior to the creation of the UTXO, the spender created a ti= mestamp of a proof of knowledge=20
of the weak private key that the UTXO originated from (a "PACT&quo= t;), or [7]

3) Starting 5,250,000 blocks after the creation of the UTXO, anyone can= spend up to 1% of the UTXO=20
balance, or 100,000 sats, whichever is greater, and MUST send the chang= e to the Recirculation address.

> Note: The post-quantum secure version of the recovery address has = two modified spending conditions:
>=20
> - For condition (1), the spender MUST provide a PQ zkPKS e.g. a zk= STARK
>
> - For condition (2), the PACT MUST have been made prior to block `= X`. `X` MUST be standardized after=20
> a CRQC is known to exist, and MUST be set conservatively to a bloc= k height that is prior to the presumed=20
> date of invention of the CRQC, to minimize the likelihood of a CRQ= C operator abusing this protocol, but=20
> also recent enough to give time after the publication of this stan= dard for coinholders to produce their=20
> PACTs so that this protocol can be used effectively. The standard = for `X` can be updated for new deposits=20
> 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 s= pent according to the following=20
condition:

1) After a relative timelock of 1 block, anyone can spend up to 1% of t= he value of the UTXO, or=20
100,000 sats, whichever is greater, and MUST send the change (if any) t= o the Recirculation address.

# Out of scope

The following considerations are explicitly out of scope:

- **Enabling recovery of coins whose private keys were not generated us= ing a BIP-32 seed or secured with=20
a PACT.** This is not for a lack of interest; if anyone has any ideas f= or how to do this, the author is=20
open to suggestions!
=20
- **Changing consensus to disable the spending of coins that are held i= n addresses derived from "weak"=20
private keys.** This proposal is intentionally designed as an applicati= on-layer standard, because using=20
consensus to intentionally impair the ability to spend specific coins r= uns contrary to bitcoin's utility=20
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 p= rovide some way for the coins=20
to re-enter circulation, akin to future generations finding buried trea= sure, providing more certainty=20
over the eventual disposition of the coins. As an alternative, coins tr= ansferred to the Recovery address=20
could instead remain there for an indefinite amount of time until they = are spent using a zkPKS. This would=20
not provide the same level of certainty as the current proposal, but wo= uld substantially reduce the=20
proposal's argument surface. Whether or not inclusion of the Recirc= ulation address is preferable to the=20
bitcoin standards community, and therefore whether or not it makes it i= nto the finalized proposal, is open=20
to discussion. The author is also open the possibility of two standards= existing: a "v1" with the Recirculation=20
address, and a "v2" without the Recirculation address. Finder= s could then choose which standard to follow=20
based on their own preference.

# Dependencies

The Bitcoin Lost and Found depends upon support for verifying a (post-q= uantum) zkPKS in Script, along=20
with a recursive covenant that enforces change destinations in perpetui= ty, ideally using standard bitcoin=20
transactions.[8] These capabilities do not yet exist in bitcoin, but co= uld be added with a soft fork that includes=20
OP_CAT and OP_MUL e.g. BIP-441 and a recursive covenant opcode such as = OP_TX, or opcodes with equivalent=20
capabilities.[9][10][11] Alternatively, we could use a soft fork to add= a new smart contract language to bitcoin that=20
has these capabilities, such as Basic Bitcoin Lisp or Simplicity.[12][1= 3]

# Prior art

This idea for the Recovery address was inspired by a conversation betwe= en the author, Matt Corallo, and=20
Ethan Heilman about the author's proposal that anyone who uses a cr= yptographically-relevant quantum=20
computer to crack bitcoin private keys should burn the coins using `OP_= RETURN`.[14] In response to this=20
proposal, Matt suggested that rather than burn the coins, they could be= sent to a recovery address that=20
requires a PQ zkPKS to spend from the address. This document is an elab= oration of this suggestion into a=20
full protocol.

Related prior art on the general topic of using zero-knowledge proofs f= or the recovery of quantum-vulnerable=20
coins can be found here: https://gist.= github.com/Roasbeef/563f173fe44e2005e003a082716e586f#zk-proofs-for-migratio= n-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.in= fo/disclosure.html
[3] https://bitcoinmagazine.com/technical/critical-v= ulnerability-found-in-android-wallets-1376273924
[4] https://githu= b.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-qu= antum-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/mas= ter/bip-0441.mediawiki
[11] https://github.com/ru= styrussell/bips/blob/68125328504930d8f5efdd594f600749ce75f130/bip-unknown-o= ptx.mediawiki
[12] https://bitcoinops.org/en/topics/basic-bit= coin-lisp-language/
[13] https://bitcoinops.org/en/topics/simplicity/
[14] https://x.com/lightcoin/status/1892987447471911005
[15] http= s://github.com/cryptoquick/bips/blob/hourglass-v2/bip-hourglass-v2.mediawik= i

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/d0fb6249-d436-48c2-9dc1-0ed6fa25c988n%40googlegroups.com.
------=_Part_3819_428027287.1777987383677-- ------=_Part_3818_1512059388.1777987383677--