From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 15 Feb 2026 04:19:12 -0800 Received: from mail-oo1-f55.google.com ([209.85.161.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 1vrb5j-0001Gr-Tx for bitcoindev@gnusha.org; Sun, 15 Feb 2026 04:19:12 -0800 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-662b9af3988sf18230732eaf.1 for ; Sun, 15 Feb 2026 04:19:11 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771157945; cv=pass; d=google.com; s=arc-20240605; b=VdVBDhppsljJ2f9e8rmiiYqRtOKJMFCwUN0eKp7rH2qR9z//kidBmd9nrKiYc1hfMM Y8JCV0gyNB/aOlawmn+Z5JkGR45oO05A0BIRD+FYEUSmk7RL5MaNvyxNPSUEY2bWdefC KFMF5E9YWqEoQNVo8N1Hd0tP+z5SMJHWcAZWgQnD8w/xH/TG9neg3+v4475p+SYNp3F/ CfZFooQ3rmweMmNCLCBSpD1+nEgE0J8YjADK35NC0/t0jiot2Z9HerXUV3Fn516RYxSt aUgMoH+2GHLf2+NgOBVNTFDaYyDU7ra4YUOoksaeYyDr3+e434Etz0xVN2oF6kfZCCLR 7/qg== 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:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=VZ499QFiXmtsJ5j/651YelX/wckHaL90kXp5jD+XU/Q=; fh=/l10WO+7ZlRUxRn/wcU+/0kGWWh6m6c/CaHc8AceSBI=; b=TaoSaFCh9EiyDxACdNUG9hRDEBsF9VwtwpkbI8bc8pHWNIGYSqsUaAp9X/YYE5Wgog SHl79sRusdSMW/zLllW8qQodkygFP7mzAgtD3z6h4R/llZmKj619785AzAmC9h9upyMa jn1hgGJ+uUm1dLBoK71pT9Zpx2serDyVDq4A95AN7qiYFYOuDNbfx5l5XGJSJYB9zh2V F/EOynZWJV1wXqCVSQKkFw0rlg3yFsWzAqoXLa/ddAQqNBF1dOxF/rtgQAdh5Yt6ldJO pUxilgHCNrqz3gP1otsmroCwsdyRYHrY0KjauZMX6FlLsfL/jUt5KFPBWgs14KMV1Wvm lpcg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1771155662 header.b="J6MI/77D"; dkim=pass header.i=@clients.mail.as397444.net header.s=1771155664 header.b="YT/MMbWe"; 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=1771157945; x=1771762745; 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:content-transfer-encoding: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=VZ499QFiXmtsJ5j/651YelX/wckHaL90kXp5jD+XU/Q=; b=srL8a5N8UbEe2GYhiNd9E3nPRn8BTKkmoA+SnbkAGBOEOhIiBT28qIzV3CU+Uwmrai +RPAyvoeZaZLVVVzOHUo+8z+Thk0znGv62JWkA5KnNSTMjt8FfQO9ntUmfErnG6cywhL C1M/TwzT/SaaEuvwEqkBjugEc3lqZZxA6l0JARkcMmByeYhs/fLOd9cQ2zwMEx5TNkvU 3Nu3aZtkEckrcqUnzT75mzvdqh2EELCiZKqD7JRtN9x6xG6P8K8QtqhIJUe6kkvRAtT+ z8hPqximuc3VwzJgAsuEkHarFx38I6rhCauLjYllJZil3TjaU7Sbiov6Kw1FdiItloES 8+fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771157945; x=1771762745; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding: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=VZ499QFiXmtsJ5j/651YelX/wckHaL90kXp5jD+XU/Q=; b=iC5JXExzyF+hxXOLXOrpL7OGackyUCkcro38vd9SvIPRy0beY943heH//f12apRumB /zuDJFdeAuz85mOVWocoH9F8Hhy23ZVklDeesOMe2HLSMxx90R5TcqxxZxT2HJBnS5OD GSyw32CalXTVzZzZZMxUBtgy5l64ybejR48qHpuZ0mE4T9W9OCIDU6WoNEQmjHp7cRhT +8M5Y15qcannw9xyF8sxYWmnxQHIFyawDOJLoUXFOEm4TX2kShiqte3Pfu9vwFdk9VUu +k0NNE80UH1AqqgWi5HNQuGGcHhrnz5NuWnvh3uM2gFa5gXyJ5NcDuSwK9gftXc4o7dl /YcA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUk3Kq1fLVw9g2j0JC/bSs812mxehe+UyIZcRcVQJJP+nsFz2cT/NyXmr5jsow1J7/CzvWsIjxzHh8K@gnusha.org X-Gm-Message-State: AOJu0Yy2i7rKXWuxC1kx9IiclxZE5g35sLbeP5UjDOYj4O+hEBlyVGLo i0lfXs4a1MgngVYNK5erFPLZbLLJUYgKZ+ZgcSVvVbnWHmNbETppPmGL X-Received: by 2002:a05:6871:4314:b0:3f5:694f:9366 with SMTP id 586e51a60fabf-40ef404c4a7mr4227469fac.30.1771157944909; Sun, 15 Feb 2026 04:19:04 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+G1S7Q3K+p0U0zFnbinSnM3RR5DSppETrI7yIabxksG+g==" Received: by 2002:a05:6870:420c:b0:40e:f703:9195 with SMTP id 586e51a60fabf-40ef703caf4ls1676811fac.0.-pod-prod-01-us; Sun, 15 Feb 2026 04:19:00 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXk4lLqWYB9LUW0ihN/hfj3A1pUGAWUYPql2Lv5PcslsUa9/bKTMyz7lAi0vRWWsLdiOFtQ2ABIsgYq@googlegroups.com X-Received: by 2002:a05:6808:6542:10b0:45e:a68b:30fb with SMTP id 5614622812f47-4639f1ead27mr3001287b6e.47.1771157940197; Sun, 15 Feb 2026 04:19:00 -0800 (PST) Received: by 2002:a05:6808:2164:b0:463:a65d:b610 with SMTP id 5614622812f47-463a65db7b9msb6e; Sun, 15 Feb 2026 04:13:01 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWHjnbapYULV2sWARXzXjZg0rRpnvsaraF42FPtOjIH2S4+Dk8oH50C32X4obDT08Z4Q/QNbPUJekBE@googlegroups.com X-Received: by 2002:a05:7022:926:b0:11b:9386:a3cf with SMTP id a92af1059eb24-1273ae8f205mr3897058c88.48.1771157580551; Sun, 15 Feb 2026 04:13:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771157580; cv=none; d=google.com; s=arc-20240605; b=BbzXdguChF53Gro+35q2VwCGsHjatn9EqC8iQl/qgK12MmNdCGINEpBiELUAEtTA5W pUyfAoLSBEbNEYWuGeKJzYD6mKn0dEt7vxbEt8vqDs+30Ajm0OjgBmB7iwJ95EhdpZQe EdzuLnJR0zf05r808HlJjbW73yr06eKdDL05vjmt4fY0GWpq1N4XIuaXKi/SRqffXK07 A9YWp7y70awboyS0SIS/Frx7DbjXRKqoVlwFS8DdxlV+t2Ztcxv3oVyGQA8YTDw+6UUM Rck5VI7Q66duUe8SWxDqifSJhqfSiPmMjZUyT4iSmWcyer+rnjcd0rkB11HedQlubtd6 Irug== 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=/ixt6erVcBgqMxFb9ZrJPxJwK6yvfBKrRRZhqK9TGr0=; fh=2EV9HtMw1QTzGSfUm2X/O0xVoxxmy5vUj8s0Z9ARrDA=; b=bTh/UKxEgX9HjUVR3MThn+0Pxg2aa6K3pz+GRLgCuefxYlG2dJdIX8dOBjPxYMC5C8 50iIigT+EaMmPPt2VBwH5D8KD4orrTNQavbfS288iYHJTnVmA2OOPFC9YL6SJYbV8lEX jYm0xtlteKW+W39Vrmq3ykfHToba/Eyi/RMrQ/s3JYfk/hMnYNSNS8atPhnjlATKv2Mz wF9td3cIEgbA/z21QY3VsckdX2O2wWXxezkYqs1HPFqILorINcN8Al6YUan4NQCs/tD+ M9EkKACHkre1ED+7N/o8W4moJJSDJGsXDAegMVskrKPNxU5BqCbmEJBzJnYBpoVjtnwr OV8Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1771155662 header.b="J6MI/77D"; dkim=pass header.i=@clients.mail.as397444.net header.s=1771155664 header.b="YT/MMbWe"; 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 a92af1059eb24-12742b6afb1si144251c88.1.2026.02.15.04.13.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 04:13:00 -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 1vrazi-00000008l5T-3OAx; Sun, 15 Feb 2026 12:12:58 +0000 Message-ID: Date: Sun, 15 Feb 2026 07:12:57 -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 Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1771155662 header.b="J6MI/77D"; dkim=pass header.i=@clients.mail.as397444.net header.s=1771155664 header.b="YT/MMbWe"; 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/14/26 7:39 AM, waxwing/ AdamISZ wrote: > Hi Matt, on this point: >=20 > >=C2=A0Imagine we discover a breakthrough in refrigeration technology th= at we've missed for 200 years > tomorrow (or a room temperature superconductor, or...) plus a few other m= ajor 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 pret= ty 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 rec= ognizable as Bitcoin - its > just some weird cryptographic scheme where tokens are shifting around all= the time and everyone is > stealing from everyone else. >=20 > For sure. It's unlikely but it's certainly *not* out of scope. Basically = the "it happens fast" scenario. >=20 > I don't see how it changes anything about the general principles. It's ju= st worse. People who are active > are going to move their coins to new outputs. People who are dead or lost= the keys are not. (People who > have locked them in a way that they are 100% inaccessible for 5+ years ar= e of course the most=20 > unfortunate case here, perhaps worth discussing separately.) No, its not just worse, it makes migration *impossible*. If we're talking a= bout having a large=20 majority of coins (certainly ~all the "active" ones) move within a year or = so, we'd have to first do=20 an immediate hard-fork to increase the block size to enable the migration t= o complete in time. In=20 the mean time fees will be insane. > It's just a worse (in terms of turbulence) version of the (far, far more = likely) slow scenario. >=20 > Look, I get the "yuck" reflex and the "this is ridiculous" reflex; if som= ething is patently=20 > obviously "open" and previously wasn't, then "obviously" we should just l= ock it up - or do=20 > something, anyway. But the real world, whether it's a 2 year time frame o= r the more likely 20-50++=20 > year timeframe, doesn't have this clean epistemology: we won't *know for = sure* when the world shifts=20 > from "outputs are safe" to "this stuff is claimable by anyone with the ma= chine". Even *if* it isn't=20 > all developed in super-secret (it probably will be), we still won't know. I don't really buy this. Sure, we won't be able to predict, with certainty,= two years out, the exact=20 day on which the first private key will be calculated correctly from a publ= ic key. But we will, in=20 all likelihood, be able to predict two years out that a CRQC is somewhere b= etween one and three=20 years away. In that case, again in many likely scenarios though not all, I = really do not think that=20 disabling insecure (non-seedphrase) spend paths is somehow immoral or again= st the tao of bitcoin. > That's why I said "perhaps=20 > worth discussing separately" for timelocks; there you have objective, pub= lic-verifiable "this is=20 > frozen" status. The "secure" vs "insecure" status simply will not be know= able in advance. That makes=20 > any engineering decisions that even *might* violate private property righ= ts completely unworkable. >=20 > >=C2=A0we can stand on principle and watch as > the CRQCs steal all the bitcoin and sell them to recoup their investment >=20 > yes, this is precisely what you would have to do (except as per previous = paragraph, it will *not* be=20 > obvious, even if large movements occur - what if someone actually owns th= e coins and is trying to=20 > trick the market?). Assuming the thesis is correct (that it's CRQCs doing= it), then the coins at=20 > that point are held in completely insecure outputs. Who has the right to = take them? Answer: anyone=20 > who's fast enough, just like a coin whose private key is "123" or similar= ly insecure, gets taken all=20 > the time. Should the network freeze insecure private keys when it sees th= em? >=20 > The problem is not the *reasoning* of safety. The problem is that, more t= han safety, principles=20 > matter, and unlike Groucho Marx, we don't have any others :) Right again I think a decent part of our disagreement here is that we're im= aging drastically=20 different scenarios. You (and I believe Odell and others) are imagining a w= orld where there's a=20 secret government lab operating a CRQC and stealing Bitcoin. We aren't sure= if its a CRQC that's=20 moving these coins, we have no strong public evidence of it, and there's de= bate as to whether to=20 burn coins in response to very weak evidence. In that scenario I'd likely a= gree with you. However, I do not buy this scenario as at-all likely. Thus far we've seen Q= C research operate=20 largely in the open, with a small world of researchers publishing their pro= gress for financing=20 reasons - the more you talk about the progress the more you can continue to= raise money to keep=20 working on it. Even if some labs "go dark" after making substantial progres= s, we'll be aware of the=20 trajectory of their progress before they do and can make reasonable, if con= servative, conclusions=20 about their timeline. Given the huge cost of these machines they largely ha= ven't been the domain of=20 academic labs (where there is a long history of government research partner= ship), but rather private=20 enterprise, where there is an interest in public promotion to encourage the= market to buy their stock. Further, given consensus cryptography recommendations have been pushing sup= porting PQ schemes to=20 avoid a rush to upgrade in a decade and the adoption of such schemes, its n= ot clear to me that, by=20 the time a CRQC is actually built, there will be all that much left waiting= to upgrade (aside from,=20 of course, borderline-unmaintained projects). Keeping a government-secret C= RQC when public QC=20 research is screaming "we're only a few years away" is probably not actuall= y all that valuable - the=20 value is decrypting old, now-insecure communication you've already captured= . Finally, its worth noting that this "secret government lab CRQC" seems some= what unlikely to run=20 around stealing large quantities of Bitcoin. Such a CRQC only has any value= if it stays a secret,=20 and any Bitcoin you steal is likely to start generating rumors, which will = intensify greatly as you=20 steal more. At some point you've basically tipped your hand and might as we= ll just make it public. Matt --=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/= da3265b4-e153-4c82-b0ed-e6bb021db7c6%40mattcorallo.com.