From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 07 Sep 2026 21:35:16 -0700 Received: from mail-oi1-f188.google.com ([209.85.167.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x3nYC-00008a-8K for bitcoindev@gnusha.org; Mon, 07 Sep 2026 21:35:16 -0700 Received: by mail-oi1-f188.google.com with SMTP id 5614622812f47-4b1bc2e44e0sf4965958b6e.0 for ; Mon, 07 Sep 2026 21:35:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1788842109; cv=pass; d=google.com; s=arc-20260327; b=UNC1EixjeP/SSRPrIlMfVS/TALkgI5uAPDifA/cgtp4vT8PXQ6NOkTXRs4r0OkYOsO cF0/sg3APfExOchCnNWLFnh1xE42GMHi/1JM4DNNg838xcEbljpVS93f8zFCPa1NzYsi 7FilRT7fWUDfD/uk70djjgxaeqxP+AMGfHj30ploWGiitedHz+fVbd/Lp/ZuUYbS8ZfC nxZ11dhA28aTBSEqaLY/gydDEluhxXC/mcugBcbjY5XucX+k1XlYr/HU5mGfYkxfLuI2 RBRwaKPQ1vz/zDmt+/Q61qvBMpj5BKagqkn2BUtHfmPf4jN0h1V6VaEH0w8eq6dTDMDp r2nA== 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:cc:to:from:references:in-reply-to :dkim-signature; bh=mw7FYnx/AMaqLt1DAGEUEQHEt9iny7khG7WaUFzFiHk=; fh=KSzy5NR5PDlbe1k/5+hBw0SfMdAn/UhuesZficjwiys=; b=B+WxmP6mvQuzUt7Eq669hkLGPvzOrOcG0u8PPFrxb0x9JQP9mbpj3p2O8VpSaaTc8B aMuZKj7mHOh20rKP8hX5dQ7daFgQXgDw11C62nymrV4lWAep0BLCq5mwWUr0Sa2Lo6+r x1C745x7npUE74uPCcnQuxv/j7eXMmskEyzNCdR5/uPqmDD4zejudkJy7YacsE/O2sJl vHoSYFKjBq91rIhoAXbmdMjnocikeuMo+4S6tmYaCludJY3KNiHuasocKRHeVmeobwSq RHetym8lMNQbBL6vqg9gwUsFK/3gPmMv6KydkDTO9hBef1uym4P5Jlfi3BQOG/n/mHn2 ldMA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@cipherscope.io header.s=resend header.b="ZbK/742n"; dkim=pass header.i=@amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b="tjB/4q+Z"; spf=pass (google.com: domain of 010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@send.cipherscope.io designates 54.240.9.156 as permitted sender) smtp.mailfrom=010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-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=1788842109; x=1789446909; 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:cc:to:from :references:in-reply-to:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mw7FYnx/AMaqLt1DAGEUEQHEt9iny7khG7WaUFzFiHk=; b=Ec1mvB7s4qSte/qCF7Cz3G1r7yr8wlyptcpgWEtBz9Thz2ZGdRMey96zNSPwT3V9/B 7vX0303fDxRZKN7qTbnzOidBYzTyJf2uEeIYXEycY9DTXeaDUsJfnbhooroJYM/J8kbM 1m2sS0+H2qTd+nXvOtU+4Q9F+hjD2TrYX11IJaSUAkXKXdZ+l4CcxEdVq5+K3JKQC6D6 8Zbf5NTQI42yTuReavOrU4hCt0hk+tBOqGjygsPBwD1+Cenf88Ru1KhVdrnEfQXvbaJo UjklmuPc9COjKOcHA+T/3VRa/J/RM0RuKUaOeT5kBeHlmrcDN8RTp9NGzJF/v1RjyBxS 1zGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788842109; x=1789446909; 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:cc:to:from :references:in-reply-to:x-beenthere:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=mw7FYnx/AMaqLt1DAGEUEQHEt9iny7khG7WaUFzFiHk=; b=r0o2eyw3uyt3iHHGjv0Ffi6kJ7QIPO7t/dWpeJlKhkocEK43oUjOY6fzUdBTjQB9WG r3vvQ+VJYQ9zZfSWe1/oCs46dlXL5jxPbuffK9LRHEXTzBGH7gQEgzsJKhq0uRzjM4cC H+8H8NuiKwWEpcSWo3SZ3SpNtZlLpmUPWaKoKP1RmaQJ5ve+trrLJIQq0T4qTzJsVNVk 2GkW7Q0edgEX7ZpVunJQSXrbzS58gtc8tXfCDvNPH9hzQbdIhY+ouEZ/cR3hFh87uSbE A+F9B0eUE2pjDEjDNS1dbkA5xkTcO8dlxglgfr35AiyaXXxfZk/bHcYdATWpcUyF2WrJ b1jQ== X-Forwarded-Encrypted: i=2; AKwUvBxanRZs7q9RTp0WYiTK39RNHnbAjc97rsRRr8kFENHqfVd0HL/7pRAlA+CAAeNtOjm+4HSnijUVUQga@gnusha.org X-Gm-Message-State: AFuF++m3QP3g+6HLkZrd1RoAwe4ANg4Dkn1B0kP6Iw0Ta7F1R6CoIpbH lASvn5oxObyC7ifB7K34hOnsWL0IrTjRk+vLFIWsURvwcmJsWVrq7DG3 X-Received: by 2002:a05:6808:159b:b0:497:da47:df5f with SMTP id 5614622812f47-4b9623ccb8emr24500011b6e.17.1788842109609; Mon, 07 Sep 2026 21:35:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddm8iwbaIETsKcuwPWuD6w0Ul/oDLEpIy/pxjzxebLOYQ==" Received: by 2002:a05:687c:419b:10b0:46f:65b1:7ea8 with SMTP id 586e51a60fabf-475354fd06als2482094fac.0.-pod-prod-01-us; Mon, 07 Sep 2026 21:35:04 -0700 (PDT) X-Received: by 2002:a05:6808:f8c:b0:4b3:8ec2:f25c with SMTP id 5614622812f47-4b96077ef26mr22753014b6e.9.1788842104163; Mon, 07 Sep 2026 21:35:04 -0700 (PDT) Received: by 2002:a05:6809:93:10b0:4b2:5fe6:230c with SMTP id 5614622812f47-4bbefe7b677msb6e; Mon, 7 Sep 2026 20:53:49 -0700 (PDT) X-Received: by 2002:a05:6a20:4393:b0:3d3:af66:9f61 with SMTP id adf61e73a8af0-3da3a16b389mr42943916637.27.1788839628298; Mon, 07 Sep 2026 20:53:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788839628; cv=none; d=google.com; s=arc-20260327; b=ULj92ZYxbcdQt2HzKvRbk5y7ixXiA4hS8wdrXWWi5pZ3UkBhkGM0czax1IKRpLZZDK tUpQl8hvCqhvkZrbFSKUcjNZnAnL+hqpjbM2tajx995V+XFT2ZpYYA2tYZI/R4KLPdtP eKSPLnirXAhti5dAI1FWCDIUvI7zBZoXcZgSXnxilodCQ86crgHpUgi+zhVP7Io06KyQ JIjQfnJBf9rIJG28GRfl9t/8s6KX6xnd4UhURIi7GehXYFRtJJZxsJcFxazfbycLj4Al FP1mAdBLjjeeeu3WkdjxB9zphFebu3pUnilZQn7Ldt5mtJBSmQHXf0t1RYkkyezXjDKI GabQ== 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:cc:to:from:references:in-reply-to:dkim-signature :dkim-signature; bh=/1oOEwCWXv+1uSvmQ8IDV9hnkw9XAPb3pB8qqQeXAmA=; fh=A/u2SrkpsTzFl11Fnb/8IRGsHaV4ahKBmbz4KJzfsd0=; b=NZpbNkJZCv/jtR3TMhGPfa9JIW7zGA/nHrSZ4Q27sUTl0SF10xgxcLge7MXOt48svO YoC7H2R30GwxxjYGS3uiwGPdbu4kh2LPvl4gcSxou6mvgLn71xWXUYOjwMJIfycUUsWy 7TCLwA+OWe50XsmZ0uaNYpPb18k8yYdJbVG0bLSgue777W1hWHFfWAJmiHfaPft8XRqi spxooLclAY4SGJ+7V3/EFvSnMW4h2NXyWW43/P2Y77Oq/R4WzlX35gXJas43YyEjBOko iMkDve+N6u0QtZIZ/69+RVjuYoJosk7Xi1LPI/7L/mK7dORVk1hN6gfloqwKVa4tKIAX vRXQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@cipherscope.io header.s=resend header.b="ZbK/742n"; dkim=pass header.i=@amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b="tjB/4q+Z"; spf=pass (google.com: domain of 010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@send.cipherscope.io designates 54.240.9.156 as permitted sender) smtp.mailfrom=010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@send.cipherscope.io; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cipherscope.io Received: from a9-156.smtp-out.amazonses.com (a9-156.smtp-out.amazonses.com. [54.240.9.156]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-cc45a6abb51si305772a12.2.2026.09.07.20.53.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 20:53:47 -0700 (PDT) Received-SPF: pass (google.com: domain of 010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@send.cipherscope.io designates 54.240.9.156 as permitted sender) client-ip=54.240.9.156; In-Reply-To: <9QUT0_vQUMszAr1ZQw9EsjX9S-gnVFJDD7g4eYgeovhYaOu84nmqJUs8vuDtaPSexGIKkiG3xNpo_jEnVMeJPSnxARXvcOah5jujNBBOdeU=@proton.me> References: <010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@email.amazonses.com> <9QUT0_vQUMszAr1ZQw9EsjX9S-gnVFJDD7g4eYgeovhYaOu84nmqJUs8vuDtaPSexGIKkiG3xNpo_jEnVMeJPSnxARXvcOah5jujNBBOdeU=@proton.me> From: "'duncan0k' via Bitcoin Development Mailing List" To: bitcoindev@googlegroups.com Cc: conduition@proton.me Subject: Re: [bitcoindev] Standardizing public key exposure classification for existing outputs Message-ID: <010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@email.amazonses.com> Date: Tue, 8 Sep 2026 03:53:47 +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.08-54.240.9.156 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="ZbK/742n"; dkim=pass header.i=@amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b="tjB/4q+Z"; spf=pass (google.com: domain of 010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000@send.cipherscope.io designates 54.240.9.156 as permitted sender) smtp.mailfrom=010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-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 conduition, Thanks for engaging with the substance despite your reservations. Answering the disclaimer straight first: > Disclaimer: I haven't read the draft BIP; it appears to be > AI-generated. Partially fair, so I'll be precise about it: I used an LLM to help draft the English text, and I won't pretend otherwise. What I'd push back on is the implication that the content is machine-generated. The classification was extracted from a scanner running in production against mainnet; the fail-closed rules each correspond to a failure mode we actually hit (truncated indexer history, the P2PK blind spot of address-indexed APIs); the v0.2.0 revisions came from review finding real holes. The test vectors are independently verifiable either way. If the prose style gets in the way of review, I'll rewrite it plainer -- the semantics are what I'm asking people to check. > My work on DropKick and Tadge Dryja's work on Lifeboat are both > contingent on this source of truth This is the kind of consumer I hoped existed. I'd like to understand what shape DropKick needs: per-output levels at a given height? A committed set? That determines whether script-level classification is sufficient or an outpoint-level profile is needed. > Would every full node go back and reindex the entire chain to > collect a list of exposed pubkeys/addresses? The draft deliberately stops at semantics -- what conclusion is sound given what data -- so it doesn't presuppose any index. The constant-time floor exists for implementations that only have aggregate spent-counts. A node-level exposure index (or the address-index drive-by) would be the natural next layer, and worth its own thread; the semantics shouldn't depend on it. > I would check out Project Eleven's dashboard I have -- the RISQ list is the closest prior art I know of. The gap it leaves is that a dashboard applies a methodology; it doesn't specify one that implementations can be checked against. Different tools citing 25%-34% is the symptom. > If you consider the internal key + MAST root to be a preimage, > then no: P2TR is actually usable without exposing that preimage I think we're answering two different questions, and the draft should name both. Mine: can a CRQC spend it under current consensus rules? For P2TR yes -- solving the dlog of Q yields a key-path spend; the attacker never needs P or the MAST root. Yours: does the holder retain a secret a CRQC lacks, usable under a future rescue encumbrance ("prove knowledge of the internal key")? For BIP341-conformant outputs yes -- and your own point that some outputs may be bare untweaked keys, indistinguishable on-chain, is exactly why any such rescue confiscates an unknown fraction, and why the draft classifies by attacker-spendability (observable) rather than rescue-provability (not). I'll add a note distinguishing the two, crediting this exchange. > I would say "unexposed" for this. The signer definitely knows > something (a script) that the CRQC doesn't. I believe we agree on substance and my naming misled you -- useful signal in itself. That case is EXPOSED_ON_SPEND in the draft, defined as "not disclosed; spending will necessarily publish key material" -- safe at rest, your reasoning exactly. NOT_EXPOSED is reserved for outputs whose spend reveals nothing reusable (P2MR script paths). If EXPOSED_ON_SPEND reads as "already exposed", the label is doing harm; EXPOSED_WHEN_SPENT may be better. Open to suggestions. > I strongly doubt we can do much about off-chain exposure. Agreed -- the draft scopes it out for that reason. The levels state what the chain shows, nothing more. I'll fold the P2TR note and the naming question into v0.3.0. 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/010001a07f268952-f2dff00c-20e0-4c9f-8a8b-344a35df0c6b-000000%40email.amazonses.com.