From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 04 Nov 2026 13:14:09 -0800 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xOiJ6-0008A5-HG for bitcoindev@gnusha.org; Wed, 04 Nov 2026 13:14:09 -0800 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-46dade0d7cdsf1238708fac.1 for ; Wed, 04 Nov 2026 13:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1793826842; x=1794431642; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=OPq/eLY160KSJqJrf9N79lz9iRaIBKBG5i8GEY22VQI=; b=E8yaO/Xor7cNTo6mCzqBLKLkIC/B2cA1kfEhT+RS1hp1fxo91ifbh9NQSFIb3NnLlY W0vDoKS745DULP52p1IdgbAcbRyDKg0fzlkKd1kwRn6a+F13/Y9S1WlDnVVmng3nmK1X k+DGjtjiRBo5NBmNH17Ls3KMwe7htFfyqirKbNz1DmQUjeYe/g0Adhltqr7vAdmj9O0S ffKTkqRP98uzKGJupxHym90/129ucucet6heD6U24TSLG73+KSRyfSnBEup1vmxvsQxc t9RYNlGE7CkRtHXH8/EsWIJ41+WaiukzFeTEtSOV+GM0/b8rFhRjErI42FVMe76BFAlv FSMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coryfields.com; s=google; t=1793826842; x=1794431642; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=OPq/eLY160KSJqJrf9N79lz9iRaIBKBG5i8GEY22VQI=; b=Gc4vps3wPiIskqlSm1pE1V872sy0oEhGUxofhAJTJkOkPp4GVkLERYTLxYCbkbCh3d GBNArOcHUNT7LNLSEsyM0wMTJoPC6mwn55UXa7bSS6G3ASgiLJgfNa51ZH4o96ZNEwkN 7tY8XXxh8WJvp/QDLxwD2CGQMlRijHrinmey0p+Xw/qIEcNeu6G9mXjgr48e0xAYWL7a WaBaB76l/aLM+CwR6q9m0GfSPKQX1+VCguB4U1KM0Lc/nJPbPsFfwxsdO9KX9oR/Y+1t vq1Jz1itN3O2BGRRsEfM7InFAm1wcnyK9YGgugDkeQ33JiWoaqd0iCviTR0BgZ9aZX2t C2Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793826842; x=1794431642; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=OPq/eLY160KSJqJrf9N79lz9iRaIBKBG5i8GEY22VQI=; b=KN0Xu46mHzleMhRvCyZBdYKYByLTfX3jloUlaxs+S/Cm4SevLXKdVMLkQ/1FtjiqZF 9IxPyhGqZmMTvs5YgoZ6ppJA9WBWuKMYVznLhjpsRqhVxzvTYxAZi6NQfwVMHlYpDGCE YJcd9iSzXJfD5CcTJ0gnrTmiqyKsYLZ2+q30kMOhZYjUPTN9omNhJK3tQIMBiIAmx1CK 2pSeV0vMMtV+vEJUqHIOEne2HDngyJVCoqC7FJk95JnDM5qQPsJVSrTC1/bhKJnOC5Vs ALVpNnQmqklE9m7Xnd7s7KePy2b25BBtohXqxbRuwykux3gd6en689oj1XzGonEK4Psz YvoQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBywyujRvNWrxxKUGZzKpNJ3pBZJCwozBQ7yLCPElGNLMNyvw5FAJZ5cD2pyNHX6fpC6XuV1HHkfige8@gnusha.org X-Gm-Message-State: APuU4Z845EX/eNGg1y0h5uTjBgPj4yBTPaXHamAto+TS1ehSWJ/iF6m5 9bUfpRuRrJchI/Bt8hB7ZhWro8tRM1pxmN3sQhMRTtyKqRirwFsd/p9X X-Received: by 2002:a05:6870:c0d0:b0:4a7:2473:8688 with SMTP id 586e51a60fabf-4a90729b0dbmr11750191fac.5.1793826842135; Wed, 04 Nov 2026 13:14:02 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfzq5SJdljnmCu1nj3DYCpbMLsGtVuec4CY7kbhpIPkUg==" Received: by 2002:a05:6871:2902:10b0:492:46f8:3965 with SMTP id 586e51a60fabf-4ac01dbe319ls1025543fac.0.-pod-prod-09-us; Wed, 04 Nov 2026 13:13:55 -0800 (PST) X-Received: by 2002:a05:6808:3195:b0:4d5:295c:a831 with SMTP id 5614622812f47-5640df3de19mr11772914b6e.62.1793826835858; Wed, 04 Nov 2026 13:13:55 -0800 (PST) Received: by 2002:a05:690c:e016:20b0:8b2:da26:98d2 with SMTP id 00721157ae682-8b30f955d53ms7b3; Wed, 4 Nov 2026 13:05:21 -0800 (PST) X-Received: by 2002:a05:690c:8d09:b0:8b1:567c:e7c2 with SMTP id 00721157ae682-8b2b66ed2dfmr83851817b3.23.1793826321206; Wed, 04 Nov 2026 13:05:21 -0800 (PST) Date: Wed, 4 Nov 2026 13:05:20 -0800 (PST) From: Cory Fields To: Bitcoin Development Mailing List Message-Id: <40a9f73d-481f-47e6-a64b-acfb2c7f4fa8n@googlegroups.com> Subject: [bitcoindev] Quantum Landmines and Vulnerable Coin Auctions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_137547_324661672.1793826320784" X-Original-Sender: foss@coryfields.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.7 (/) ------=_Part_137547_324661672.1793826320784 Content-Type: multipart/alternative; boundary="----=_Part_137548_334992772.1793826320784" ------=_Part_137548_334992772.1793826320784 Content-Type: text/plain; charset="UTF-8" I've had fun discussing these rough ideas regarding post-quantum migration to a few people in the last week. Rather than describing mechanics of how to do any of the below via soft fork, which I do believe to be possible, I'm leaving those details to a future exercise. The purpose of this post is just to introduce the ideas as thought experiments. For the below, I'm assuming a future where: - We have a new quantum-safe output type pre-qday - Some new validation rules are activated post-qday (Something like Tripwire and/or manually) - Post qday, all legacy output spends must be fully collateralized in order to be spent (more on this later) - Post qday, all legacy output spends must be have outputs that meet certain conditions (time-locks and alternate spend paths) Note that the last two requirements are similar to vault/covenant constructions, but in this case their behavior could be enforced implicitly by soft-fork rules. ## Quantum Landmines This is a commit/reveal scheme, similar to those which have been discussed here, but with the addition of a payout in the case of proven theft. Alice has 3 unspent outputs: 1btc in a legacy output type, 1btc in a quantum-safe output, and a trivial amount of btc in another quantum-safe output (the landmine). Let's say that her legacy output is p2pk, though any legacy output type would work. Pre-qday, when Alice funded her trivial quantum-safe output, she also embedded within it a proof-of-knowledge. For the sake of example, imagine this is a taproot-like tree. So in addition to its script-spend-path, it also contains a leaf which commits to a new quantum-safe pubkey and is signed by her legacy p2pk private key. The existence of this leaf is never revealed unless/until it is used as a proof. Post-qday, in order to spend her legacy p2pk coin, recall that the new rules require that it must be fully collateralized. So she creates a transaction consisting of both of her 1btc inputs and a 2btc quantum-safe output. The output has the following implicit spending conditions: - If re-spent within (say) 30 days, a proof of pre-qday knowledge of the private key is sufficient to spend - If a proof is provided, the output's pubkey must be the same as the one signed for in the above proof - If re-spent after the time-out, no proof is required and it can be spent as usual. To see why this is useful, let's now consider the same scenario, except that a quantum attacker is attempting to steal her p2pk coin after finding her private key. The attacker creates a transaction consisting of their own quantum-safe 1btc coin (for collateral) as well as Alice's vulnerable 1btc as inputs, and a 2btc output with the same required spending conditions described above. Because they have no pre-qday proof-of-knowledge of Alice's key, the attacker would have to wait the 30 days before they can re-spend the output. However, Alice notices the transaction in the meantime and spends the in-limbo output to her committed-to key by including her landmine as an input and revealing the proof. In doing so, she moves her own coins while also taking the attacker's collateral. Unbeknownst to the attacker, Alice's trivial output, which looked just like any other quantum-safe output, actually contained a landmine. This scheme is especially interesting because it actually incentivizes Alice to bait a quantum attacker pre-qday in order to double her vulnerable coins later, and thus makes quantum attackers wary of stealing coins as they may be secretly guarded by mines. It also muddies the waters so that on qday, it's not possible to analyze how many coins are vulnerable to theft. ## Staked Auction The obvious problem with relying on landmines alone is that the associated private keys for many vulnerable outputs are believed to be lost, thus a quantum attacker could reasonably assume that they are not guarded by landmines. But what if we could devise a similar collateral/commit/reveal scheme to empower users who stake their coins pre-qday in order to thwart a quantum attacker post-qday and take their collateral? Let's add a new required spending condition, so there are now 3 ways to spend a legacy output: - If re-spent before the initial landmine timeout, a proof of pre-qday knowledge of the private key is sufficient to spend - If re-spent after the landmine timeout but before the auction timeout, a bid is sufficient to spend - If re-spent after the auction time-out, no proof is required and it can be spent as usual. Bob suspects that an old legacy unspent output of 50btc has no associated landmine and thus a quantum attacker will try to steal it in the future. Pre-qday, He creates a quantum-safe output of 50btc with a secret leaf, but in this case it commits to a the vulnerable output, a bid amount of 40btc, and a new pubkey. This unspent transaction represents a staked bid of 40btc in the event that a particular vulnerable output is ever spent. In order to keep bidding sane, the allowed depth of bid-leaves could be constrained. Post-qday, a quantum attacker finds the private key associated with the vulnerable 50btc unspent output and spends it, along with the required 50btc of their own as collateral, to an output which has the above spending conditions and is worth 95btc. This represents a bid of 45btc. Because no landmine exists, the initial timeout comes and goes. Now an auction begins and continues until a second time-out. During this auction period, Bob reveals his staked 50btc output with a 40btc bid, and uses it to take 40btc of the attacker's collateral. The original stolen coins are lost, the attacker loses some or all of their collateral, and the auction continues. If nobody outbids him, Bob takes the 40btc as profit. Carol sees Bob's winning bid and repeats the same process, using her staked 50btc to reveal her secret bid of 30btc. The auction continues, but nobody outbids her and the auction times out. She can now claim the 30 coins as profit. The staking requirement limits how many vulnerable coins a future quantum attacker can bid on before qday. There are many ways this could be designed. Bob could get his coins back so that a bid carries no risk, or be slashed for a losing bid. Unused collateral could be burned, or given to Carol, or given to miners, or thrown into a pot for later use. Staking requirements could be 1:1 or x:y. Staked time (coin age) could be taken into consideration. Etc. Notice that in this design, as long as there is a landmine or a staked lower bid on the vulnerable coins, they are never successfully stolen by the quantum attacker. The vulnerable coins are burned, and it's the attacker's collateral that is claimed by the auction winner. The attacker only ever makes away with the stolen coins if no one outbids them. Thus they're incentivized to make a very conservative bid. ## Sats Auction When describing the above auction scheme to Neha Narula, she suggested that the well-understood Dollar Auction game [0] could be used as well. See the link for more details and intuition, but I'll summarize briefly how it could be used here. In this case, there's no need for pre-qday staking. The spending/timeout mechanics are similar to a Staked Auction. Every spend of legacy coins triggers an auction after the landmine timeout. The highest bid wins the coins minus the bid, and the second-highest bid loses its bid and collects nothing. The auction continues until there are no more bids. Participants may keep bidding more in order to prevent themselves from ending up as the second-highest bid and thus having to pay. As a result, it's possible that a quantum attacker trying to spend a vulnerable 50btc output ends up losing all their collateral. Bidders could even attach additional inputs to keep the auction going beyond the value of the vulnerable output. This is interesting because, as the Wikipedia article mentions, the logical conclusion is for the attacker not to play. Also, because there is no pre-qday commitment requirement, the original coin owner (outwardly indistinguishable from an attacker) would actually have a chance at partial recovery if they chose to start the auction themselves. Similar to auction A, there are lots of knobs and levers here: - Collateral ratio - Min/Max bids and intervals - Where do the loser's coins go? ## Desired Auction Outcome Having thought about these for a week or so, it's clear that there are lots of interesting ways to dissuade a quantum attack via a vulnerable coin auction using incentives and game theory. However, it's unclear what the best design would be because it's not even clear to me what the most desirable outcome would be. - Attempt to prevent a quantum attacker from ever attempting to steal in the first place? - Attempt to encourage staking via auctions, with quantum attackers sometimes winning to encourage the process? - Attempt to redistribute the coins as randomly as possible? If so, an auction could be designed to work more like a lottery, where every unspent output is a lottery ticket or authorization to bid. To complicate things even further, the most desirable outcome may even change as time goes on after qday, as the vulnerable coin spender is increasingly likely to be an attacker as opposed to the original owner. [0]: https://en.wikipedia.org/wiki/Dollar_auction -- 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/40a9f73d-481f-47e6-a64b-acfb2c7f4fa8n%40googlegroups.com. ------=_Part_137548_334992772.1793826320784 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've had fun discussing these rough ideas regarding post-quantum migration = to a few people in the last week. Rather than describing mechanics of how t= o do any of the below via soft fork, which I do believe to be possible, I'm= leaving those details to a future exercise. The purpose of this post is ju= st to introduce the ideas as thought experiments.

