From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Feb 2026 08:21:35 -0800 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqvvC-00080E-MF for bitcoindev@gnusha.org; Fri, 13 Feb 2026 08:21:35 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-4081db82094sf9378221fac.0 for ; Fri, 13 Feb 2026 08:21:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770999689; cv=pass; d=google.com; s=arc-20240605; b=ZEaH+Dzh3rWbYGY+/HPrXutcl6nk9ZiKtfCXiSV2G5VzCAmdyehc5EPzYNsFiqE83Q YVJA1Yd9ml5qAxOGCvQ+PG0bNB9aw4axE9MZ+6m+m65ZRsvYCOqN64gvcQTv95x+fNaZ PyJZfTKVjrmtHWaMxqxIlC8YPcq3NaB+3HGaVS34cgKgGLVdEJynRVFEY7aRLoIgSAN0 bR8wmDd9xqd78mdpnmFI73HImKBh+zkNfyC6blukye3EVKGAWUp/JVhKhG5Lh+PD5rUr lNM/WaypNz3h92SrL/+g5UCxJXagtctNFIv+we80zAcl9I+CuiB8QfCqDf0f+RAzeY1b ZL6A== 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:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=OvIy40SVCRdoU4mGRACcGQDBj+4LgD2Yyp/D1B8zPT8=; fh=uOLjlSLRb5VTcORbBomkBMoVvZRf1ML2a+VtJdV7Hsk=; b=XCPXd0y1DVZ7tZZxaXujwl+VwEUXqo59nvyHtAe4hUznvlv6wQJ4hXshP24W+9UyNs EGMsob+16bPiKKrbI16YT7dF8LQ9KJ7IHLBAGNriqN8EQmBL99lRmQBqi54XCGvAIVts a9s5FArKeTxZpuHqShWwiSmZyHuBN8pvc2t/zwIb5Pl1UXiyNELxYkEFl5W7ZwpBhLo4 kdrFoJJ2wpYnLClYMG2ef9ARtdWSASyZsybW5jO2Stj6qVfK/FRpk9fhDIKyWgg7uQNn EMqM7RbFLBiEXTm8UwFK43xDbXuceVxmixSO7Z0zgvHV9S90HdCpiNshMX4451J6ICuu YdiA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1770922862 header.b=G5bpTWnF; dkim=pass header.i=@clients.mail.as397444.net header.s=1770922864 header.b=HJQ2Xx2F; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770999689; x=1771604489; 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:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=OvIy40SVCRdoU4mGRACcGQDBj+4LgD2Yyp/D1B8zPT8=; b=bpZJs7m1dD5SlG1/K8fg/RViiYenAn/UmpA2+9kox7YCs2uDKfpJW5Yc35Jl2pEJTG SJlWpQhTcnpim8IsBc76RT3/lyDbgtDLK6Y7VNLQAJoR2n3va5jQ6zFoHMhDxfB1PBIV ie9GVcgAb9+2N2l2u5wxSIXlINYlJywhJ8qc6mWY4NkGQ/L1P8BZCnD1Ai+zWHQaQFAf XAlp61rvvKaizwFgFDDci0WoXvwrHNCCbHUrusoHh10lUm6mR2u+KWcHTfvO4Jc2bl28 OEgI71E/gEU12t+NoDjuUkuFUmpXbbUH5X5OgkqX8PLCfZcuCnS1DOa4Dm3a1+uyfKBA X28A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770999689; x=1771604489; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:from:content-language:references:to :subject:mime-version:date:message-id:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=OvIy40SVCRdoU4mGRACcGQDBj+4LgD2Yyp/D1B8zPT8=; b=wkoHvntSe48U8UBX/tzkceqROsP63YJ8Ye4ZX/Mo4fTyYzDIFuWshgqE3GbV/D+roh /0Vszl3z+RISGWluk9TdeIoc2cA22KsN/TIO/7QnBSSjzVLro5OZNO4k4BDiyZiD0Em/ RUaRj7rP52hnfLIZH8YNj5r6CDx5BlF/fC86Sz7t2lwmDQlKCbGLCmZTQF5eOYF05oar ZrwaWZQL1ju41S6sCEI5Eg6ivVW9xcOIi/t/xh7C3CUAvlqndVTMkPgGjRQbh++J4Whb MzARD9f4OF7hjfsBDykfScax5wOLalWDym96szeYShl0rwVQdVIRfYInB5onQUjl5Jfb F5UA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVZVMhWbFBODVgcDiXmBg97Kvl+z1/9XCifNrDdnoOBn37Ge+Gy1kinaKPwY32iR+sEVJhuJszuw/tH@gnusha.org X-Gm-Message-State: AOJu0YxnCyP01e27LZgeGUzNh7VVZelwnuCW693sY24qSLsDUZks+VLx gfgYSmddH0aI7USgaWyM1ZSvYnCIgjR5g0BGQIEcBjwxGdIdMY2zM95w X-Received: by 2002:a05:6870:e0a6:b0:3e7:e420:6229 with SMTP id 586e51a60fabf-40ef3bf73d1mr1265264fac.6.1770999688603; Fri, 13 Feb 2026 08:21:28 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HshX1sqRGa/6m7bCl7e+Bjsfsg5TvTDxs9Oitjkoy7PA==" Received: by 2002:a05:6870:420c:b0:40e:f703:9195 with SMTP id 586e51a60fabf-40ef703caf4ls594687fac.0.-pod-prod-01-us; Fri, 13 Feb 2026 08:21:24 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVe8fwoXmHnhsCJJnrezsNhhhP0xFFtK5GAblaRVkGRPpaxXjZNIO7GWI4GVYAeZk+jk5ylXocIG7J0@googlegroups.com X-Received: by 2002:a05:6808:f14:b0:463:7029:8b59 with SMTP id 5614622812f47-4639ef0ed56mr1109541b6e.17.1770999684014; Fri, 13 Feb 2026 08:21:24 -0800 (PST) Received: by 2002:a05:620a:51d8:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8cb3f827295ms85a; Thu, 12 Feb 2026 11:37:59 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWP4HtgKWUB6H4MtuPdDPyR3701H63t5w1VZSwYtiNz2CR/kYyCUsjZ8K8fUVOibxuRko7P5nEDmMhB@googlegroups.com X-Received: by 2002:a05:620a:4505:b0:89f:5f63:68eb with SMTP id af79cd13be357-8cb4081debamr6305285a.13.1770925078310; Thu, 12 Feb 2026 11:37:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770925078; cv=none; d=google.com; s=arc-20240605; b=kn/d3PFC30W0DSXRWlPY5RcTXEGDcYbKx6KyIQYzqkx+3hbIiZkeHirh48p1Z7E8eK x7r7AyWzEFeKlbdMpBtXNmLsYgkiMQa9GFlHhHCrnJyhmh9Qe19qpzncNZoqKNG/4dyX HU79QOIXv3R5gWONuvjWlbZew57eQBi0ibWKmD2669ji2qQTdTC/T7SatjLciL5s/N9M TzuP1FNmHRnh/COkUzl67XzKQjDQ8VCItWmLMoJgB0JwFJdrWvsQ6yvXLpSJ561sxutD 1taDP/zpannjmMigR8cg5kWFPxXqMjcP+Gsh5KBVMw4mPKD0bhddqn/o+Ejav+uPqCbG /cLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:mime-version:date:message-id:dkim-signature :dkim-signature; bh=jP6OICA/VNkLifjKMGBRMRrA/7oRxDKVG2p5i1VH7Dg=; fh=2EV9HtMw1QTzGSfUm2X/O0xVoxxmy5vUj8s0Z9ARrDA=; b=LQM8vn8yvi3BfTua7BmZMLpxwx0HWVUHNbOwd/UUrpWcL0kgRyw13CP5D4xyYWMjBz mcmCKVRLRIkItXb71KF/pyXUY79skyDEqN0yn0qAdIlVJFq08vyi1CV/asXqceaWRohX aQy7CEnctiuJshdjahKIycsyxXWVNIrlKQlGWDnLYFjHl6LUMEfka/LlAaFyr4pEbTW4 aPPQlvQlDLHt8pF88GX7TMCzC5217XYKm45knAexXD7Kgr4q1JJhm69u8CKODq68Wy48 KocWy7U+iS9gUAildnRfSHgyTYldXhv2D0ZeKoBT7VNbgezv1haPfZrAfWIO9RJg1dqh FPkw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1770922862 header.b=G5bpTWnF; dkim=pass header.i=@clients.mail.as397444.net header.s=1770922864 header.b=HJQ2Xx2F; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id af79cd13be357-8cb2b16896dsi15846685a.6.2026.02.12.11.37.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 11:37:58 -0800 (PST) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1vqcTX-00000008ICv-1Jkh; Thu, 12 Feb 2026 19:35:43 +0000 Message-ID: Date: Thu, 12 Feb 2026 14:35:41 -0500 MIME-Version: 1.0 Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: waxwing/ AdamISZ , Bitcoin Development Mailing List References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1770922862 header.b=G5bpTWnF; dkim=pass header.i=@clients.mail.as397444.net header.s=1770922864 header.b=HJQ2Xx2F; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/) On 2/12/26 10:36 AM, waxwing/ AdamISZ wrote: > > For what its worth I do not see a scenario where a decision ultimately made by the market will pick > the fork side with materially, say 5-10x higher, supply, over the side with lower supply...supply > and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today > use seedphrases, which could still be spent with a ZK proof-of-seedphrase :). > > This line of reasoning is wrong imo. > > If supply and demand is king, why not just delete supply as much as possible? No more mining? > Arbitrary freezing of various actors' coins (but with warning! so it's only confiscation in quotes, > right?). > > Hypothetical: someone proposes a fork which freezes all coins residing at utxos with addresses > containing "234" (insert technical description as appropriate - you get the idea). It'll be a bit > like the rules about driving into town with various letters in your license plate, though, a bit > more permanent :) The vast majority will benefit economically from the lazy few who don't notice, > since if they pay attention, they can hop out of the frozen addresses with time to spare, so why > doesn't it happen? > > Obviously, ridiculous examples, but .. point stands in general: > > It's a curious kind of self-referential. The "market" here is really the set of holders, their > *short term* interest is to grab any they can, but their long term interest is to have their stash > keep its value. There is *nothing* that will destroy bitcoin's value more effectively (certainly not > technical issues like bugs, certainly not an unexpected unlock of a big amount of coins to be moved > in the market) than an event that questions the "private property promise": > > 1/ coin inflation schedule is set in stone; > 2/ if you can cryptographically validate a transfer, bitcoin will let you do it, i.e. you can always > spend your own money; > 3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset will still be active and > let you spend in future, i.e. you can't be locked out of your own money. > > Bitcoin is the only digital asset in the world for which those assertions are credible; it has never > yet violated them, and imo it's the thing that keeps it unique and important (PoW ties in; it's > another aspect of the same rigid adherence to no controlling entities). > > That's why both this idea and Peter Todd's tail emission idea, both high quality engineering-safety > thinking, will not happen, in my opinion. I obviously agree with you at a high level - the value of Bitcoin derives from its (attempt at) trustlessness and any attempts to break that will necessarily result in the market rejecting them precisely because they break the exact thing that gives Bitcoin value. Its also hard to analyze this because it depends so much on the very exact scenario we're talking about. There are indeed certainly scenarios I can imagine where I think the market would prefer to not disable insecure spend paths. But at the risk of using an equally absurd example as yours, Imagine we discover a breakthrough in refrigeration technology that we've missed for 200 years tomorrow (or a room temperature superconductor, or...) plus a few other major engineering breakthroughs and we're now on track to have a CRQC in 2-3 years instead of 15-20, and oh in 6 months we discover that they're not just gonna be buildable soon but pretty easy to build farms and they'll be able to calculate a private key in seconds. Yes, we can stand on principle and watch as the CRQCs steal all the bitcoin and sell them to recoup their investment, but the market is obviously not going to value that because the thing that's left isn't recognizable as Bitcoin - its just some weird cryptographic scheme where tokens are shifting around all the time and everyone is stealing from everyone else. There would certainly be market participants (like you, I guess :p) that try to hold on to the original Bitcoin and might even invest some money in buying more (from the CRQC-operators). And the insecure-spend-paths-disabled fork would probably have somewhat less value than the original as a result. But the original chain would without question have nearly zero value, and the fork might have some. Now, this scenario maybe seems exaggerated, but actually I think its equivalent to the most likely outcome. Not that I think we'll see multiple major 100-year physics breakthroughs soon, but rather if we see a CRQC in the next 10-20 years, that the state of Bitcoin wallet adoption of PQ spend paths will be only marginally better than it is today. Sure, maybe 50% of wallets have upgraded, but that's not enough to have any outcome materially different from the above. Finally, more philosophically, I disagree that these are somehow equivalent. Yes, in stated black-and-white principles it violates the "ethics of Bitcoin", but that the *alternative does too*. Leaving the coins to be stolen by a CRQC almost equally violates the "ethics of Bitcoin" - the rightful owner of the coins, the one that created the private key and did not leak that private key to anyone else no longer has the coins! but... > > ZK proof-of-seedphrase :). > > Oh cool, that's a good point. Ethan's counterpoint is good too, that we would need a consensus rule > and that's v. hard, but: my spidey sense is tingling a bit about whether people might find tricks to > avoid it: if you consider the very clever tricks recently discovered around Glock, ArgoMAC and so > on, they enable gating txs behind ZKP schemes w/o new consensus but what we're talking about here is > way more narrowly defined than the larger problem they're trying to solve, which might support being > optimistic ...). I think this makes the philosophical point more stark! Now the options in front of the future Bitcoin community aren't "burn the coins or let the CRQC-operator steal them" then options in front of the future Bitcoin community are "burn some of the coins and let a probably-majority of the rightful owners claim them, or let the CRQC-operator steal all of them". I cannot justify why the second option is somehow more ethical or more in line with building the best, most trustless money on the planet. Matt -- 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/f0a2f902-2813-40f3-91ca-597ddcce1ed0%40mattcorallo.com.