From 6cdb124d6f6808db61318ff5cf704ff8ed33e595 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 | 46 +++++++++++++++++++ 1 file changed, 46 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..1dd7b6137 --- /dev/null +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -0,0 +1,46 @@ +--- +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 +--- +FIXME:bitschmidty + +## 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 6b732375f3013e09dafc59fa551fa1b22f2936c7 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, 85 insertions(+) diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md index 1dd7b6137..520c127a0 100644 --- a/_posts/en/newsletters/2026-05-01-newsletter.md +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -20,6 +20,83 @@ 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 [BIP32][] congruent hierarchical deterministic + wallets 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. + +- **In defense of a PQ 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, some agreement was reached on both adding + post-quantum signing to 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 for minimum viable PQC protection without a fork**: 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. + +- **Consensus Cleanup: demo 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 part of [BIP54][] + ([consensus cleanup][topic consensus cleanup]) prevents. Over nearly a full + day, 3 batches of slow to validated 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 BIP-86 Recovery via zk-STARK Proof of BIP-32 Seed Knowledge**: + Olauluwa Osuntokun (roasbeef) [posted][oo ml pqrecovery] on the Bitcoin-Dev + mailing list his project to demonstrate [zk-STARK][zc 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 showed 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 _New releases and release candidates for popular Bitcoin infrastructure @@ -44,3 +121,11 @@ 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 +[zc zk stark]: https://z.cash/learn/what-are-zk-snarks/ From 4b102489cbe8de457cd581e868ab3ed06c928016 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] Added binary fuse filters news item. --- .../en/newsletters/2026-05-01-newsletter.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md index 520c127a0..be59968d4 100644 --- a/_posts/en/newsletters/2026-05-01-newsletter.md +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -11,6 +11,32 @@ FIXME:bitschmidty ## News +- **Binary Fuse filters as an alternative to BIP 158 GCS**: Csaba Purszki + [posted][bin fuse del] to Delving Bitcoin about the research he made for + Chaincode Lab BOSS challenge 2026, which focused on finding a better alternative + to Golomb-Rice Coded Sets (GCS) used for [compact block filter][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 characteristics of this type of algorithm is the + ability to give `O(1)` query time (for reference, GCS gives `O(N)`), which grants a + strong reduction in the CPU power required to query the filters. Moreover, these filters + guarantee zero false negatives, whith 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 + performances 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 case, and 9x-80x + on desktop at the cost of a slight increase in bandwith, 0%-3%. For a full write up on + the methodology and full result, the reader can refer to [Purszki's website][bin fuse web]. + + Purszki's research received a first feedback from Kyoto developer Robert Netzke, + who provided comments on the differences in false positive rates with respect + to GCS and possible failures that could occur in the algorithm. + FIXME:bitschmidty ## Changing consensus @@ -129,3 +155,5 @@ FIXME:Gustavojfe [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 [zc zk stark]: https://z.cash/learn/what-are-zk-snarks/ +[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 059bfc1579e6de541d7eec1d365b2244b4e9e82d Mon Sep 17 00:00:00 2001 From: Gustavo Flores Date: Thu, 30 Apr 2026 00:50:06 -0600 Subject: [PATCH 4/5] add merge summaries and releases --- _includes/references.md | 5 ++ .../en/newsletters/2026-05-01-newsletter.md | 84 ++++++++++++++++++- 2 files changed, 86 insertions(+), 3 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 be59968d4..a279136ff 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 PoS updates, LUD-21 [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,11 +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. + +- [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`. + +- [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 + #394][news394 bip393]). {% include snippets/recap-ad.md when="2026-05-05 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +{% 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 @@ -157,3 +225,13 @@ FIXME:Gustavojfe [zc zk stark]: https://z.cash/learn/what-are-zk-snarks/ [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 +[news394 bip393]: /en/newsletters/2026/03/06/#bips-2099 +[news46 getbalances]: /en/newsletters/2019/05/14/#bitcoin-core-15930 From 6dcfdfcfaa581013e49344fe6d433ebee37a8d1b Mon Sep 17 00:00:00 2001 From: Gustavo Flores Date: Thu, 30 Apr 2026 19:01:46 -0600 Subject: [PATCH 5/5] reorder bip item --- _posts/en/newsletters/2026-05-01-newsletter.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_posts/en/newsletters/2026-05-01-newsletter.md b/_posts/en/newsletters/2026-05-01-newsletter.md index a279136ff..90a9447cc 100644 --- a/_posts/en/newsletters/2026-05-01-newsletter.md +++ b/_posts/en/newsletters/2026-05-01-newsletter.md @@ -188,6 +188,14 @@ repo], and [BINANAs][binana repo]._ `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 + #394][news394 bip393]). + - [HWI #831][] adds support for the Ledger Nano Gen5 hardware signing device. - [BDK #2188][] starts verifying that a transaction returned by an Electrum @@ -204,14 +212,6 @@ repo], and [BINANAs][binana repo]._ genesis, the merge fails. See Newsletters [#372][news372 checkpoint] and [#390][news390 checkpoint] for previous work on `CheckPoint`. -- [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 - #394][news394 bip393]). - {% 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" %}