For the below,= I'm assuming a future where:
- We have a new quantum-safe output type= pre-qday
- Some new validation rules are activated post-qday (Somethi= ng like Tripwire and/or manually)
- Post qday, all legacy output spend= s must be fully collateralized in order to be spent (more on this later)- Post qday, all legacy output spends must be have outputs that meet cer= tain conditions (time-locks and alternate spend paths)

Note that= the last two requirements are similar to vault/covenant constructions, but= in this case their behavior could be enforced implicitly by soft-fork rule= s.

## Quantum Landmines

This is a commit/reveal schem= e, similar to those which have been discussed here, but with the addition o= f a payout in the case of proven theft.

Alice has 3 unspent outp= uts: 1btc in a legacy output type, 1btc in a quantum-safe output, and a tri= vial amount of btc in another quantum-safe output (the landmine). Let's say= that her legacy output is p2pk, though any legacy output type would work.<= br />
Pre-qday, when Alice funded her trivial quantum-safe output, she= also embedded within it a proof-of-knowledge. For the sake of example, ima= gine this is a taproot-like tree. So in addition to its script-spend-path, = it also contains a leaf which commits to a new quantum-safe pubkey and is s= igned by her legacy p2pk private key. The existence of this leaf is never r= evealed unless/until it is used as a proof.

