From a4e603f69cdef114f311780723852be0a876ebec Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 24 Apr 2026 10:14:23 -0500 Subject: [PATCH 1/5] Newsletters: add 403 (2026-05-01) --- .../en/newsletters/2026-05-01-newsletter.md | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 _posts/en/newsletters/2026-05-01-newsletter.md diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md new file mode 100644 index 000000000..9872b8ba3 --- /dev/null +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -0,0 +1,50 @@ +--- +title: 'Bitcoin Optech Newsletter #403' +permalink: /en/newsletters/2026/05/01/ +name: 2026-05-01-newsletter +slug: 2026-05-01-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter describes research around using binary fuse filters as an +alternative to the GCS used in compact block filters. Also included are our +regular sections summarizing proposals and discussion about changing Bitcoin's +consensus rules, announcing new releases and release candidates, and describing +notable changes to popular Bitcoin infrastructure software. + +## News + +FIXME:bitschmidty + +## Changing consensus + +_A monthly section summarizing proposals and discussion about changing +Bitcoin's consensus rules._ + +FIXME:bitschmidty + +## 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-05-05 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} From c74d98f39971579a557732a69d3590a8f8d93ca8 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Sun, 26 Apr 2026 09:00:09 -0700 Subject: [PATCH 2/5] News403: Add changing consensus --- .../en/newsletters/2026-05-01-newsletter.md | 85 ++++++++++++++++++- 1 file changed, 83 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md index 9872b8ba3..dc50c83ac 100644 --- a/_posts/en/newsletters/2026-05-01-newsletter.md +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -22,7 +22,82 @@ FIXME:bitschmidty _A monthly section summarizing proposals and discussion about changing Bitcoin's consensus rules._ -FIXME:bitschmidty +- **Post-quantum HD wallets with fallback SPHINCS keys:** In a + [post][c ml pq bip32] on the Bitcoin-Dev mailing list, Conduition described + a design for [post-quantum][topic quantum resistance] [BIP32][] congruent [hierarchical deterministic + wallets][topic bip32] with fallback [SPHINCS][news383 sphincs] keys. The design replaces + the child key derivation functions of BIP32 to generate SPHINCS keys + alongside [secp256k1][secp256k1] keys. Due to the lack of an algebraic + relationship within SPHINCS keys, non-hardened child keys share the same + SPHINCS keys as their parents and siblings. This requires wallets to insert + a nonce (or the secp256k1 key) into scripts spent using the SPHINCS key to + retain privacy equivalent to BIP32 wallets. A benefit of this design choice + is that the expensive full SPHINCS key derivation can be deferred to the + first non-hardened derivation step and then cached for all non-hardened keys + below that step. This wallet design is intended to be combined with + [BIP360][] P2MR outputs and a future `OP_CHECKSPHINCS` (or similar) to + enable migration to quantum-resistant wallets. Conduition suggests that such + a wallet structure might also be combined with future lower-cost + post-quantum signature algorithms with SPHINCS providing a dependable + fallback in case they are proven insecure. + +- **Discussion of a post-quantum output type**: Antoine Poinsot [wrote][ap ml pqout] to + the Bitcoin-Dev mailing list defending a plain post-quantum output type (as + opposed to a [P2TR][topic taproot]-like output type which allows + quantum-vulnerable key spending to be disabled by a later soft fork). The + crux of the argument is that the decision of whether or when it makes sense + to disable quantum-vulnerable spends should be separated from enabling users + to migrate to post-quantum cryptography at their discretion. In the + subsequent conversation, the participants agreed on both adding + post-quantum signing to [tapscript][topic tapscript] and adding a plain post-quantum output + type. Several open questions remain, including whether and to what degree to + incentivize migration and when / whether to disable quantum-vulnerable + signatures. + +- **Proposal to embed post-quantum keys in tapscript without consensus changes**: Daniel + Buchner [sent][db ml minpqc] a proposal to the Bitcoin-Dev mailing list + which describes a potential path to enabling flexible post-quantum wallet + designs without fully describing the signature validation parameters. + Because [BIP342][] signature checking opcodes treat all non-32-byte keys as + unknown key types which are valid with any non-empty signature, other key + lengths (in this case with an initial tag byte) can be used in scripts today + as long as either the scripts are kept secret or they also require a secure + [BIP340][] signature in addition to the unknown key or keys. If Buchner's + proposal were to be standardized, wallets could start building scripts with + various post-quantum key types now while continuing to spend using + quantum-vulnerable keys until such time as a soft fork enables secure + spending with the post-quantum keys. Like many quantum migration proposals, + this proposal only retains security in the face of a quantum adversary if + key reuse is strictly prevented. Buchner is seeking feedback on the + proposal. + +- **BIP54 demonstration of slow blocks on signet**: On Delving Bitcoin, + Antoine Poinsot [wrote][ap delving slowblocks] about a demonstration of the + types of slow-to-validate blocks that [BIP54][] + ([consensus cleanup][topic consensus cleanup]) prevents. Repeated three times over the course of a + day, batches of slow-to-validate blocks were signed on the most popular + Bitcoin [signet][topic signet] and then reorged away to enable testing of + propagation and validation behavior of these blocks without forever slowing + signet initial block download. Many around the world watched the slow blocks + hit their nodes and logged the validation and propagation behavior. As + expected, the slow-to-validate blocks propagated much more slowly through + the network and required significantly more time to be fully validated on + individual nodes compared to typical blocks. It should be noted that these + demonstration blocks were far from the worst case that is prevented by + BIP54. + +- **Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds**: + Olaoluwa Osuntokun (roasbeef) [posted][oo ml pqrecovery] on the Bitcoin-Dev + mailing list his project to demonstrate zk-STARK recovery of + quantum-vulnerable coins secured by keys derived using [BIP32][]. This + possible mechanism for coin recovery in the event that + [secp256k1][secp256k1] is disabled in the face of a cryptographically + relevant quantum computer has long been discussed, but never fully + demonstrated. Osuntokun produced a fully working implementation of the + required prover and verifier and provided benchmarks showing that recovery + using this method is, at least, possible. The original implementation was + intentionally not optimized and several developers offered optimizations + that make the recovery less costly both to prove and to verify. ## Releases and release candidates @@ -47,4 +122,10 @@ FIXME:Gustavojfe {% include snippets/recap-ad.md when="2026-05-05 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +[c ml pq bip32]: https://groups.google.com/g/bitcoindev/c/5tLKm8RsrZ0 +[news383 sphincs]: /en/newsletters/2025/12/05/#slh-dsa-sphincs-post-quantum-signature-optimizations +[secp256k1]: https://en.bitcoin.it/wiki/Secp256k1 +[ap ml pqout]: https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg +[db ml minpqc]: https://groups.google.com/g/bitcoindev/c/jn7COyeHtW0 +[ap delving slowblocks]: https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367 +[oo ml pqrecovery]: https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI From 87afc528f7c623bb84499bb2ffea6256797234a5 Mon Sep 17 00:00:00 2001 From: TumaBitcoiner <119351965+TumaBitcoiner@users.noreply.github.com> Date: Wed, 29 Apr 2026 17:39:05 +0200 Subject: [PATCH 3/5] News403: add binary fuse filters news item --- .../en/newsletters/2026-05-01-newsletter.md | 28 ++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md index dc50c83ac..c75e379c2 100644 --- a/_posts/en/newsletters/2026-05-01-newsletter.md +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -15,7 +15,31 @@ notable changes to popular Bitcoin infrastructure software. ## News -FIXME:bitschmidty +- **Binary fuse filters as an alternative to BIP158's GCS**: Csaba Purszki + [posted][bin fuse del] to Delving Bitcoin his research on finding a better alternative + to Golomb-Rice Coded Sets (GCS) used for [compact block filters][topic compact block filters] + as defined in [BIP158][]. + + According to Purszki, a suitable alternative can be found in binary fuse + filters, a family of probabilistic data structures for approximate set + membership, and specifically the 16-bit variant, called Fuse16. The main + characteristic of this type of algorithm is the ability to give O(1) query + time (for reference, GCS gives O(N)), which reduces the CPU power required to + query the filters. Moreover, these filters guarantee zero false negatives, + with a rate of false positives equal to `1/2^k`, with `k` being the number of + bits. + + Purszki provided the preliminary results of his research, which compare the current GCS + performance against binary fuse filters. Tests were performed on 10 different wallet + use cases (from 24 scripts up to 480), running filters on 50,000 mainnet blocks, + on two different CPUs, a desktop x86_64, and an ARM. Binary fuse filters were able to + obtain a 6x-45x speedup on ARM, according to the different wallet use cases, and 9x-80x + on desktop at the cost of a slight increase in bandwidth, 0%-3%. For a full write up on + the methodology and full results, the reader can refer to [Purszki's website][bin fuse web]. + + Kyoto developer Robert Netzke commented on the differences in false positive + rates with respect to GCS and possible failures that could occur in the + algorithm. ## Changing consensus @@ -129,3 +153,5 @@ FIXME:Gustavojfe [db ml minpqc]: https://groups.google.com/g/bitcoindev/c/jn7COyeHtW0 [ap delving slowblocks]: https://delvingbitcoin.org/t/consensus-cleanup-demo-of-slow-blocks-on-signet/2367 [oo ml pqrecovery]: https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI +[bin fuse del]: https://delvingbitcoin.org/t/binary-fuse-filters-as-an-alternative-to-bip-158-gcs/2428 +[bin fuse web]: https://purszki.github.io/bitcoin_research_01/ From 75f17e9ad5d4389cab4564c2e258a21418943f6a Mon Sep 17 00:00:00 2001 From: Gustavo Flores Date: Thu, 30 Apr 2026 00:50:06 -0600 Subject: [PATCH 4/5] News403: add merge summaries and releases --- _includes/references.md | 5 ++ .../en/newsletters/2026-05-01-newsletter.md | 83 ++++++++++++++++++- 2 files changed, 86 insertions(+), 2 deletions(-) diff --git a/_includes/references.md b/_includes/references.md index 808da15cb..947a1ff95 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -196,6 +196,7 @@ for details --> {% endcomment %} [BIP373]: https://github.com/bitcoin/bips/blob/master/bip-0373.mediawiki [BIP374]: https://github.com/bitcoin/bips/blob/master/bip-0374.mediawiki [BIP375]: https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki +[BIP376]: https://github.com/bitcoin/bips/blob/master/bip-0376.mediawiki [BIP379]: https://github.com/bitcoin/bips/blob/master/bip-0379.md [BIP380]: https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki [BIP381]: https://github.com/bitcoin/bips/blob/master/bip-0381.mediawiki @@ -208,10 +209,14 @@ for details --> {% endcomment %} [BIP388]: https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki [BIP389]: https://github.com/bitcoin/bips/blob/master/bip-0389.mediawiki [BIP390]: https://github.com/bitcoin/bips/blob/master/bip-0390.mediawiki +[BIP391]: https://github.com/bitcoin/bips/blob/master/bip-0391.mediawiki [BIP392]: https://github.com/bitcoin/bips/blob/master/bip-0392.mediawiki +[BIP393]: https://github.com/bitcoin/bips/blob/master/bip-0393.mediawiki [BIP431]: https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki [BIP434]: https://github.com/bitcoin/bips/blob/master/bip-0434.md [BIP433]: https://github.com/bitcoin/bips/blob/master/bip-0433.mediawiki +[BIP440]: https://github.com/bitcoin/bips/blob/master/bip-0440.mediawiki +[BIP441]: https://github.com/bitcoin/bips/blob/master/bip-0441.mediawiki [BIP442]: https://github.com/bitcoin/bips/blob/master/bip-0442.md [BIP443]: https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki [BIP446]: https://github.com/bitcoin/bips/blob/master/bip-0446.md diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md index c75e379c2..185d6eb78 100644 --- a/_posts/en/newsletters/2026-05-01-newsletter.md +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -129,7 +129,19 @@ _New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates._ -FIXME:Gustavojfe +- [Core Lightning 26.04.1][] is a maintenance release that includes + [gossip][topic channel announcements] protocol fixes, as well as build system + fixes for environments that experienced problems immediately after the major + release. + +- [BTCPay Server 2.3.8][] is a minor release of this self-hosted payment + solution that includes subscription and point-of-sale updates, LUD21 [LNURL-pay][topic + lnurl] support, an additional API surface for managing subscription offerings, + and other fixes and improvements. + +- [BTCPay Server 2.3.9][] is a maintenance release that addresses server + recovery after a plugin crash and fixes an xpub parsing issue that was + introduced in v2.3.8. ## Notable code and documentation changes @@ -142,10 +154,67 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -FIXME:Gustavojfe +- [Bitcoin Core #33671][] adds a `nonmempool` field to the `getbalances` RPC + (see [Newsletter #46][news46 getbalances]) for wallet UTXOs spent by + transactions that are neither confirmed nor in the node’s mempool, such as + unbroadcasted, non-standard, evicted, or transactions that are part of + too-long mempool chains. Previously, balance buckets could omit value tied + to those in-flight spends even though the wallet still recorded the + transactions, so `getbalances` did not fully reflect how the wallet was + accounting for those coins. The PR counts that value in the usual `mine` + buckets where it belongs and applies an offset via `nonmempool` so the + fields sum to the wallet’s overall balance while making the mempool mismatch + explicit. + +- [Bitcoin Core #34885][] adds `btck_block_tree_entry_get_ancestor()` to the + `libbitcoinkernel` C API (see [Newsletter #380][news380 kernel]) for + retrieving the ancestor of a block at a specified height on its chain branch. + Instead of walking backward one block at a time with repeated calls to + `btck_block_tree_entry_get_previous()`, callers constructing block locators + from a stale or forked tip can directly request ancestors at the needed + heights. + +- [Bitcoin Core #33920][] adds an `exportasmap` RPC that exports the node’s + ASMap data embedded at build time (see [Newsletter #394][news394 asmap]) to a + file. This allows users to inspect, validate, and analyze the data using tools + such as `contrib/asmap-tool.py`. + +- [Bitcoin Core #34911][] removes deprecated [RBF][topic rbf]-related boolean + fields from several mempool RPC responses unless they are explicitly requested + using the `deprecatedrpc` configuration option. The `getmempoolinfo` RPC no + longer returns the `fullrbf` field by default, as full-RBF behavior has been + the default since Bitcoin Core 28.0 and the `mempoolfullrbf` option was + removed in Bitcoin Core 29.0. The `getrawmempool`, `getmempoolentry`, + `getmempoolancestors`, and `getmempooldescendants` RPCs no longer return the + deprecated `bip125-replaceable` field described in [BIP125][] by default. + +- [BIPs #1548][] adds [BIP391][], a specification for Binary Output Descriptors + (BOD), an efficient container format for [output script descriptors][topic + descriptors] based on [PSBT][topic psbt]-style key-value maps. This BIP has a + closed status and lists [BIP393][] as a proposed replacement, noting that + [BIP391][] was withdrawn after [BIP393][] proposed an alternative method for + handling wallet metadata such as descriptor annotations (see [Newsletter + #400][news400 bip393]). + +- [HWI #831][] adds support for the Ledger Nano Gen5 hardware signing device. + +- [BDK #2188][] starts verifying that a transaction returned by an Electrum + server matches the requested txid before caching or using it. Previously, a + server could respond to a `fetch_tx()` request with any transaction data and a + different txid, and BDK would accept it. + +- [BDK #2115][] adds previous-block-hash awareness to `CheckPoint` by extending + the `ToBlockHash` trait with an optional `prev_blockhash()` method. This + allows BDK to verify that adjacent checkpoints connect when their payloads + contain previous-block-hash information, such as in block headers. This also + prevents `merge_chains()` from treating a conflicting height-0 checkpoint as a + normal reorg and replacing it. Now, if two checkpoint chains disagree on + genesis, the merge fails. See Newsletters [#372][news372 checkpoint] and + [#390][news390 checkpoint] for previous work on `CheckPoint`. {% include snippets/recap-ad.md when="2026-05-05 16:30" %} {% include references.md %} +{% include linkers/issues.md v=2 issues="33671,34885,33920,34911,831,2188,2115,1548" %} [c ml pq bip32]: https://groups.google.com/g/bitcoindev/c/5tLKm8RsrZ0 [news383 sphincs]: /en/newsletters/2025/12/05/#slh-dsa-sphincs-post-quantum-signature-optimizations [secp256k1]: https://en.bitcoin.it/wiki/Secp256k1 @@ -155,3 +224,13 @@ FIXME:Gustavojfe [oo ml pqrecovery]: https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI [bin fuse del]: https://delvingbitcoin.org/t/binary-fuse-filters-as-an-alternative-to-bip-158-gcs/2428 [bin fuse web]: https://purszki.github.io/bitcoin_research_01/ +[BTCPay Server 2.3.8]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.3.8 +[BTCPay Server 2.3.9]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.3.9 +[Core Lightning 26.04.1]: https://github.com/ElementsProject/lightning/releases/tag/v26.04.1 +[LUD-21]: https://github.com/lnurl/luds/blob/luds/21.md +[news372 checkpoint]: /en/newsletters/2025/09/19/#bdk-1582 +[news380 kernel]: /en/newsletters/2025/11/14/#bitcoin-core-30595 +[news390 checkpoint]: /en/newsletters/2026/01/30/#bdk-2037 +[news394 asmap]: /en/newsletters/2026/02/27/#bitcoin-core-28792 +[news400 bip393]: /en/newsletters/2026/04/10/#bips-2099 +[news46 getbalances]: /en/newsletters/2019/05/14/#bitcoin-core-15930 From 96d5d488d02a25388cdad81faf5ac2711bb8c763 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 1 May 2026 07:23:22 -0500 Subject: [PATCH 5/5] News403: add topics --- _topics/en/compact-block-filters.md | 3 +++ _topics/en/consensus-cleanup-soft-fork.md | 3 +++ _topics/en/hd-key-generation.md | 6 ++++++ _topics/en/hwi.md | 3 +++ _topics/en/output-script-descriptors.md | 6 ++++++ _topics/en/quantum-resistance.md | 12 ++++++++++++ _topics/en/replace-by-fee.md | 3 +++ _topics/en/signet.md | 3 +++ _topics/en/tapscript.md | 3 +++ 9 files changed, 42 insertions(+) diff --git a/_topics/en/compact-block-filters.md b/_topics/en/compact-block-filters.md index 02bab1220..e717e1fa1 100644 --- a/_topics/en/compact-block-filters.md +++ b/_topics/en/compact-block-filters.md @@ -92,6 +92,9 @@ optech_mentions: - title: "LND v0.17.0-beta released with improved compact block filter speed through batched downloading" url: /en/newsletters/2023/10/04/#lnd-v0-17-0-beta + - title: "Binary fuse filters as an alternative to BIP158's GCS" + url: /en/newsletters/2026/05/01/#binary-fuse-filters-as-an-alternative-to-bip158-s-gcs + ## Optional. Same format as "primary_sources" above see_also: - title: BIP37 transaction bloom filtering diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index c9a275d56..623d7dbb3 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -89,6 +89,9 @@ optech_mentions: - title: "Bitcoin Inquisition adds an implementation of the BIP54 consensus cleanup soft fork rules" url: /en/newsletters/2026/02/13/#bitcoin-inquisition-99 + - title: "BIP54 demonstration of slow blocks on signet" + url: /en/newsletters/2026/05/01/#bip54-demonstration-of-slow-blocks-on-signet + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/hd-key-generation.md b/_topics/en/hd-key-generation.md index 587d8c5f9..471db1f8d 100644 --- a/_topics/en/hd-key-generation.md +++ b/_topics/en/hd-key-generation.md @@ -96,6 +96,12 @@ optech_mentions: - title: "Chain code withholding to improve privacy when using co-signer services" url: /en/newsletters/2025/07/25/#chain-code-withholding-for-multisig-scripts + - title: "Post-quantum HD wallets with fallback SPHINCS keys" + url: /en/newsletters/2026/05/01/#post-quantum-hd-wallets-with-fallback-sphincs-keys + + - title: "Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds" + url: /en/newsletters/2026/05/01/#post-quantum-bip86-recovery-using-zk-stark-proofs-of-bip32-seeds + ## Optional. Same format as "primary_sources" above see_also: - title: Output script descriptors diff --git a/_topics/en/hwi.md b/_topics/en/hwi.md index 48efcab5c..5534ef158 100644 --- a/_topics/en/hwi.md +++ b/_topics/en/hwi.md @@ -70,6 +70,9 @@ optech_mentions: - title: "Sparrow 2.1.0 begins using Lark as an alternative to HWI" url: /en/newsletters/2025/02/21/#sparrow-2-1-0-released + - title: "HWI #831 adds support for the Ledger Nano Gen5 hardware signing device" + url: /en/newsletters/2026/05/01/#hwi-831 + ## Optional. Same format as "primary_sources" above see_also: - title: Partially-Signed Bitcoin Transactions (PSBTs) diff --git a/_topics/en/output-script-descriptors.md b/_topics/en/output-script-descriptors.md index 814dde6fc..78f197478 100644 --- a/_topics/en/output-script-descriptors.md +++ b/_topics/en/output-script-descriptors.md @@ -215,6 +215,12 @@ optech_mentions: - title: "BIPs #2047 publishes BIP392, defining a descriptor format for silent payments" url: /en/newsletters/2026/03/13/#bips-2047 + - title: "BIPs #2099 publishes BIP393, an optional annotation syntax for output script descriptors" + url: /en/newsletters/2026/04/10/#bips-2099 + + - title: "BIPs #1548 adds BIP391, a closed specification for Binary Output Descriptors superseded by BIP393" + url: /en/newsletters/2026/05/01/#bips-1548 + ## Optional. Same format as "primary_sources" above see_also: - title: Miniscript diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index 8b49ee250..a49b6f0c5 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -127,6 +127,18 @@ optech_mentions: - title: "BIPs #1895 publishes BIP361, a post-quantum migration and legacy signature deprecation proposal" url: /en/newsletters/2026/04/24/#bips-1895 + - title: "Post-quantum HD wallets with fallback SPHINCS keys" + url: /en/newsletters/2026/05/01/#post-quantum-hd-wallets-with-fallback-sphincs-keys + + - title: "Discussion of a post-quantum output type" + url: /en/newsletters/2026/05/01/#discussion-of-a-post-quantum-output-type + + - 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 + + - title: "Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds" + url: /en/newsletters/2026/05/01/#post-quantum-bip86-recovery-using-zk-stark-proofs-of-bip32-seeds + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot diff --git a/_topics/en/replace-by-fee.md b/_topics/en/replace-by-fee.md index da67f6d58..cf6a39d89 100644 --- a/_topics/en/replace-by-fee.md +++ b/_topics/en/replace-by-fee.md @@ -210,6 +210,9 @@ optech_mentions: - title: "LDK #4427 adds RBF of negotiated splice funding transactions that are not yet locked" url: /en/newsletters/2026/03/20/#ldk-4427 + - title: "Bitcoin Core #34911 removes deprecated RBF-related boolean fields from mempool RPCs" + url: /en/newsletters/2026/05/01/#bitcoin-core-34911 + ## Optional. Same format as "primary_sources" above see_also: - title: Transaction pinning diff --git a/_topics/en/signet.md b/_topics/en/signet.md index 3505616f1..f51199fc2 100644 --- a/_topics/en/signet.md +++ b/_topics/en/signet.md @@ -126,6 +126,9 @@ optech_mentions: - title: "Post and website examining soft fork testing on the default signet" url: /en/newsletters/2024/11/22/#signet-activity-report + - title: "BIP54 demonstration of slow blocks on signet" + url: /en/newsletters/2026/05/01/#bip54-demonstration-of-slow-blocks-on-signet + ## Optional. Same format as "primary_sources" above see_also: - title: "Bitcoin Core #16411: signet support" diff --git a/_topics/en/tapscript.md b/_topics/en/tapscript.md index 619afb123..6315e7353 100644 --- a/_topics/en/tapscript.md +++ b/_topics/en/tapscript.md @@ -88,6 +88,9 @@ 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: "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 + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot