From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 15:17:12 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCm4F-0007ga-Hc for bitcoindev@gnusha.org; Tue, 14 Apr 2026 15:17:12 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-41701418411sf11877043fac.1 for ; Tue, 14 Apr 2026 15:17:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776205025; cv=pass; d=google.com; s=arc-20240605; b=T9ctlUSuRf08/aFvzwGOrI3recBiDd2h+7PWqAVolAhKqi5boOKeSNQkcPKGOcEqCx /UNvJ9FAfm13AC0f6qQ5Mf8uNPb609NByFKSizo5lU6c+1ZIaM3NAG32Xb7i1F6FnDcs 7GEF8CCx8v8WUbTYkeoJ2zT0dGcK460qifGxON8oCVG/YjdGemGk9+G6jVrEGpsHoIy2 /Uc9bPB66fENV1VZrTKHSiw6Gs8zdmXFaJ+Bo5lAN+xRfzhi9nHjWW+N0odXxyHL0aHu kz2Q9OGPZ7q5cqdRf/U7thRo9phBPILWJlCb0nRNhlwAyYJVvhmnCN7TdQCeWvUgW1VP XOMQ== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=LkywoRGybXRdUrFzk5ZOScKRWc9jIIrXxR6Un4Pdqco=; fh=5lYhek4zvyudRHTqDpRgnS/9nvzNwLPYWCCXY6rwhPs=; b=IZykPN35MUj/Ets5GlPS/dyFh4pXP7Xvvjdqme6Pb8x3AA8MY+R072fXAR3psGrKMx 4i6thkzR/nKs2xdWMegWBhNHV5RmIjtrMH49H7vA6c3BpVmIcLR8Tzh6uJQSlw8TqdQa ZP5JKZ+G5IeaPak/EK7ZmWOx1slXN0XWi6Az/efID7w3h9QF/yM8mMLNLkqTCBJnVW9H Yy5h21UrtTr9WegcoEX6EfkVYP+OTXjWw1ArziHP601OZuApiAmPVRho9DqlzQ/WOVe3 xILqC6ucpsEUb8bEMCsbbUUXF1xQfVxKlD3gDg9Y+/rTd17XgpOGKqDvXzGS89pqdOns Mksw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Rgfjlrx8; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776205025; x=1776809825; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=LkywoRGybXRdUrFzk5ZOScKRWc9jIIrXxR6Un4Pdqco=; b=rqoBWwe805NjI2girWkToxgR6qskttNe0H7Qhfo7tKdftWGQ2gRWdkjfUgS6oVgqFt zSN/BNGODVORO8nzdfd/lt/3PBttGP7OrqXkyJZyvwEgt4O1cotftDtZIba/T0ezy6J5 ga11m9bIzQz/YZ/juu9Ohpnz5av6RfU+t3RxPNdeM1sKv9NNPNbuTjxpUblNjHqI/g/S 7xp41JR8q64IG2u6T+YFZhuk+xeclxRrmK6n8iv5iPkFji958aOuTgpMRAKR0Uo1+83h tW9KjMCkYZADj4xslljAGIEE7Q1YhwVc3A/+BeRy5J+ZxMWnvEDJbslx4VmA2mJqsZrK EWzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776205025; x=1776809825; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LkywoRGybXRdUrFzk5ZOScKRWc9jIIrXxR6Un4Pdqco=; b=dLzSO7EdOszTbduQX1CwZpxGmG6FamaBMqSzljhknnknfj4p1jEVPnd3C3KK+qojoK qXgiGKOkvTLfBzVURjiiMitdBAA/Vo7bGOaiT9nb2dABaov3P6T2doJDapouadRaxqXu K422jiVYh4PwPCmPYTXwrCXXWH7HVIWEtJQoqZtCjqoruD2Dj3KyR17YjMhf+AVix5Iu V0CMO28raCVZs9kYhIq51gJIhDeBNOPX25ZL3VYcrbMiP98VEssQcmiqv1k1DqmSfsdw mfBXFrUEjYewM5kz+ro5baJgK5VNez+kvN3ylvk0HBrPN+3Rjc3gg6GlEs2K0rEVbYFG da1g== X-Forwarded-Encrypted: i=2; AFNElJ8d1yBwxeSSaTnXy79jP7li5MlwXEH2AJfJJy32eeJR0JKIgbkBYH+LcGhueU7P4J4u+lp7s9A/rlDm@gnusha.org X-Gm-Message-State: AOJu0Yz/ciq/LYkKxXBgZva0N2TyzwTHTHXuRWn3o8bLGRCGVroXa1T6 Y6wR2uNwCzIuJ3iPxmvb3FzrHej7Yx9LO2z6FTOaPPjmO5RovHkp3abf X-Received: by 2002:a05:6871:8908:b0:36e:8381:db00 with SMTP id 586e51a60fabf-423e0db87cemr11825281fac.9.1776205025030; Tue, 14 Apr 2026 15:17:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJ0fcPlB+QBDnoYnLywIHBYaXFsP955UKsqfGZmZ+lbow==" Received: by 2002:a05:6870:a092:b0:422:c0f1:a9e4 with SMTP id 586e51a60fabf-423dd0223a3ls2884721fac.0.-pod-prod-08-us; Tue, 14 Apr 2026 15:16:57 -0700 (PDT) X-Received: by 2002:a05:6808:c1f2:b0:467:edae:362 with SMTP id 5614622812f47-4789e72246cmr9822488b6e.29.1776205017714; Tue, 14 Apr 2026 15:16:57 -0700 (PDT) Received: by 2002:a05:600c:8a18:b0:488:963a:630a with SMTP id 5b1f17b1804b1-488f07ce094ms5e9; Tue, 14 Apr 2026 13:25:32 -0700 (PDT) X-Received: by 2002:a05:600c:34cd:b0:487:575:5e1 with SMTP id 5b1f17b1804b1-488d68c2cb4mr241289535e9.24.1776198330560; Tue, 14 Apr 2026 13:25:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776198330; cv=none; d=google.com; s=arc-20240605; b=kgEKB2lYEe2HZXVp1Nxdy77xQjfXQhYJ/bX41t0Xh4jxdfMhDckY7fy5HbSUBW/wGJ ZDbbwY8Cz+Zg3rxo8nQqpMcbZN3Sbcsfcsm83hs0WXHBFk3WNufvt6aS4oMOZjtLGES2 JxhVyxJ3ngENEcbqc2GSJE22TZ0HkC4/58n91nSf3C6roNhj8IM1jLGZ5sma+Bm3eJYs xVp0+NJFo0V7d4ur4nDR/LYODr477ktw4eFBlB+Znc9Kxjd98Cy19QfPKIY6YN71HUxR Ro1HQrsOkuhOB6PIM7wRRjzKLqyc6KEnHDQTZcMil4Zlpff/O9TLGleOUcBFSk2j/8IF +kEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=X+fC/jwPBaNIv0HL4LJmwmA5R4AdHXeDJXdVeIy8MYI=; fh=t0xe4s6OwK/nag7dWixgc9y26E3m78ldPpNpzh4RGuU=; b=WhuCBq/5LVUeWrRDSjbR155GDfOAVPAGDbKbz5xdXfNHcY/g2NSsiUaTPi8Pq8RCKh 1Fi+T0xSwfiCQ9+YM5jEVZ+ICyoiD+ATGk3w5BbAxzKbSpWS45b64PDj2A4OLtAHX8b5 WykE90eUimoumYMYgSX/2/bTsLftgdw4U4m/Wk9LGM1BOHhFph3kZ9j2Tn4t4uiwBgKH ZcAYjmCeGT68+ZB1Hbz5U3AjcgZkPjGAbALbfF3d4uB7gacS0MN/+x6f+CVmSrgr2moz wEoHdiFvkQZGWEW6mPXxfkkodKyeL6g+zV6SwFkUyfMKuHSGFzHTXYPfjWzjZ4MMEQmt d5LA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Rgfjlrx8; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch. [79.135.106.102]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-488f0e5f404si34935e9.2.2026.04.14.13.25.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 13:25:30 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) client-ip=79.135.106.102; Date: Tue, 14 Apr 2026 20:25:22 +0000 To: Erik Aronesty From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Deactivating ECDSA/Schnorr Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: fea58bc11d8625b99cab82cb49c13a07b29d7cfb MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------1b7c0cc158aa2ffefa8b8f04fe843224ec054d71a2d6fedb6c95a35c42993c21"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Rgfjlrx8; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.102 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------1b7c0cc158aa2ffefa8b8f04fe843224ec054d71a2d6fedb6c95a35c42993c21 Content-Type: multipart/mixed;boundary=---------------------e0a7c9b2e84f4d94d30141055d0736ba -----------------------e0a7c9b2e84f4d94d30141055d0736ba Content-Type: multipart/alternative;boundary=---------------------b2ffa505b422456ba0cd9b5d7c445e19 -----------------------b2ffa505b422456ba0cd9b5d7c445e19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Erik, > Deactivating ECDSA/Schnorr based schemes should not be discussed seriousl= y. > ... > The worst possible thing we could do is confiscate everybody's coin and m= ove to a NISD approved algorithm on the say so of large government funded o= rganizations. You seem to be under the impression that a confiscatory soft fork would com= pletely lock and freeze any and every coin that isn't on a PQ-safe address.= If so, you are mistaken.=C2=A0I don't think anyone would ever be so foolis= h as to deploy a soft fork that disables ECC spending without introducing= =C2=A0some set of rescue protocols to complement=C2=A0legacy ECC spending r= ules. I'd urge you not to think of such a fork as "disabling" ECC spending, becau= se that is not the entire picture. Instead think of it as "restricting" ECC= spending to a tighter set of rules which a quantum attacker should not be = able to abuse.=C2=A0Laolu's recent work on building concrete BIP32 STARKs= =C2=A0is one such awesome example of a tool which can do this - It works to= day and it covers every BIP32 wallet, even those with exposed pubkeys and x= pubs. Though personally I prefer commit/reveal for better scaling. There will probably be some non-zero subset of the UTXO set (whose holders = are alive and still have their keys) that cannot meet these stricter condit= ions to satisfy the rescue protocol, and so cannot migrate. These coins wou= ld indeed be confiscated. There is research needed to quantify this, and it= depends a lot on what rescue protocols can be invented between now and Q-d= ay, and on how many UTXOs we can reliably say are or aren't covered by each= protocol. Today, we can confidently say that any address derived via BIP32= , or any hashed address which has an unexposed public key, can be rescued. = Others are open problems. > There is simply no credible way you can convince somebody who is sovereig= n that their encryption algorithm is broken aside from breaking it. I suspect many Bitcoiners agree, which is why any confiscatory soft fork wh= ich restricts ECC spending will probably only be triggered after=C2=A0a CRQ= C has been demonstrated concretely, e.g. by breaking the NUMS point, or spe= nding satoshi's coins, or with a ZK-STARK that shows they could=C2=A0have s= pent satoshi's coins, or whatever canary mechanism we might dream up and ag= ree on. Personally I'd prefer to trigger it earlier rather than later, because we h= ave no reason to expect a CRQC to cooperate with our canary system, but I r= ealize that might be a hard pill to swallow, so a canary would be a decent = compromise as long as the community has the option to push a panic button a= nd force-trigger the upgrade through majority hashrate consensus later, to = cover the case of an adversarial CRQC who sidesteps our canary. > Bitcoin is not a nanny state."oh no someone might break satoshi's keys" > Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty that = propels humanity to a future of limitless unbounded magical computing that = is not a problem we need to solve right now. > The worst possible thing we could do is confiscate everybody's coin and m= ove to a NISD approved algorithm on the say so of large government funded o= rganizations. > That sounds dystopian at best. I appreciate your code-is-law purism, but there is an exception to every ru= le. Ethereum's DAO hack shows us what happens to those who commit to such uncom= promising fervor. Ethereum's devs had committed to code-is-law, and then fa= ced a similar situation where a large fraction of their supply=C2=A0(one th= ird of it, if my sources are correct) was at risk of immediate theft, and t= hey could either stick to their principles and do nothing, or intervene and= hard fork. The interventionist chain turned into ETH and the purist chain = turned into ETC. Today, ETH=C2=A0is far more=C2=A0economically=C2=A0relevan= t than ETC, because their community recognized that cruelty is not the ethi= cal response to tragedy.=C2=A0Users prefer not losing their coins to attack= ers, basically. They prefer to use technologies whose devs take steps to pr= event that sort of thing. ETC meanwhile has suffered a slow death, as devs = and users migrate to greener pastures. Their situation rhymes with ours, but is very different too. We can see our= threat (CRQCs) coming from years away, and can prepare today to avoid the = need for a hard fork. So in a way, our prospects are more optimistic, but o= ur problem is also far harder to engineer around. It's not just a single bu= g we need to fix. It's the fact that our entire supply is currently resting= on a shaky assumption (the ECDLP is hard). When and if that assumption bre= aks, some significant fraction of coins will also be at risk, and we will b= e put to the same choice as the ETH devs were: Do we intervene and compromi= se our principles to reduce the fallout, or do we do nothing? Personally, I think we should learn from the history of the ETH DAO hack, a= nd make the same choice the ETH devs did: intervene. We have options to mit= igate the confiscatory effects of intervention, and we can do it without a = hard-fork. While I doubt the appetite exists to deploy any of this stuff to= day, I suspect it will be someday when the threat looms larger. regards, conduition On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty wrote= : > Deactivating ECDSA/Schnorr based schemes should not be discussed seriousl= y. >=20 > You give people alternatives, yes. I'm a big fan of quantum optionality. >=20 > But we cannot have a forced vaccination situation. >=20 >=20 > There is simply no credible way you can convince somebody who is sovereig= n that their encryption algorithm is broken aside from breaking it. >=20 > People can send to bad keys today. >=20 > There are lots of op codes that let people shoot themselves in the foot >=20 > Bitcoin is not a nanny state. >=20 > "oh no someone might break satoshi's keys" >=20 > Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty that = propels humanity to a future of limitless unbounded magical computing that = is not a problem we need to solve right now. >=20 > The worst possible thing we could do is confiscate everybody's coin and m= ove to a NISD approved algorithm on the say so of large government funded o= rganizations. >=20 > That sounds dystopian at best. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.com. --=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/= NaG-z72AcUvBjEO5c4yZzEbmkuPkUCwYlHMEGECRPE3C2cUhnD6on_F3eSI38-7quhWNIziELfk= QUl3KbWnFSMl7aCtRDNLvb79eqRgrkWI%3D%40proton.me. -----------------------b2ffa505b422456ba0cd9b5d7c445e19 Content-Type: multipart/related;boundary=---------------------4be337330f6da94426fda3987695c795 -----------------------4be337330f6da94426fda3987695c795 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

Deactivating ECDSA/Schnorr based schemes should = not be discussed seriously.
...
The worst possible thing we could do is confiscate everybody's coin= and move to a NISD approved algorithm on the say so of large government fu= nded organizations.

You seem to be under the impression that a confiscatory soft fork = would completely lock and freeze any and every coin that isn't on a PQ-safe= address. If so, you are mistaken. I don't think anyone would ever be= so foolish as to deploy a soft fork that disables ECC spending without int= roducing some set of rescue protocols to complement legacy ECC s= pending rules.

I'd urge you not to= think of such a fork as "disabling" ECC spending, because that is not the = entire picture. Instead think of it as "restricting" ECC spending to a tigh= ter set of rules which a quantum attacker should not be able to abuse. = ;Laolu's recent work on building c= oncrete BIP32 STARKs is one such awesome example of a tool which can do this - It works today = and it covers every BIP32 wallet, even those with exposed pubkeys and xpubs= . Though personally I prefer commit/reveal for better scaling.

There w= ill probably be some non-zero subset of the UTXO set (whose holders are ali= ve and still have their keys) that cannot meet these stricter conditions to= satisfy the rescue protocol, and so cannot migrate. These coins would inde= ed be confiscated. There is research needed to quantify this, and it depend= s a lot on what rescue protocols can be invented between now and Q-day, and= on how many UTXOs we can reliably say are or aren't covered by each protoc= ol. Today, we can confidently say that any address derived via BIP32, or an= y hashed address which has an unexposed public key, can be rescued. Others = are open problems.