Post-qday, in order = to spend her legacy p2pk coin, recall that the new rules require that it mu= st be fully collateralized. So she creates a transaction consisting of both= of her 1btc inputs and a 2btc quantum-safe output. The output has the foll= owing implicit spending conditions:
- If re-spent within (say) 30 days= , a proof of pre-qday knowledge of the private key is sufficient to spend- If a proof is provided, the output's pubkey must be the same as the o= ne signed for in the above proof
- If re-spent after the time-out, no = proof is required and it can be spent as usual.

To see why this = is useful, let's now consider the same scenario, except that a quantum atta= cker is attempting to steal her p2pk coin after finding her private key.
The attacker creates a transaction consisting of their own quantum= -safe 1btc coin (for collateral) as well as Alice's vulnerable 1btc as inpu= ts, and a 2btc output with the same required spending conditions described = above. Because they have no pre-qday proof-of-knowledge of Alice's key, the= attacker would have to wait the 30 days before they can re-spend the outpu= t. However, Alice notices the transaction in the meantime and spends the in= -limbo output to her committed-to key by including her landmine as an input= and revealing the proof. In doing so, she moves her own coins while also t= aking the attacker's collateral.

Unbeknownst to the attacker, Al= ice's trivial output, which looked just like any other quantum-safe output,= actually contained a landmine.

