From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Apr 2026 13:47:12 -0700 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wHpKp-00015H-63 for bitcoindev@gnusha.org; Tue, 28 Apr 2026 13:47:12 -0700 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-50edf0245b0sf71302671cf.1 for ; Tue, 28 Apr 2026 13:47:10 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1777409225; cv=pass; d=google.com; s=arc-20240605; b=XooQdEA9WtO/W837PmFsvEXPSiM+LiSay/Nf6fxLTOBdRBMMRzOz47drItld7b6Gu9 k4vseDOnmXocq4GSgEAdMkn0HGPBzrcrzXHcR0IQLx6hlkn/iY3y+XuIR6dkIkJXyr+z UQh7U7FslkyFv2MfFkT8sTjGhKOmfovDx2fH1nPSHvS7gx3cExzTDlaDKuCMHn0LOkyr uBXOcHZEoRootrNnPRnTXfWrP/OnpXAblbDzyFpg8zllh97gjddaP8oOknwhNo2i1C78 cuX2E00GGfdZTx7haqFyF10wmuotvhRi6a7OfuW/3c3GsTCUIl6pQA6ShuqOD0eRULyH YM7w== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=dvo8h7Y04wlHGga6Wv6l6RajewFjBQItoISb6gvnZ1E=; fh=NSP6LEdZe6+2jrq3ouuvcwmIl/oVq8+gpBmLHQNFoV0=; b=ey7saSAes3a5zGrGfzeL22ik+NUPvpvX9QQ6/OZNhRaq7x8FC9tSihU4WdYgjfSW2r h3ub5L1PnfCbQnuKa1RE2s26amO3YMhN9ASO7Sbe1DdlNHtKsl3ZPj480rH6ANJTbJoA W7J/AFBrjkaDU7ZpMulj+s3kUQ18YtfHc9ncTBFdjJP724y+df3lcolZXwsfMeggsstB IULld1EKIq4dwT9AzokwMldXOTpQiYeXkXHMf5q80Hdgsd0W862IFGKd4DZTAMMSkJ2r 8eIewerum4TUG6HJtBTnHcXhc6dRKS03f+de2nF2BCiMy+Z0QXf1Ox0b6FtlsAGI4jF0 +MUA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=OhGWV786; arc=pass (i=1); spf=pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=aderb001@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777409225; x=1778014025; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=dvo8h7Y04wlHGga6Wv6l6RajewFjBQItoISb6gvnZ1E=; b=BQ6NBhDSN3Rh4NFdEhOK3dQS2/TC0M6Jb/dGVAIi3xY1yMZj8e6UtBR3pdGdfmOyQh tYy27vFMOnfzRHVz057c4smQkX4Ye73Jm8KgEds/EQlgGPR9u0NaA8L0Tb5AtAWa0DaO 6JBJKkCIYcGiAvpqjzkDnpC9JXMAIzGdr3qOLPRJAsQGM9V9ReNprUuBJAQ+CbX39K70 dByn9WwbwHLtWAL2myg2KUtQ0diMZP0+6I+V+BTEaXr4LRYXxCuSs2m7rg3M5rnrAIBB RTFVD0mXT6KvkjYfySWitk2dGBnprQM7dpR4RGGCL+mJ1sXFS84q/DflxhjCJkswhC5z DCqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777409225; x=1778014025; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dvo8h7Y04wlHGga6Wv6l6RajewFjBQItoISb6gvnZ1E=; b=ASSsE9Lm/DoqAR2e7l31pPqTYb5n/5DJ3oIoyrVpyilJLFLKrlCrsoRkBcZjeC0fei 6ecRg9sYwyHFXCIksevVnMqshdcBvlKoItz3fJTraGzprglIlqSwxaq7PNZc9+AH+jqs fBH3dIh9sWSgqwcPfaQleeXZY24ksby7qkHVPuJYXV1qz3edOpkw1bs/NScAjkvYlBEt oY9BucU2G6AZLAVHZZBKy+1Zvbzj/fPsCTngQONu0EJDgUuU2S/jAzRLzQ3aNSYNllUI Oqf69vI9a62RomrqrtO2UVRhmRcYr9AsOgKeI80oirj40xBaUaBt5vEHHBlIrg3y3KHj 3Fbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777409225; x=1778014025; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=dvo8h7Y04wlHGga6Wv6l6RajewFjBQItoISb6gvnZ1E=; b=SNpFNYcyfdUZPcIPGHIB1JUDE3TIj66zirD952/UAqb3uO/Xn27gYGCkGzSCGIpf2z ed98mnk/pjGYBroPsrVIJbGWgqGhg9YwvSzIjHtjP0aPelfrE2+D9KCBhcC/mALbzP9t nDMxblH+1FYWOYn7/C//bxXwDzi80jqRnv/lJDCeEJVoSiqq3fT2xWOfA+uSChNuXPAK jK+WFv9WkYdsmQusMu/QGUlPjwKYZ5TrcwKDLeoRPxP7LOWOVBjza1pjbw5q/yUqwo5e //oJYm1qwArRZ77bDj05Q9IdQMR5Y7AWkBfVsRMqswojDrvE3YAsNTT/vq4arvBEGZI6 JPAw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+B1oG33D+6ZILYIv1GT02KD10icvx//ROVekBkaF8ZwuF7Ex1nCoWBEwcXGQO1HMoIFVTitQXNoiHA@gnusha.org X-Gm-Message-State: AOJu0YwuDhTsw93JAOUJjL0s1rDzHbW7NIr41nDRXfvjXR2fC3RPxl5V 97miaiCLbwTNnBY2N3+bd5Cf5znPwxc/cIZCTc4KLyl3eMjK97oTCKo0 X-Received: by 2002:a05:622a:1883:b0:50e:5755:912e with SMTP id d75a77b69052e-5100e19b5admr66533751cf.35.1777409224594; Tue, 28 Apr 2026 13:47:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOpuC9KXLRqtOiTx3wFoeBRbEQBeecOIhKex5mKXzJGrQ==" Received: by 2002:ac8:5889:0:b0:50d:a977:953a with SMTP id d75a77b69052e-50fad933780ls173932031cf.2.-pod-prod-03-us; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) X-Received: by 2002:a05:620a:4627:b0:8cf:d510:3b39 with SMTP id af79cd13be357-8f7d9207db1mr669525385a.40.1777409217485; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) Received: by 2002:a05:600c:8a18:b0:488:963a:630a with SMTP id 5b1f17b1804b1-488f07ce094ms5e9; Wed, 15 Apr 2026 10:25:12 -0700 (PDT) X-Received: by 2002:a05:6000:4207:b0:43b:4166:b855 with SMTP id ffacd0b85a97d-43eb10e57a3mr417318f8f.14.1776273910852; Wed, 15 Apr 2026 10:25:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776273910; cv=pass; d=google.com; s=arc-20240605; b=GHxe14/JL+sS7Sy70s1OM9y4vl30yd3wYIC1goqewR1/S1ZbDu58LtgK9TB13QaPE/ 0Hqf1aHV8BSgJi6+p2Xcv39ykIlC2o+mim7L1ijobdQKO/yHpd9aCMjqpwWgZnNQbL0h m7vFf6kjyYEyHWUETpOfIkUUtBywp9JZxsZ+yHxjW+IILjhvlm/BPfgkaG0uUYScnHxE njRhG8wxtI+TE8HBCr912r0SW6YTkET2ARLZITlsU57mk43E9x1lC4jtoP1pYInogV8T vi6CHbx/p8ZeynKmEWdFmwhRUNgH6vT8RpfL+RQeX+3/DhbKXlQcFljGPZ/NuuGTXJ43 SXzw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xcneLaRQJHnkwAu4V4ZtbB5rSftaE51xNP49xaxQhzU=; fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=; b=X8K4UFjaWQttQobyNRGx/YjdG/hHq5fhi+iQMq+7ESIW/EJdbT2q1m/Qtwpx8EURat TiTCLKtPPbF7xZ7eY6kZ2xKtdfUb1h42TIeL6AQ3b12JYEb5uScTnz1ys7KBc3kCH47x UDIInf3AHf/a5tRttTWasloUPSKtoBAoyxt+Nc3qT+/x8w0W0FFidYrPIXDta97Z+OIH 6js/duHu9FqiFRLc9Qy0RaUkThfz7pNLOFERbsZuP5kEXJPCcC0ovdJ4WHJ1s8uzmDNg lfi9Mv1QP4USqEtrFnceJBGeAVG8wle8xYvp8GGKaq1miESFhDcsQ3NnBQ2DqdHLfzjo RfGg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=OhGWV786; arc=pass (i=1); spf=pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=aderb001@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com. [2a00:1450:4864:20::330]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43ead3ce726si53373f8f.3.2026.04.15.10.25.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 10:25:10 -0700 (PDT) Received-SPF: pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) client-ip=2a00:1450:4864:20::330; Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-488b3f8fa2bso71532095e9.1 for ; Wed, 15 Apr 2026 10:25:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776273910; cv=none; d=google.com; s=arc-20240605; b=AylJILXML/RUte4E5lIRg7FoWFdKGp6OLMCcFXe/L+aaTWu28R3HAV2CaDxMA0ccUh hrU0gYHu6e5c4wobLOrFcPRPb1CnID9fVW01tiRmr1CNdcN+QtfQeFXEZnJKheZmFr04 hInWWbOZY7dMFcJkInhpZOxkMf4s64bP3BuZZgvndIkLOjo7nJp7L3Onqs2vPClcHgVz 4PUKo4+XNN8g5vZP1xXZnGgMFi04apCxFFZYOxuNrbk/r4dKjgtta3zrO7wY51+K4rNs hn5CZKhhs0rzqJyhmVfjkum6g3jL5FWfDG4qR/IRklW2ax+VVb29elPDsvHcdo2G10yC nsIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xcneLaRQJHnkwAu4V4ZtbB5rSftaE51xNP49xaxQhzU=; fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=; b=OGbS48gGyz7zMBFvGj0nzBkWsKkUsx2tJDC54m1nQXmpaeoliwVn84vrKvLhG/MU3x NFiQC0bNCYWHwYv7Pvr53W7Q438cY1FscHkbOeMLWRy0Umsxjv7I8IcSgESRa9ZKtuNd a3pNTcMea7tD90kaTRdBGyFJnf9afkfineTZkYqfHXD121Z9AHlP+ox8t02RaGLf6F66 hLKrrClsc4do/zsYR3d7BTJCFJi4xhtIRcl4fgph2NTgDq8Kr77f+Tsp0W7dvcXXzBix MD8nM8C7S7H2cup1tq7j/x3VP0XmM/IlV+UrUBUf2zBhTNkB66LyS1XacdCgpxhrFkZ+ nVvw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDieuZL7jAEyjpgJ+mmUWGldNcuNKBaIss9dg0FEA9CgpPC83YzTiXhVUy7betcXE wR4uE5xNwUlpHEN8t/20lV2hM+sP64zxla3yjFQWjhbp2Ewv34KVCr0fbGOEC1hxnQENUJnHpJs hUHaukPWOQ0YljYnnok8n9JJ922gXE4ZincshM2JlYL9elathyrus62gq3KjCapiZ4mZBR5XGTS 8V1berDhXAuu2f/2mfopI8oyUbjRhNJQzESEsIHu7Ap0k75of/13ZCcYT2pJAlPaqWmoz4PS84F FJUas9FoXeVUyNKWjl/XaKP86P+DEb70Qp5PRCs7s13fW/T9KXf3dBTukodBuq8OPpjDe2KKNL0 jZRpTrKtLf6s46bpw61fTn7aYS6C/iThMhvvTLL1WsXIajF8= X-Received: by 2002:a05:600c:1e28:b0:488:9c3b:ff40 with SMTP id 5b1f17b1804b1-488f4829bc6mr5234455e9.15.1776273909955; Wed, 15 Apr 2026 10:25:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony Derbidge Date: Wed, 15 Apr 2026 11:24:57 -0600 X-Gm-Features: AQROBzD2iWo9lLpsG1Y5eppZgJEk3dYpaQVNvuUi_sVBpCi37e-FWnuqd-05CCI Message-ID: Subject: Re: [bitcoindev] PQC - What is our Goal, Even? To: Matt Corallo Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000006d3ed3064f82ffae" X-Original-Sender: aderb001@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=OhGWV786; arc=pass (i=1); spf=pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=aderb001@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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.5 (/) --0000000000006d3ed3064f82ffae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Matt, agree the binding constraint is the wallets least likely to migrate, and that scope discipline matters here. One minor distinction worth keeping in mind: if the community eventually faces the fork-and-burn decision you reference in [1], a PQ-signed record tied to pre-attack UTXO state could still matter for distinguishing prior owners from post-attack claimants, even if it doesn=E2=80=99t solve the spe= nd-path problem itself. For the =E2=80=9Cwon=E2=80=99t-migrate=E2=80=9D bucket, tha= t may be one of the only ecosystem-side ways to preserve any independent evidence of prior control without depending on wallet vendors to ship anything. - Anthony Derbidge On Wed, Apr 15, 2026 at 10:51=E2=80=AFAM Matt Corallo wrote: > Its become obvious in recent discussions that a large part of the PQC > discussion has people coming at it from very different fundamental goals, > and as a result the conversations often talk past each other without maki= ng > real progress. So instead of doing that more I'd like to write down what = I > think the actual, short-term goal *is*, what it it is not. > > Fundamentally, it seems to me the most reasonable goal is that we should > be seeking to increase the number of coins which are reasonably likely to > be secured by the time a CRQC exists. Put another way, we should be seeki= ng > to minimize the chance that the Bitcoin community feels the need to fork = to > burn coins by reducing the number of coins which can be stolen to the > minimum number [1]. > > This naturally means focusing on the wallets which are the *least likely* > to migrate or otherwise get themselves in a safe spot. Focusing on those > who are the most likely to migrate does almost nothing to move the needle > on the total number of coins protected, nor, thus, on the probability of = a > future Bitcoin community feeling the need to burn coins. Sadly, this > probably means the "top wallets" that are generally terrible at adopting > Bitcoin standards. Wallets which are the top listing on app stores like > (currently in the top few in my app store): Bitcoin.com, Trust Wallet, > Coinbase Wallet, Blockchain.com, etc. These wallets generally use a singl= e > static address (because anything else confuses their users and they get > additional support tickets for it!) and put very little time into Bitcoin= , > focusing instead on other tokens and integrations. > > A few non-goals: > > * To ensure that advanced setups have the absolute best in post-quantum > security. I don't see how this moves the needle on the above goal, and in > fact in many cases detracts from the above goal. Of course if we can > accomplish this without detracting from the top-line goal above, great. > > * To ensure we have the best possible design for the signature scheme > bitcoin will be using in a world where a CRQC exists and we've gotten pas= t > the mess. We'll almost certainly know a lot more about the security of > various schemes and have more options for how to approach the problem by > the point we're dealing with the mess of a CRQC being imminent, so it see= ms > like a fools errand to try to predict what we should build for this. But > even if we know no more then than we do today, likely ending up with > hash-based signatures as the scheme everyone uses, we'll almost certainly > be having conversations about additional witness discounts or increased > block sizes to compensate for the sudden increase in transaction sizes. > Maybe we would decide against such an increase, but there's no question > such a conversation would happen and it would be premature to have it tod= ay. > > Matt > > [1] Of course I believe that the lost coin pool is large enough that the > Bitcoin community will, almost without question, fork to disable insecure > spend paths and burn some coins in the process, but reducing the number o= f > coins burned to the absolute minimum is of course best for everyone. > > -- > 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/CF7A554D-EE6F-4E6B-A670-1D6F= 72170539%40mattcorallo.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/= CACja%3DNxfNT4dkS9F3L%3D9HKwxqLPJOJ6MJxfhWZrbkX-K-fuHhw%40mail.gmail.com. --0000000000006d3ed3064f82ffae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Matt, agree the binding constraint is the w= allets least likely to migrate, and that scope discipline matters here.
=
One minor distinction worth keeping in mind: if the communit= y eventually faces the fork-and-burn decision you reference in [1], a PQ-si= gned record tied to pre-attack UTXO state could still matter for distinguis= hing prior owners from post-attack claimants, even if it doesn=E2=80=99t so= lve the spend-path problem itself. For the =E2=80=9Cwon=E2=80=99t-migrate= =E2=80=9D bucket, that may be one of the only ecosystem-side ways to preser= ve any independent evidence of prior control without depending on wallet ve= ndors to ship anything.

- Anthony Derbidge
On Wed, = Apr 15, 2026 at 10:51=E2=80=AFAM Matt Corallo <lf-lists@mattcorallo.com> wrote= :
Its become obv= ious in recent discussions that a large part of the PQC discussion has peop= le coming at it from very different fundamental goals, and as a result the = conversations often talk past each other without making real progress. So i= nstead of doing that more I'd like to write down what I think the actua= l, short-term goal *is*, what it it is not.

Fundamentally, it seems to me the most reasonable goal is that we should be= seeking to increase the number of coins which are reasonably likely to be = secured by the time a CRQC exists. Put another way, we should be seeking to= minimize the chance that the Bitcoin community feels the need to fork to b= urn coins by reducing the number of coins which can be stolen to the minimu= m number [1].

This naturally means focusing on the wallets which are the *least likely* t= o migrate or otherwise get themselves in a safe spot. Focusing on those who= are the most likely to migrate does almost nothing to move the needle on t= he total number of coins protected, nor, thus, on the probability of a futu= re Bitcoin community feeling the need to burn coins. Sadly, this probably m= eans the "top wallets" that are generally terrible at adopting Bi= tcoin standards. Wallets which are the top listing on app stores like (curr= ently in the top few in my app store): Bitcoin.com, Trust Wallet, Coinbase = Wallet, Blockchain.com, etc. These wallets generally use a single static ad= dress (because anything else confuses their users and they get additional s= upport tickets for it!) and put very little time into Bitcoin, focusing ins= tead on other tokens and integrations.

A few non-goals:

* To ensure that advanced setups have the absolute best in post-quantum sec= urity. I don't see how this moves the needle on the above goal, and in = fact in many cases detracts from the above goal. Of course if we can accomp= lish this without detracting from the top-line goal above, great.

* To ensure we have the best possible design for the signature scheme bitco= in will be using in a world where a CRQC exists and we've gotten past t= he mess. We'll almost certainly know a lot more about the security of v= arious schemes and have more options for how to approach the problem by the= point we're dealing with the mess of a CRQC being imminent, so it seem= s like a fools errand to try to predict what we should build for this. But = even if we know no more then than we do today, likely ending up with hash-b= ased signatures as the scheme everyone uses, we'll almost certainly be = having conversations about additional witness discounts or increased block = sizes to compensate for the sudden increase in transaction sizes. Maybe we = would decide against such an increase, but there's no question such a c= onversation would happen and it would be premature to have it today.

Matt

[1] Of course I believe that the lost coin pool is large enough that the Bi= tcoin community will, almost without question, fork to disable insecure spe= nd paths and burn some coins in the process, but reducing the number of coi= ns burned to the absolute minimum is of course best for everyone.

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/C= F7A554D-EE6F-4E6B-A670-1D6F72170539%40mattcorallo.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/CACja%3DNxfNT4dkS9F3L%3D9HKwxqLPJOJ6MJxfhWZrbkX-K-fuHhw%= 40mail.gmail.com.
--0000000000006d3ed3064f82ffae--