From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 04 Sep 2026 12:25:38 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x2ZXd-0007r8-IZ for bitcoindev@gnusha.org; Fri, 04 Sep 2026 12:25:38 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-458326d2d9asf2107158fac.2 for ; Fri, 04 Sep 2026 12:25:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1788549931; cv=pass; d=google.com; s=arc-20260327; b=BaWo78r3llBWe4Qkf6HQQaxIY4eZz6ozY8n8bClrNuaV6CfBWklyFe4cCmAB4dOe0W TSXbD76rnyoaAHPR9NkAqnjdvlQksS/d/g2k/JhAB3Wo2xzELmhoI8+V2C1kZ1hbkk5/ iM39aIhav5kY5c6mxDzmFCfdq9hepG8WCUReYhVHTgsAkSHYx6PJVdBETBHnBw6HKUC9 IsF/LVm5RaGv9xnFMUDF78f/sp9cjbVQcvYgoenM4De1mHvz+C57VdIKrM8eiR/iZdxm KMlZPDAGU7RKGCJmqz9x8wYe+ZS6riZJ/rc8i5lZZ3OCmMFbZNHXd5eqZoOzv6fYt802 tkVQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:feedback-id:mime-version :date:message-id:subject:to:from:dkim-signature; bh=3oY0QK6YxTUJKY1ZXumMtoEqRMdcDjr4XkswzmpluuI=; fh=5C+WIpRMC40o3tDbDziMx0kzHrv9keKuE7szHCiEMcI=; b=TJm1ZZFNG+WR6qGL2r6b864/DtC/rRUMcteFksxpG3GlOBF6mmzbrE/rXaDu4n9x3U ZFJZMeBlu/oIwSYXcXbyCt5TOvcM5tTGdppAuBXPH+SeohiPJmw011rH/SL47KZOseZE uW/fq8LJMkMrpEYU2AifIMkHOVO6LiEIQGnVxUmrAWFrqofWGaYirxDCfmEbewUpY2NT L/UaDoj/n8NzUwpJCX08TUx/J0aN0L/vCr42zy5YnnTXdUDG/iRKKCHFaoDdeQgymmF3 R30RuPwssCgl81LZCwwoRcexSwNJdf8nb7n3Q0bWiK9/l0ZmT0WkyQURigR60N9p8+Ku a1Vg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@cipherscope.io header.s=resend header.b=FbXKtPYI; dkim=pass header.i=@amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=ry4UvqSF; spf=pass (google.com: domain of 010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io designates 54.240.14.56 as permitted sender) smtp.mailfrom=010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cipherscope.io DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1788549931; x=1789154731; 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:feedback-id :content-type:mime-version:date:message-id:subject:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=3oY0QK6YxTUJKY1ZXumMtoEqRMdcDjr4XkswzmpluuI=; b=TLTRD1+WiN7WWLPGzOFVkDqOMbE9U6j63GtwhI/kwWtFy1mhTnVk1FNeWJ5z2M0h5k s7bbfr7q9Amdp2rUMxETOXEsZqPUj9ygXFU2r57XhdJUZZ85xiIwvdxWi5AqKZSHKaLA igGo++TurR7sXGV8Sjisbnx0KifP06Hxyh0ZJwGrg68Qids3Wc5TY2FLC6CCpV6PX/SY 5KvrY2WT4OxZZqLQ7jQ0Uz5mYb4jgjB+D/yD3McGwU+vAzeBtEBZkoNTSFRdAW2WAUIA UkVdV8EBl2v4K1+NwrJVyN1Yu6hC5e2VboNr6yvZLX45jefJiTq0wk/mM8P0/ZjVKh9F nIOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788549931; x=1789154731; 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:feedback-id :content-type:mime-version:date:message-id:subject:to:from :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=3oY0QK6YxTUJKY1ZXumMtoEqRMdcDjr4XkswzmpluuI=; b=M7WPrULk5p/RKHLbwdJYa9GBva6KHNU5NLxJ9iqaeOyBYOBSKBNJ8Koa+BTcShKkYk P1d6tx6kJEjbHbdhw7Z0t1WbFIQyoMbb+9YopSGtxt1Am1XV2fzSQPhL1Uzkmn1rLjMG cV8Zx4pAk6ybwnHnjRx2cb+sGXqjSttDO64badaDYWfpJZCgctAJ7W3O+HVdytF3cLww zVssAKybhUOkjLDtvjZddjMc6pGblBKkPAH0lRzfMG782iz7wQSQCre+Imlux6udRhMR gDlYyukDnORnHrDLUKxW5MJ2dIdhgYJ7/HOPJl+EyFrbWn8lqs0EMeDmHHjQxEeAQ0na gcvA== X-Forwarded-Encrypted: i=2; AKwUvBzQnNzzFPPcSXTF6X2pm8pZKxVYu/V90516d8myV9+dOmdIKtp+rPTV2JgOq2/BsfFPioajTqCnC3KH@gnusha.org X-Gm-Message-State: AFuF++mrAsxsQTW5dmwIYJams14ti8QdWxgu7oFYHFvFD+RHEHM8Yais bclql6jdZVF45eQR7f7pWQ9iifLxXPIf//CvhSY4KD8wYkBVqK7CSOu/ X-Received: by 2002:a05:6870:7083:b0:475:e2e9:4f47 with SMTP id 586e51a60fabf-475e2e9535emr3543205fac.21.1788549931219; Fri, 04 Sep 2026 12:25:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddO+nTTcpaQYFtle5i0pjdTFDfrH2P5egOmUg3tpYeKbg==" Received: by 2002:a05:687c:34a:10b0:45e:cf1f:ee1 with SMTP id 586e51a60fabf-47538d7e2bdls1505619fac.1.-pod-prod-07-us; Fri, 04 Sep 2026 12:25:26 -0700 (PDT) X-Received: by 2002:a05:6808:1907:b0:4b3:77da:2b9c with SMTP id 5614622812f47-4b961a7ba19mr7036765b6e.12.1788549926016; Fri, 04 Sep 2026 12:25:26 -0700 (PDT) Received: by 2002:a05:6808:1599:b0:4ab:3e9a:a867 with SMTP id 5614622812f47-4b89d8748b8msb6e; Fri, 4 Sep 2026 12:11:00 -0700 (PDT) X-Received: by 2002:a17:902:f092:b0:2d8:df44:a5c2 with SMTP id d9443c01a7336-2db126afe54mr86339505ad.20.1788549059189; Fri, 04 Sep 2026 12:10:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788549059; cv=none; d=google.com; s=arc-20260327; b=Y4wjLBXgrZ73+/RHPqlP/Rlq+3O/3YzNLNhd9rlexD5P4631gOTMdfxbHeZ5Yd/19H hmTjfWhzNTpW9enmo1ITWS+s9ZJOZ3aADdXvaBW9yX1ZUt4Q7vUukzufPNTIsXF9z3J8 UgvhBl86CZuPmSb4iWcyhOiz/cz0+60pcdeRS2kBcNSKq/UJLXIfTsXNn/NPhgd9a7wT L/M4hHecct0FzQCR69nqTvzeUW7LRwy1Pa5lcnd1PpeGrt1UOZqKxbnw7MbxtC/WW80K kWN5eQyqtxHRCLQe/GAaqxaOlXC1KywMUZFG2pXbuArrKIUtfaD+bK0LSm8vInrKO/LD DRtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=feedback-id:mime-version:date:content-transfer-encoding:message-id :subject:to:from:dkim-signature:dkim-signature; bh=TT3Cp9P8zG+QyyqipdPiZyThJUO3t1P/C8v76HqOsjI=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=g0GvTMgk6RNM4qfd630cPQhN5xg5cNRN7X5zlZYBCPLzoO6I8wEHhbeynNEuQTl1T/ QU73KTjz+miy9VACtqZChkTVHwEW6L+A+J1yJjT1B1iSp2EnCko3Uwimj9reNw4JETZ3 ny70dkLCxTmnUZsZHmD+6F+q2bdpRtF6NPp5t4I3x6jWpOtTgVHF1D0U8qIPMQsQPuWA r51+lUMEltE9dobaXNC/163caqHIoKMTKI2m8FlvOrV7Zjm0dy8+fal//3/7k+nnhaml FZxU1E+bo7z9V9Tb8gWX2fuFhqRqDJKZSZEksVklGv8HI7G0ChswLVpTVzAoNL1Iv6J4 7+OQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@cipherscope.io header.s=resend header.b=FbXKtPYI; dkim=pass header.i=@amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=ry4UvqSF; spf=pass (google.com: domain of 010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io designates 54.240.14.56 as permitted sender) smtp.mailfrom=010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cipherscope.io Received: from a14-56.smtp-out.amazonses.com (a14-56.smtp-out.amazonses.com. [54.240.14.56]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2db14942428si1016785ad.7.2026.09.04.12.10.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 12:10:59 -0700 (PDT) Received-SPF: pass (google.com: domain of 010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io designates 54.240.14.56 as permitted sender) client-ip=54.240.14.56; From: "'duncan0k' via Bitcoin Development Mailing List" To: bitcoindev@googlegroups.com Subject: [bitcoindev] Standardizing public key exposure classification for existing outputs Message-ID: <010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@email.amazonses.com> Date: Fri, 4 Sep 2026 19:10:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Feedback-ID: :1.us-east-1.uYze2bwK3SHKKircWy/itkS3vRiPQKZLrl6+y7WCGuRPsvW9ql8MorhNCUOEXf2PGCXNSg8zb4wXghGsSzasI0jj39JRaHKfNZGZIx1mhBBywFYJj0UYJyJnxeFR8KB0PocMWVVGOZzOXWt7Tivy/pn7sTtrfNSfjeDxZfpLwxQ=:1.us-east-1.QSNtDRXSTq9sAuvRl56h5mypgasnQ5yDLNpVzTnziu0=:AmazonSES X-SES-Outgoing: 2026.09.04-54.240.14.56 X-Original-Sender: duncan0k@cipherscope.io X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@cipherscope.io header.s=resend header.b=FbXKtPYI; dkim=pass header.i=@amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=ry4UvqSF; spf=pass (google.com: domain of 010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io designates 54.240.14.56 as permitted sender) smtp.mailfrom=010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@send.cipherscope.io; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cipherscope.io X-Original-From: duncan0k Reply-To: duncan0k 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 (-) Hi all, I would like to gauge interest in a specification that defines how to classify an existing Bitcoin output by whether the public key needed to spend it has already been published on-chain. The gap: BIP 360 gives us an output type whose key stays off-chain until a script-path spend, and BIP 361 proposes a phased sunset of legacy signature verification. Both assume the ecosystem can answer "which existing outputs are exposed?" -- but no BIP specifies how that question is answered. Why this is a practical problem: published estimates of the exposed supply currently range from roughly 25% to over 34%. As far as I can tell the spread is definitional, not measurement error. Recurring disagreements: - Is a P2TR output exposed at rest? Its 32-byte output key is a public key, and solving its discrete log yields a working key-path spend regardless of how the internal key was chosen -- a NUMS internal key does not help, since consensus never checks how Q was constructed. - Is a spent-from P2PKH address that still holds a balance "exposed at rest" or "exposed on spend"? To an adversary these are the same situation, but tools label them differently. - What should a classifier report for a P2SH/P2WSH output whose script has never been revealed? - What about keys disclosed off-chain -- xpubs handed to service providers, or spends of the corresponding output on a 2017 fork? If BIP 361 or something like it advances, "is this output legacy-vulnerable" becomes a question asked at scale by wallets, explorers and custodians, with money attached. Users consulting two tools should not get two answers about the same coins. What the draft does: it specifies four levels -- EXPOSED_AT_REST, EXPOSED_ON_SPEND, NOT_EXPOSED, UNDETERMINED -- a per-output-type assignment table, and a fail-closed rule: where data is insufficient to distinguish two levels, the more-exposed level must be assigned. Two points I would particularly like feedback on: 1. Disclosure mechanism does not change the level. A reused, spent-from script that retains a balance is EXPOSED_AT_REST, the same as P2PK. I think separating these invites the reading that reused addresses are safer than P2PK, which is false. Some existing tools (including an earlier iteration of my own) do separate them. 2. UNDETERMINED is mandatory for unrecognized output types, rather than defaulting them to unexposed. Any classifier predating a future output type will encounter outputs it cannot reason about, and reporting those as safe asserts a property it has not established. The draft also specifies a constant-time floor: if a script's confirmed spent-output count is greater than zero, a spend has occurred, and for every type except P2MR that publishes the material the script commits to. This is what prevents a truncated history scan from producing a false NOT_EXPOSED -- without it, every implementation independently decides what to report when it runs out of scan budget, and the divergence reappears at the engineering layer. (The one over-approximation -- a revealed script that requires no signature -- errs in the conservative direction, which the fail-closed rule permits; see the v0.2.0 changelog.) Explicitly out of scope: risk scoring. Turning exposure into a number requires weighing balance, dormancy and CRQC timelines, none of which are observable on-chain and all of which are contested. The draft stops at the observable so that the numbers people compute on top of it are at least computed over the same facts. Draft, reference implementation and test vectors: https://github.com/duncan0k/pubkey-exposure-classification I posted this to Delving Bitcoin a couple of days ago and am cross-posting here for wider review: https://delvingbitcoin.org/t/standardizing-an-exposure-classification-for-existing-outputs-pre-bip/2866 Before I invest further: is this something the list considers worth specifying, or is it better left to each implementation? I am also interested in whether anyone has prior art I have missed -- I could not find a canonical definition, but this is the kind of thing that gets rediscovered. duncan0k -- 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/010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000%40email.amazonses.com.