This scheme is especially intere= sting because it actually incentivizes Alice to bait a quantum attacker pre= -qday in order to double her vulnerable coins later, and thus makes quantum= attackers wary of stealing coins as they may be secretly guarded by mines.= It also muddies the waters so that on qday, it's not possible to analyze h= ow many coins are vulnerable to theft.

## Staked Auction
The obvious problem with relying on landmines alone is that the associa= ted private keys for many vulnerable outputs are believed to be lost, thus = a quantum attacker could reasonably assume that they are not guarded by lan= dmines.

But what if we could devise a similar collateral/commit/= reveal scheme to empower users who stake their coins pre-qday in order to t= hwart a quantum attacker post-qday and take their collateral?

Le= t's add a new required spending condition, so there are now 3 ways to spend= a legacy output:
- If re-spent before the initial landmine timeout, a= proof of pre-qday knowledge of the private key is sufficient to spend
- If re-spent after the landmine timeout but before the auction timeout, a= bid is sufficient to spend
- If re-spent after the auction time-out, = no proof is required and it can be spent as usual.

Bob suspects = that an old legacy unspent output of 50btc has no associated landmine and t= hus a quantum attacker will try to steal it in the future.

Pre-q= day, He creates a quantum-safe output of 50btc with a secret leaf, but in t= his case it commits to a the vulnerable output, a bid amount of 40btc, and = a new pubkey. This unspent transaction represents a staked bid of 40btc in = the event that a particular vulnerable output is ever spent. In order to ke= ep bidding sane, the allowed depth of bid-leaves could be constrained.