There is simply no credible way you can convince somebody wh= o is sovereign that their encryption algorithm is broken aside from breakin= g it.

I su= spect many Bitcoiners agree, which is why any confiscatory soft fork which = restricts ECC spending will probably only be triggered after a CRQC has been demonstrated concretely,= e.g. by breaking the NUMS point, or spending satoshi's coins, or with a ZK= -STARK that shows they could = ;have spent satoshi's coins, or whatever canary mechanism we might dream up= and agree on.

=
Personally I'd prefer to trigger= it earlier rather than later, because we have no reason to expect a CRQC t= o cooperate with our canary system, but I realize that might be a hard pill= to swallow, so a canary would be a decent compromise as long as the commun= ity has the option to push a panic button and force-trigger the upgrade thr= ough majority hashrate consensus later, to cover the case of an adversarial= CRQC who sidesteps our canary.

Bitcoin is not a nanny state.
"oh no someone might break satoshi's keys"<= /div>
Let them. if sato= shi's 50 Bitcoin stash keys serve to be the bounty that propels humanity to= a future of limitless unbounded magical computing that is not a problem we= need to solve right now.
The worst possible thing we could do is confiscate everybod= y's coin and move to a NISD approved algorithm on the say so of large gover= nment funded organizations.
That sounds dystopian at best.<= /div>

