From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 05 May 2026 05:00:32 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wKERz-0001r0-C4 for bitcoindev@gnusha.org; Tue, 05 May 2026 05:00:32 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-43013bffd49sf12674198fac.0 for ; Tue, 05 May 2026 05:00:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1777982425; cv=pass; d=google.com; s=arc-20240605; b=XPVLiu1IxeFOZBhoRTM3ehqqeyQIRg8A7hZ/ejmd6tsy45QHEEizZWC9SRzNywcPuZ 7MnumqG72Hyz85VPL76rPPHSh+r5+CFGsQsGZT7K9jnlWVxwvPNSsgCogGtNPBB7jfFJ 6e6Ok19UW4M7eoagHhSMA+yosrPONYMbSbF876COyNsryi0SuYmFB1ZiMDaVds2OB7tv p7PBy/UthDeRG0LLfgEwDotQxJMrpDW332q7hljZzNWxckdtyNWHflAGBIGXApqeWA7M Ee4cHykeU90QqDzMSmam3QPb1fJoITN0IzsgPwrNimp5ap8PZ2MS4fSUrUm1v+5RrWS+ equA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:subject:message-id:to:from:date :mime-version:feedback-id:sender:dkim-signature; bh=BfDvVGXGh5sXjc/vHtRaOiQN6ZuXDcGtS2ml9lCPMSU=; fh=/OIs+CFWUwH17nTaDIaHOgFBI7v/7pwJ/BmxYl/DgvA=; b=YqDfLLmpBUeuWel35QsnG3ZZMFsuUtF7BXM8OyFmU4eNoamGJZ3+iHx6g9QRKLtQB6 gVMmcNmYsSzzJBaEiTZsubwcLWXNH0EasfEe7a4/XcovGYtMUOSTCifsuD08G4T2fPay xRQAY22XrFw0k7ZeDQYCBnN28zprWbPbqms6zTZH6j3xndOSYpXjWBAwcX3558rFZ35s WHsrdQKxLvBB+VuwIqjUUYBsfNu/MP1MjCLkoxaB4oEEMmBFlSjw8KchVfeBFDBeFYt1 TfSB/tvS41i3U1H04kHRBOTzSjX0AR4+es7pgUhtDI15XerpAMGe2PnnGrUFHOU8x473 CeSg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=cA6e3sz4; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=drDtNEjj; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.149 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777982425; x=1778587225; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:subject:message-id:to:from:date:mime-version :feedback-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=BfDvVGXGh5sXjc/vHtRaOiQN6ZuXDcGtS2ml9lCPMSU=; b=II5Kx+nYUNzNQpKbo/3w0nfMmIVK6ZOhGJKlVl0wAYiKBb03G+T8Z6VmiLVcBVQhOz DAIFTLw9NAo7v+pw3MsymF8Mp63SERP7mRgbHy8KPhXhSLPNHzEdhyJWEf2KrVjTgN8D BWNP6SDyGNKPfh1t1mWqo2Y2ClAu+cTDC/vtdt7qZOS9nylp5dJA6b2fGT96eTd6jBqO FlRB95LzL5/Rnmv6jkvsbrhsTVDtfRDecdgrZK2LZsHGUcPzvm1cUl83wiT1z9H1JnZ/ BWEwDPuTgytLyt8l1a4xXXDTm8iIayefzAhD+1/xNvlJyjaRLUa9ycYXpD2uUvHCdeYs FhBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777982425; x=1778587225; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:subject:message-id:to:from:date:mime-version :feedback-id:x-beenthere:x-gm-message-state:sender:from:to:cc :subject:date:message-id:reply-to; bh=BfDvVGXGh5sXjc/vHtRaOiQN6ZuXDcGtS2ml9lCPMSU=; b=fH1qMDWmw6iyVGd6CypLPsQxaT4lpSILsIVRHhCeK74SXxnVg98a1WZdnJENy4Bg9r NQUPw6SymeOEMjfYzZ97nS/ix6uziitEnLAbFkFXThIKG904/pGbPog52ZRKbwH30kIk z41FHynuZFSJK+V3Lh/pJyKkewNcMXBkxipahsEC+gfIb1rBrcTnJTAab50HijWVakaL aU5CpqWz3V9b2I7RKXsVbB7DEMGrP8MkokvLHAvz89bRsHk6g6KMx0PJZca8SnmMlWsL N2Py5ggJKnfgjfEDadyfp6Gkq8QxuCIHbfCAIrxF8sVUss4q08hfl5E8tEOksteM/q9p 7l8Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ+r4MTrD2HCH2A2H77spbkeY20LyHhNCoSOVV43+5EfKeeKq9+dS/XdhGiwxqstDJwxWpKiMoa6y6PQ@gnusha.org X-Gm-Message-State: AOJu0YxtKHIGV+QHFWMhdl/U8wuJTg6CmHJMHqoIvvabxkgBCImsW0qC o8n52UkI0DbslYWJwnI03yoh/5w/5SSHMMr4n73rW84uW4WO0p0mkfhV X-Received: by 2002:a05:6871:721:b0:430:3591:26c6 with SMTP id 586e51a60fabf-434d0bc9423mr1586182fac.4.1777982425053; Tue, 05 May 2026 05:00:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMP0oiKzdTIpfP9ALpDItaPsQMaWMzm/ep/+QOX/U2lwYQ==" Received: by 2002:a05:6870:fba4:b0:42c:d01:d9e1 with SMTP id 586e51a60fabf-4340adcc2e1ls1834946fac.0.-pod-prod-00-us-canary; Tue, 05 May 2026 05:00:19 -0700 (PDT) X-Received: by 2002:a05:6808:11c1:b0:479:d372:b7d0 with SMTP id 5614622812f47-47d25f3094dmr1585049b6e.5.1777982419450; Tue, 05 May 2026 05:00:19 -0700 (PDT) Received: by 2002:a05:6808:32ca:b0:47c:339e:add7 with SMTP id 5614622812f47-47c88e7fea0msb6e; Tue, 5 May 2026 04:38:47 -0700 (PDT) X-Received: by 2002:a05:6808:23d3:b0:47b:d07b:ec9a with SMTP id 5614622812f47-47d2ba46e1emr1590151b6e.15.1777981126787; Tue, 05 May 2026 04:38:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777981126; cv=none; d=google.com; s=arc-20240605; b=h3jfnig2M5PtiqsWKJb5VQeqpvbYq3InqLhu9f1gBcdDZzSW4Ew2n3Ds78w608XuLC 5CDb6WWF4qE1NDNN0e6Qtt3IGz+03SG6bx+FxRwkypgAwIIlo9ZobIKDu7vkbEXpNGXJ kvY+IVyUg6/QqTm/bwschPcBZWh4MkZpCGjDHZ+uBCI7WxpD/RGr227Imjr9JSoENU6W pK2ScLXe0MW+MVyiFbGsumVHVRkc7OXIoI9aTZrZAIEUC9WZMQNUeyGF73d/BrDA+SK4 yzNCKTBS7+Vw2+IWEjG1VrEltetARviUuZlAEPLeOOHIbyyhtqwMy7fyILcKtvAn+BIn vzxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:subject:message-id:to:from:date :mime-version:feedback-id:dkim-signature:dkim-signature; bh=FGtTNRZYcdPQjZYNq92uuPcmPqUQeXIrZCsKJObguiE=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=VgoemJlGDxEoFYDZ3VcQsvNdxL5J7IgMJOWARNZVYArhVSonsNslPxxzI+zpqNJGrP ANfmK7ExZm1UW9d4k24pbMsy4q2JfjFz/z76vbpShd4lbvuPQf7PXWtwyyynGW+HUC25 HmTIoOxAeKjumoWtSHdK6Z1W+iC0ZwYlejLo/whYWhRalS7uNCd84j1ovvykoxSAsBUn s/Fd08dK3WYr2CT8nEbCnDwIidYWkkryQGoga0CJ8l33QjFUMRPWDxGMNIqwkSWZM4Pd lYIlfAgyVpJbII5LnyKtL/rfaEcpQrLyH/udG/E3H+uFDrEwQB28twxwrvyRy6U9PKv3 VNVg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=cA6e3sz4; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=drDtNEjj; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.149 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in Received: from fout-a6-smtp.messagingengine.com (fout-a6-smtp.messagingengine.com. [103.168.172.149]) by gmr-mx.google.com with ESMTPS id 5614622812f47-47c7699824dsi379246b6e.5.2026.05.05.04.38.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 04:38:46 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.149 as permitted sender) client-ip=103.168.172.149; Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 25DB2EC0072 for ; Tue, 5 May 2026 07:38:46 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-04.internal (MEProxy); Tue, 05 May 2026 07:38:46 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddutdduieduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmnegfrh hlucfvnfffucdluddumdenucfjughrpefoggffhffvkffutgfgsehtjeertdertddtnecu hfhrohhmpefnihhghhhtuceosghithgtohhinhdquggvvheslhhighhhthgtohdrihhnqe enucggtffrrghtthgvrhhnpefhheeuieethffhteehueevkefhudfhgeefgeffhfdvtdeu keeiheffkeffffevteenucffohhmrghinhepghhoohhglhgvrdgtohhmpdhgihhthhhusg drtghomhdplhhighhhthgtohdrihhnpdhunhhmrdgvughupdhmihhlkhhsrggurdhinhhf ohdpsghithgtohhinhhmrghgrgiiihhnvgdrtghomhdpohhurhifohhrlhguihhnuggrth grrdhorhhgpdhprghrrgguihhgmhdrgiihiidpsghithgtohhinhdrohhrghdpgidrtgho mhdpsghithgtohhinhhophhsrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghithgtohhinhdquggvvheslhhighhhthgtohdrihhn pdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsih httghoihhnuggvvhesghhoohhglhgvghhrohhuphhsrdgtohhm X-ME-Proxy: Feedback-ID: ic4c14615:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 00F6B780070; Tue, 5 May 2026 07:38:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Tue, 05 May 2026 07:38:45 -0400 From: Light To: bitcoindev@googlegroups.com Message-Id: Subject: [bitcoindev] The Bitcoin Lost and Found Content-Type: text/plain; charset="UTF-8" X-Original-Sender: bitcoin-dev@lightco.in X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=cA6e3sz4; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=drDtNEjj; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.149 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in 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.8 (/) 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.