Post-qday, a quantum attacker finds the private key associated with = the vulnerable 50btc unspent output and spends it, along with the required = 50btc of their own as collateral, to an output which has the above spending= conditions and is worth 95btc. This represents a bid of 45btc.

= Because no landmine exists, the initial timeout comes and goes. Now an auct= ion begins and continues until a second time-out. During this auction perio= d, Bob reveals his staked 50btc output with a 40btc bid, and uses it to tak= e 40btc of the attacker's collateral. The original stolen coins are lost, t= he attacker loses some or all of their collateral, and the auction continue= s. If nobody outbids him, Bob takes the 40btc as profit.

Carol s= ees Bob's winning bid and repeats the same process, using her staked 50btc = to reveal her secret bid of 30btc. The auction continues, but nobody outbid= s her and the auction times out. She can now claim the 30 coins as profit.<= br />
The staking requirement limits how many vulnerable coins a futur= e quantum attacker can bid on before qday.

There are many ways = this could be designed. Bob could get his coins back so that a bid carries = no risk, or be slashed for a losing bid. Unused collateral could be burned,= or given to Carol, or given to miners, or thrown into a pot for later use.= Staking requirements could be 1:1 or x:y. Staked time (coin age) could be = taken into consideration. Etc.

Notice that in this design, as lo= ng as there is a landmine or a staked lower bid on the vulnerable coins, th= ey are never successfully stolen by the quantum attacker. The vulnerable co= ins are burned, and it's the attacker's collateral that is claimed by the a= uction winner. The attacker only ever makes away with the stolen coins if n= o one outbids them. Thus they're incentivized to make a very conservative b= id.

## Sats Auction

When describing the above auction= scheme to Neha Narula, she suggested that the well-understood Dollar Aucti= on game [0] could be used as well. See the link for more details and intuit= ion, but I'll summarize briefly how it could be used here.

In th= is case, there's no need for pre-qday staking. The spending/timeout mechani= cs are similar to a Staked Auction.

Every spend of legacy coins = triggers an auction after the landmine timeout. The highest bid wins the co= ins minus the bid, and the second-highest bid loses its bid and collects no= thing. The auction continues until there are no more bids. Participants may= keep bidding more in order to prevent themselves from ending up as the sec= ond-highest bid and thus having to pay. As a result, it's possible that a q= uantum attacker trying to spend a vulnerable 50btc output ends up losing al= l their collateral. Bidders could even attach additional inputs to keep the= auction going beyond the value of the vulnerable output.

This i= s interesting because, as the Wikipedia article mentions, the logical concl= usion is for the attacker not to play. Also, because there is no pre-qday c= ommitment requirement, the original coin owner (outwardly indistinguishable= from an attacker) would actually have a chance at partial recovery if they= chose to start the auction themselves.

Similar to auction A, th= ere are lots of knobs and levers here:
- Collateral ratio
- Min/M= ax bids and intervals
- Where do the loser's coins go?

## D= esired Auction Outcome

Having thought about these for a week or = so, it's clear that there are lots of interesting ways to dissuade a quantu= m attack via a vulnerable coin auction using incentives and game theory. Ho= wever, it's unclear what the best design would be because it's not even cle= ar to me what the most desirable outcome would be.

- Attempt to = prevent a quantum attacker from ever attempting to steal in the first place= ?
- Attempt to encourage staking via auctions, with quantum attackers = sometimes winning to encourage the process?
- Attempt to redistribute = the coins as randomly as possible? If so, an auction could be designed to w= ork more like a lottery, where every unspent output is a lottery ticket or = authorization to bid.

To complicate things even further, the mos= t desirable outcome may even change as time goes on after qday, as the vuln= erable coin spender is increasingly likely to be an attacker as opposed to = the original owner.

[0]: https://en.wikipedia.org/wiki/Dollar_au= ction

--
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/40a9f73d-481f-47e6-a64b-acfb2c7f4fa8n%40googlegroups.com.
------=_Part_137548_334992772.1793826320784-- ------=_Part_137547_324661672.1793826320784--