I appreciate yo= ur code-is-law purism, but there is an exception to every rule.

=
Ethereum's DAO hack shows us what happ= ens to those who commit to such uncompromising fervor. Ethereum's devs had = committed to code-is-law, and then faced a similar situation where a large = fraction of their supply = ;(one third of it, i= f my sources are correct) was at risk of immediate theft, and they could e= ither stick to their principles and do nothing, or intervene and hard fork.= The interventionist chain turned into ETH and the purist chain turned into= ETC. Today, ETH is far more economically 
Their situation rhymes with ours, but is very = different too. We can see our threat (CRQCs) coming from years away, and ca= n prepare today to avoid the need for a hard fork. So in a way, our prospec= ts are more optimistic, but our problem is also far harder to engineer arou= nd. It's not just a single bug we need to fix. It's the fact that our entir= e supply is currently resting on a shaky assumption (the ECDLP is hard). Wh= en and if that assumption breaks, some significant fraction of coins will a= lso be at risk, and we will be put to the same choice as the ETH devs were:= Do we intervene and compromise our principles to reduce the fallout, or do= we do nothing?

Pe= rsonally, I think we should learn from the history of the ETH DAO hack, and= make the same choice the ETH devs did: intervene. We have options to mitig= ate the confiscatory effects of intervention, and we can do it without a ha= rd-fork. While I doubt the appetite exists to deploy any of this stuff toda= y, I suspect it will be someday when the threat looms larger.


