diff --git a/_posts/en/newsletters/2026-07-03-newsletter.md b/_posts/en/newsletters/2026-07-03-newsletter.md new file mode 100644 index 000000000..85bf4866c --- /dev/null +++ b/_posts/en/newsletters/2026-07-03-newsletter.md @@ -0,0 +1,214 @@ +--- +title: 'Bitcoin Optech Newsletter #412' +permalink: /en/newsletters/2026/07/03/ +name: 2026-07-03-newsletter +slug: 2026-07-03-newsletter +type: newsletter +layout: newsletter +lang: en +--- +FIXME:bitschmidty + +## News + +FIXME:bitschmidty + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +FIXME:bitschmidty + +- **Benchmarking SLH-DSA STARK aggregation**: Remix7531 [posted][rs ml starkbench] + to the Bitcoin-Dev mailing list his benchmark results for aggregating many + [SPHINCS][news383 sphincs] signature verifications into a single + [STARK][news403 stark] proof. This follows Ethan Heilman's earlier + [proposal][eh ml starkagg] to use STARKs to scale [post-quantum][topic + quantum resistance] blocks. In this benchmark suite (built in RISK Zero's + zkVM), proving time scales roughly linearly with the number of signatures + (~3.1 seconds per signature on an RTX 5090), proof size grows sublinearly + (218 KiB for one signature up to 454 KiB for 512 signatures, versus 3.8 MiB + of raw signatures), and verification stays near 12-15 milliseconds + regardless of batch size. Proving an entire block on one GPU would still + take hours, but Remix suggests that dedicated AIR circuits, mempool + preprocessing, and multi-GPU proving could improve this. The benchmarks also + use standard SPHINCS rather than the more compact Bitcoin-optimized + [SPHINCS+][news386 jn hash] variant. + +- **Bird of Prey 2 (BoP-2): non-malleable Schnorr + PQ signatures**: Pieter + Wuille [posted][pw delving bop2] to Delving Bitcoin about a EuroCrypt 2026 + paper on constructing hybrid strongly-unforgeable signature schemes from a + [Schnorr][topic schnorr signatures]-like scheme and an arbitrary + [post-quantum][topic quantum resistance] signature scheme. While simply + concatenating signatures from both schemes is unforgeable if at least one + remains secure, it is not strongly unforgeable: if either scheme breaks, an + attacker can replace that scheme's partial signature while the signature as + a whole remains valid. The paper's BoP-2 construction avoids this by having + the Schnorr signature commit to the post-quantum signature in its challenge + hash. + + Adam Gibson and Conduition discussed whether strong unforgeability still + matters post-[segwit][topic segwit], since witnesses no longer affect + txids. Wuille explained that the concern is a quantum or classical break + allowing anyone to malleate the broken scheme's signature component. + Conduition compared the construction to Boris Nagaev's space-saving hybrid + hash-based design (see the lattice signatures item below) and concluded + BoP-2 looks like the stronger unified-hybrid contender, though Wuille and + Conduition both questioned whether unified hybrid schemes are worth the + complexity when separate [BIP360][] (P2MR[news393 p2mr]) leaves, or simple + script combinations can achieve similar results. + +- **Post-quantum: lattice-based signatures**: Nikita Karetnikov + [posted][nk delving lattice] to Delving Bitcoin and + [cross-posted][nk ml lattice] to the Bitcoin-Dev mailing list about a + Blockstream [blog post][bs blog lattice] comparing post-quantum signature + families, where lattice-based schemes appear favorable on size and + functionality. He inquired as to why Bitcoin post-quantum work has focused + on hash-based signatures instead. + + Conduition [replied][c ml lattice] that hash-based signatures remain + attractive for Bitcoin because of weaker security assumptions, + implementation simplicity, fast verification, and suitability as a long-term + fallback. Mikhail Kudinov noted that while naïvely, lattice-based signatures + often require floating point computations, Falcon's floating-point + operations can be simulated with integers. Conduition and Jesse Posner + discussed whether unified hybrid Schnorr+lattice schemes are necessary + versus achieving similar security with separate [BIP360][] (P2MR) leaves. On + the other hand, Boris Nagaev described space savings from treating hybrid + signing as a single construction rather than a simple concatenation of + multiple signature schemes - schemes could likely share certain required + randomizing parameters, for example. + +- **Public key recovery for EC leaves in P2MR (BIP360)**: starius + [posted][st delving recover] to Delving Bitcoin a proposal to add a + recoverable elliptic curve (EC) key leaf type to [BIP360][] (P2MR). The idea + is to recover the EC public key from the [Schnorr][topic schnorr signatures] + signature. The public key is committed to in P2MR Merkle tree instead of a + script, and the Schnorr signature challenge is modified to include the + Merkle root and control block instead of the public key itself. Because both + the Merkle root and control block are known both at signing and verification + time, the signature can be verified without foreknowledge of the public key, + and then the public key's inclusion in the Merkle root can be verified via + the control block. Using this technique, a depth-1 Schnorr leaf witness + shrinks from 135 bytes to 100 bytes, between the size of a [P2TR][topic + taproot] key spend and a [P2WPKH][topic segwit] spend, at the cost of giving + up BIP340 batch verification. starius and Conduition explained that + including the control block in the challenge prevents a related-key attack + when multiple such leaves share a tree. Pieter Wuille reviewed the + construction favorably. Anthony Towns, Pieter Wuille, and Conduition + discussed implications for [BIP32][topic bip32] derivation, + batch-verification discounts, and the interaction with Conduition's + depth-zero tree ban (depth-zero recoverable leaves could match [P2TR][topic + taproot] witness sizes without a post-quantum fallback). starius explained + that this should be folded into BIP360 before activation because it changes + witness parsing rules. + +- **Aligning privacy incentives in P2MR**: Conduition [posted][c ml p2mrdepth] + to the Bitcoin-Dev mailing list a proposed [BIP360][] (P2MR) change to + require every P2MR control block to include at least one 32-byte Merkle + authentication path (i.e. ban depth-zero script trees). Depth-zero trees + make some protocols requiring only a single script path more efficient in + P2MR than [P2TR][topic taproot], creating a perverse incentive to skip + cooperative signing paths and making some contract protocols easier to + fingerprint on chain. + + Antoine Poinsot agreed this would address that privacy concern but still + prefers [P2TRv2][news403 pqout] for mass migration because typical + single-key P2MR spends cost roughly 15% more than P2TRv2 (possibly less with + key recovery discussed above). Pieter Wuille argued that pre-quantum + adoption incentives matter more than long-term post-quantum efficiency and + that P2TRv2 better minimizes migration costs, he also noted that P2MR only + even makes sense if users can rely on a future soft fork disabling elliptic + curve paths within P2MR. Conduition predicted similarly low voluntary + migration rates for either design and noted an upcoming witness-size + optimization for common elliptic curve spends (see the next item). Hayashi + [suggested][h ml p2mrdepth] an additional witness discount on P2MR Schnorr + leaves to further close the cost gap. + +- **Prohibit Merkle internal node preimages that encode minimal 64-byte transactions**: + Jeremy Rubin [posted][jr ml merkle64] to the Bitcoin-Dev mailing list a + draft BIP proposing an alternative to the [consensus cleanup][topic + consensus cleanup] ([BIP54][]) rule making 64-byte witness-stripped + transactions consensus-invalid. Instead of banning the transactions + themselves, Rubin's rule would invalidate any block whose transaction Merkle + tree contains an internal node preimage with the byte layout of a minimal + one-input, one-output, witness-stripped transaction. This targets the same + [merkle tree vulnerability][topic merkle tree vulnerabilities] at the + internal-node boundary while preserving potentially useful 64-byte + transactions (see [Newsletter #408][news408 64byte]). SPV verifiers would + need to reject proofs whose branch preimages match the forbidden pattern. + The draft includes miner recovery guidance (reorder or drop offending + transactions) and notes that accidental violations should be rare. + +- **Giving teeth to expected EC disabling: P2XX(-T)(-ML)**: Pieter Wuille + [wrote][pw ml p2xx] to the Bitcoin-Dev mailing list about codifying the + expected future disabling of elliptic curve (EC) spending paths within new + [post-quantum][topic quantum resistance] output types such as [BIP360][] + (P2MR) and [P2TRv2][news403 pqout]. Without consensus-enforced triggers, + users won't be confident that EC spending will actually be disabled, + undermining the quantum-resistance story for output types that initially + allow cheap EC spends. + + Wuille proposed two mechanisms bundled with the introducing soft fork: + **tripwire** (P2XX-T), which disables EC paths in the new output type after + any successful ` OP_CHECKSIG` spend proves secp256k1 is broken, + putting a non-confiscatory upper bound on EC availability; and **miner + lockdown** (P2XX-ML), which lets a hashrate majority activate the same + disabling through a separately signaled soft fork with a very long + activation window. Boris Nagaev supported tripwire but raised false-positive + concerns for miner lockdown after large classical thefts. Sjors Provoost + suggested long delays and user migration back to [P2TR][topic taproot] as a + remedy. Conduition supported tripwire, noted that the proof need not be + mined on-chain, and warned that early miner lockdown could be + fee-incentivized. Wuille clarified that disabling must cover all EC usage + within the output type (not just key paths) and that hybrid signing should + use dedicated opcodes rather than arbitrary script combinations to ensure + spendability post-EC disabling. + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +FIXME:Gustavojfe + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +FIXME:Gustavojfe + +{% include snippets/recap-ad.md when="2026-07-07 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} + +[rs ml starkbench]: https://groups.google.com/g/bitcoindev/c/0IdqdnlC4Og +[eh ml starkagg]: https://groups.google.com/g/bitcoindev/c/wKizvPUfO7w +[pw delving bop2]: https://delvingbitcoin.org/t/bird-of-prey-2-non-malleable-schnorr-pq-signatures/2514 +[c ml p2mrdepth]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA +[h ml p2mrdepth]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/T7UWqgnvAAAJ +[st delving recover]: https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603 +[jr delving cr]: https://delvingbitcoin.org/t/commit-reveal-for-pq-migration/2419 +[nk ml lattice]: https://groups.google.com/g/bitcoindev/c/nMO4hyEm5qc +[nk delving lattice]: https://delvingbitcoin.org/t/pqc-lattice-based-signatures/2522 +[c ml lattice]: https://groups.google.com/g/bitcoindev/c/nMO4hyEm5qc/m/WE-R3z85AAAJ +[bs blog lattice]: https://blog.blockstream.com/schnorr-but-with-vectors-lattice-based-signatures-explained/ +[jr ml merkle64]: https://groups.google.com/g/bitcoindev/c/ZVDEzxG6Sq8 +[pw ml p2xx]: https://groups.google.com/g/bitcoindev/c/aWYtPLVPZ3U +[pacts]: https://www.paradigm.xyz/2026/05/pacts-protecting-your-bitcoin-from-a-quantum-sunset +[news383 sphincs]: /en/newsletters/2025/12/05/#slh-dsa-sphincs-post-quantum-signature-optimizations +[news386 jn hash]: /en/newsletters/2026/01/02/#hash-based-signatures-for-bitcoin-s-post-quantum-future +[news393 p2mr]: /en/newsletters/2026/02/20/#bips-1670 +[news403 pqout]: /en/newsletters/2026/05/01/#discussion-of-a-post-quantum-output-type +[news403 stark]: /en/newsletters/2026/05/01/#post-quantum-bip86-recovery-using-zk-stark-proofs-of-bip32-seeds +[news408 64byte]: /en/newsletters/2026/06/05/#bip54-64-byte-transactions-and-potential-legitimate-uses +[news361 pqcr]: /en/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index 56b55e5d8..85c8ea69a 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -98,6 +98,9 @@ optech_mentions: - title: "Draft BIP for testnet5 would activate BIP54 from block 1" url: /en/newsletters/2026/06/12/#draft-bip-for-testnet5 + - title: "Prohibit Merkle internal node preimages that encode minimal 64-byte transactions" + url: /en/newsletters/2026/07/03/#prohibit-merkle-internal-node-preimages-that-encode-minimal-64-byte-transactions + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/cross-input-signature-aggregation.md b/_topics/en/cross-input-signature-aggregation.md index ea07e6f42..5e75f676a 100644 --- a/_topics/en/cross-input-signature-aggregation.md +++ b/_topics/en/cross-input-signature-aggregation.md @@ -42,6 +42,9 @@ optech_mentions: - title: "DahLIAS interactive aggregate signatures for secp256k1" url: /en/newsletters/2025/04/25/#interactive-aggregate-signatures-compatible-with-secp256k1 + - title: "Post-quantum signature aggregation" + url: /en/newsletters/2025/11/07/#post-quantum-signature-aggregation + ## Optional. Same format as "primary_sources" above see_also: - title: Schnorr signatures diff --git a/_topics/en/merkle-tree-vulnerabilities.md b/_topics/en/merkle-tree-vulnerabilities.md index fef84808b..28f0c9e8f 100644 --- a/_topics/en/merkle-tree-vulnerabilities.md +++ b/_topics/en/merkle-tree-vulnerabilities.md @@ -62,6 +62,12 @@ optech_mentions: - title: "Question about whether 64-byte transactions can be third-party malleated to change their size" url: /en/newsletters/2025/03/28/#can-all-consensus-valid-64-byte-transactions-be-third-party-malleated-to-change-their-size + - title: "BIP54 64-byte transactions and potential legitimate uses" + url: /en/newsletters/2026/06/05/#bip54-64-byte-transactions-and-potential-legitimate-uses + + - title: "Prohibit Merkle internal node preimages that encode minimal 64-byte transactions" + url: /en/newsletters/2026/07/03/#prohibit-merkle-internal-node-preimages-that-encode-minimal-64-byte-transactions + ## Optional. Same format as "primary_sources" above see_also: - title: CVEs diff --git a/_topics/en/op_checksigfromstack.md b/_topics/en/op_checksigfromstack.md index bc6d96f96..d6ddba775 100644 --- a/_topics/en/op_checksigfromstack.md +++ b/_topics/en/op_checksigfromstack.md @@ -94,6 +94,9 @@ optech_mentions: - title: "Why doesn't CSFS bind signatures to specific inputs?" url: /en/newsletters/2026/03/27/#does-op-checksigfromstack-intentionally-allow-cross-utxo-signature-reuse + - title: "LNHANCE soft fork" + url: /en/newsletters/2025/12/05/#lnhance-soft-fork + ## Optional. Same format as "primary_sources" above see_also: - title: Covenants in Elements Alpha diff --git a/_topics/en/op_checktemplateverify.md b/_topics/en/op_checktemplateverify.md index 03ac2f265..db2616560 100644 --- a/_topics/en/op_checktemplateverify.md +++ b/_topics/en/op_checktemplateverify.md @@ -175,9 +175,15 @@ optech_mentions: - title: "`OP_TEMPLATEHASH` proposal as an alternative to CTV" url: /en/newsletters/2025/08/01/#taproot-native-op-templatehash-proposal + - title: "LNHANCE soft fork" + url: /en/newsletters/2025/12/05/#lnhance-soft-fork + - title: "Understanding and mitigating a CTV footgun" url: /en/newsletters/2026/01/02/#understanding-and-mitigating-a-ctv-footgun + - title: "CTV activation meeting" + url: /en/newsletters/2026/01/02/#ctv-activation-meeting + - title: "CTV-only vault proof of concept" url: /en/newsletters/2026/06/05/#ctv-only-vault-proof-of-concept diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index 0645d0d28..d28e2d319 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -151,6 +151,18 @@ optech_mentions: - title: "BIPs #2198 makes one-path P2MR outputs unsafe to discourage omitting a post-quantum fallback leaf" url: /en/newsletters/2026/06/26/#bips-2198 + - title: "Benchmarking SLH-DSA STARK aggregation" + url: /en/newsletters/2026/07/03/#benchmarking-slh-dsa-stark-aggregation + + - title: "Bird of Prey 2 (BoP-2): non-malleable Schnorr + PQ signatures" + url: /en/newsletters/2026/07/03/#bird-of-prey-2-bop-2-non-malleable-schnorr-pq-signatures + + - title: "Post-quantum: lattice-based signatures" + url: /en/newsletters/2026/07/03/#post-quantum-lattice-based-signatures + + - title: "Giving teeth to expected EC disabling: P2XX(-T)(-ML)" + url: /en/newsletters/2026/07/03/#giving-teeth-to-expected-ec-disabling-p2xx-t-ml + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/schnorr-signatures.md b/_topics/en/schnorr-signatures.md index bb61a4849..63375c110 100644 --- a/_topics/en/schnorr-signatures.md +++ b/_topics/en/schnorr-signatures.md @@ -122,6 +122,9 @@ optech_mentions: - title: "Explanation for why BIP340 uses secp256k1 instead of a different curve" url: /en/newsletters/2024/03/27/#why-does-bip-340-use-secp256k1 + - title: "Public key recovery for EC leaves in P2MR (BIP360)" + url: /en/newsletters/2026/07/03/#public-key-recovery-for-ec-leaves-in-p2mr-bip360 + ## Optional. Same format as "primary_sources" above see_also: - title: Will a schnorr soft fork introduce a new address format? diff --git a/_topics/en/simplicity.md b/_topics/en/simplicity.md index 94b5284cd..48e2d0c00 100644 --- a/_topics/en/simplicity.md +++ b/_topics/en/simplicity.md @@ -54,6 +54,9 @@ optech_mentions: - title: "SimplicityHL released to allow compiling Rust-like programs to Simplicity script" url: /en/newsletters/2025/08/22/#simplicityhl-released + - title: "Details about the design of Simplicity" + url: /en/newsletters/2025/09/05/#details-about-the-design-of-simplicity + ## Optional. Same format as "primary_sources" above see_also: - title: "Simplicity: A New Language for Blockchains" diff --git a/_topics/en/tapscript.md b/_topics/en/tapscript.md index 6315e7353..09453a2c7 100644 --- a/_topics/en/tapscript.md +++ b/_topics/en/tapscript.md @@ -88,6 +88,24 @@ optech_mentions: - title: "Research showing effect of OP_SUCCESSx on covenants using output script introspection" url: /en/newsletters/2023/10/25/#op-success-changes-would-be-beneficial + - title: "Draft BIP for adding elliptic curve operations to tapscript" + url: /en/newsletters/2025/09/05/#draft-bip-for-adding-elliptic-curve-operations-to-tapscript + + - title: "Draft BIP for OP_TWEAKADD" + url: /en/newsletters/2025/09/05/#draft-bip-for-op-tweakadd + + - title: "Draft BIPs for Script Restoration" + url: /en/newsletters/2025/10/03/#draft-bips-for-script-restoration + + - title: "Native STARK proof verification in Bitcoin Script" + url: /en/newsletters/2025/11/07/#native-stark-proof-verification-in-bitcoin-script + + - title: "Benchmarking the varops budget" + url: /en/newsletters/2025/12/05/#benchmarking-the-varops-budget + + - title: "Varops budget and tapscript leaf 0xc2 (aka Script Restoration) are BIPs 440 and 441" + url: /en/newsletters/2026/04/03/#varops-budget-and-tapscript-leaf-0xc2-aka-script-restoration-are-bips-440-and-441 + - title: "Proposal to embed post-quantum keys in tapscript without consensus changes" url: /en/newsletters/2026/05/01/#proposal-to-embed-post-quantum-keys-in-tapscript-without-consensus-changes