regards,
conduition
On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty <erik@q32= .com> wrote:
Deactivating ECDSA/Schnorr = based schemes should not be discussed seriously.
<= br>
You give people alternatives, yes. I'm a big fan= of quantum optionality.

But we cannot have a forced vaccination situation.


There is simply n= o credible way you can convince somebody who is sovereign that their encryp= tion algorithm is broken aside from breaking it.
People can send to bad keys today.

There are lots of op codes that let p= eople shoot themselves in the foot

Bitcoin is not a nanny state.

=
"oh no someone might break satoshi's keys"

Let them. if satoshi's 50 Bitcoin st= ash keys serve to be the bounty that propels humanity to a future of limitl= ess unbounded magical computing that is not a problem we need to solve righ= t now.

The worst possib= le thing we could do is confiscate everybody's coin and move to a NISD appr= oved algorithm on the say so of large government funded organizations.

That sounds dystopian at bes= t.







--
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/CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dt= EYRaB1w%40mail.gmail.com.

--
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/bitcoindev/NaG-z7= 2AcUvBjEO5c4yZzEbmkuPkUCwYlHMEGECRPE3C2cUhnD6on_F3eSI38-7quhWNIziELfkQUl3Kb= WnFSMl7aCtRDNLvb79eqRgrkWI%3D%40proton.me.
-----------------------4be337330f6da94426fda3987695c795-- -----------------------b2ffa505b422456ba0cd9b5d7c445e19-- -----------------------e0a7c9b2e84f4d94d30141055d0736ba Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------e0a7c9b2e84f4d94d30141055d0736ba-- --------1b7c0cc158aa2ffefa8b8f04fe843224ec054d71a2d6fedb6c95a35c42993c21 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmneoqIJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfx+foOse/PkvETIrt/begA8vAUiyr0d7h4q09n K1m7kBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACewQEAhUMrrkbtn0XcmKTN Xf/zGpyAxAAuSSaKYXwxLSpOhXIBAMXDPYKyUllUuFa8km9UMC/mupMl5GsW H4fqszXa8NIH =VFN/ -----END PGP SIGNATURE----- --------1b7c0cc158aa2ffefa8b8f04fe843224ec054d71a2d6fedb6c95a35c42993c21--