From 1ef1958f3389d504a89b7f8fbb333261f2f3133a Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 3 Feb 2026 09:48:33 +0000 Subject: [PATCH 1/6] Newsletters: add 391 (2026-02-06) --- .../en/newsletters/2026-02-06-newsletter.md | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 _posts/en/newsletters/2026-02-06-newsletter.md diff --git a/_posts/en/newsletters/2026-02-06-newsletter.md b/_posts/en/newsletters/2026-02-06-newsletter.md new file mode 100644 index 000000000..588d55d10 --- /dev/null +++ b/_posts/en/newsletters/2026-02-06-newsletter.md @@ -0,0 +1,51 @@ +--- +title: 'Bitcoin Optech Newsletter #391' +permalink: /en/newsletters/2026/02/06/ +name: 2026-02-06-newsletter +slug: 2026-02-06-newsletter +type: newsletter +layout: newsletter +lang: en +--- +This week's newsletter links to work on a constant-time parallelized UTXO +database, summarizes a new high-level language for writing Bitcoin Script, and +describes an idea to mitigate dust attacks. Also included are our regular +sections summarizing 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:reardencode + +## 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-02-10 17:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} \ No newline at end of file From 2fdd3bfc893b6098f687305c91e9156ff8979757 Mon Sep 17 00:00:00 2001 From: TumaBitcoiner Date: Wed, 4 Feb 2026 12:41:27 +0100 Subject: [PATCH 2/6] News391: add hornet news --- .../en/newsletters/2026-02-06-newsletter.md | 33 +++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2026-02-06-newsletter.md b/_posts/en/newsletters/2026-02-06-newsletter.md index 588d55d10..411adae1a 100644 --- a/_posts/en/newsletters/2026-02-06-newsletter.md +++ b/_posts/en/newsletters/2026-02-06-newsletter.md @@ -16,7 +16,32 @@ to popular Bitcoin infrastructure software. ## News -FIXME:bitschmidty +- **A constant-time parallelized UTXO database**: Toby Sharp + [posted][hornet del] to Delving Bitcoin about his latest project, a custom, highly + parallel UTXO database, with constant-time queries, called Hornet UTXO(1). + This is a new additional component of [Hornet Node][hornet website], an + experimental Bitcoin client focused on providing a minimal executable + specification of Bitcoin's consensus rules. + This new database aims to improve Initial Block Download (IBD) through a lock-free, + highly concurrent architecture. + + The code is written in modern C++23, without external dependencies. To optimize for + speed, sorted arrays and [LSM trees][lsmt wiki] were preferred over + [hash maps][hash map wiki]. + Operations, such as append, query, and fetch, are executed concurrently, and + blocks are processed out of order as they arrive, with data dependencies resolved + automatically. The code is not yet publicly available. + + Sharp provided a benchmark to assess the capabilities of his software. + For re-validating the whole mainnet chain, Bitcoin Core v30 took 167 minutes + (with no script or signature validation), while Hornet UTXO(1) took 15 minutes + to complete validation. Tests were performed on a 32-core computer, + with 128GB RAM and 1TB storage. + + In the discussion that followed, other developers suggested Sharp to compare + performance against [libbitcoin][libbitcoin gh], which is known for providing a + very efficient IBD. + ## Changing consensus @@ -48,4 +73,8 @@ FIXME:Gustavojfe {% include snippets/recap-ad.md when="2026-02-10 17:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} \ No newline at end of file +[hornet del]: https://delvingbitcoin.org/t/hornet-utxo-1-a-custom-constant-time-highly-parallel-utxo-database/2201 +[hornet website]: https://hornetnode.org/overview.html +[lsmt wiki]: https://en.wikipedia.org/wiki/Log-structured_merge-tree +[hash map wiki]: https://en.wikipedia.org/wiki/Hash_table +[libbitcoin gh]: https://github.com/libbitcoin From 6563bff96cbe1837ccb852c73d9ec1b300e2e0c0 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Wed, 4 Feb 2026 17:19:06 -0800 Subject: [PATCH 3/6] News391: add changing consensus and bithoven items --- .../en/newsletters/2026-02-06-newsletter.md | 85 ++++++++++++++++++- 1 file changed, 84 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2026-02-06-newsletter.md b/_posts/en/newsletters/2026-02-06-newsletter.md index 411adae1a..3ef4f2824 100644 --- a/_posts/en/newsletters/2026-02-06-newsletter.md +++ b/_posts/en/newsletters/2026-02-06-newsletter.md @@ -42,13 +42,89 @@ to popular Bitcoin infrastructure software. performance against [libbitcoin][libbitcoin gh], which is known for providing a very efficient IBD. +- **Bithoven: A formally verified, imperative language for Bitcoin Script:** + Hyunhum Cho [wrote][delving hc bithoven] on Delving Bitcoin about his + [work][arxiv hc bithoven] on Bithoven which is an alternative to + [miniscript][topic miniscript]. In contrast to miniscript's predicate + language for expressing the possible satisfactions for a locking script, + Bithoven uses a more familiar C-family syntax with `if`, `else`, `verify`, + and `return` as its primary operations. The compiler handles all stack + management and makes similar guarantees to the miniscript compiler regarding + all paths requiring at least one signature and similar. Similar to + miniscript, it can target various Script versions. ## Changing consensus _A monthly section summarizing proposals and discussion about changing Bitcoin's consensus rules._ -FIXME:reardencode +- **SHRINCS: 324-byte stateful post-quantum signatures with static backups:** + Following-up on the [Hash-based Signature Schemes for Bitcoin][news386 jn + hash], Jonas Nick [detailed][delving jn shrings] on Delving Bitcoin a + specific hash-based [quantum-resistant][topic quantum resistance] signature algorithm with potentially useful properties for use in + Bitcoin. + + In the paper, there was discussion of the trade-offs between + stateful and stateless hash-based signatures, where stateful signatures can + have significantly reduced cost at the expense of complex backup schemes. + SHRINCS offers a compromise where a stateful signature is used when the + fidelity of the key+state can be known with certainty, but falls back to + stateless signing at higher cost if there is doubt that the state is valid. + + The two schemes chosen for SHRINCS are SPHINCS+ for stateless signing and + Unbalanced XMSS for stateful signing. The public key posted in the output + script is a hash of the stateful and stateless keys. Because these + hash-based signature schemes return the signing public key as part of + verification, the signer provides the unused public key along with their + signature and the verifier checks that the returned public key hashes with + the provided public key to the key specified in the locking script. The + Unbalanced XMSS scheme is chosen to optimize for cases where relatively few + signatures are needed from a key. + +- **Addressing remaining points on BIP54:** Antoine Poinsot [wrote][ml ap + gcc] about the remaining points of discussion for the [consensus + cleanup soft fork][topic consensus cleanup]. + + First up for discussion is the proposal to enforce that the coinbase + transaction's `nLockTime` be set to one less than the block height. Here the + discussion centers around whether this change unnecessarily restricts mining + chips' ability to use this field as an extra nonce as future miners run out + of nonce space in the existing version, timestamp, and nonce fields. Several + posters mentioned that the `nLockTime` field already has consensus enforced + semantics and is therefore not a prime candidate for additional nonce + rolling. Various proposals for alternate nonce space were made, including + additional version bits and a separate `OP_RETURN` output. + + The other change discussed is the proposal to make 64-non-witness-byte + transactions invalid in consensus. Such transactions are also restricted + by default relay policy, but a consensus change would protect SPV (or other + similar) light clients from certain attacks. Several posters questioned + whether this change is even worthwhile, given that other mitigations exist, + and it introduces a potentially surprising validity gap for certain types of + transactions (e.g. [CPFPs][topic cpfp] for certain protocols). + +- **Falcon post-quantum signature scheme proposal:** Giulio Golinelli + [posted][ml gg falcon] on the mailing list proposing a fork to enable Falcon + signature verification to Bitcoin. The Falcon algorithm is based on lattice + cryptography and is seeking FIPS standardization as a post-quantum signature + algorithm. It requires about 20x more space on chain than ECDSA signatures while being + about twice as fast to verify. This makes it one of the smallest + post-quantum signature schemes so far proposed for Bitcoin. + + Conduition posted some limitations of the Falcon algorithm, especially + around the difficulty of implementing signing in constant time. Others + discussed the question of whether a post-quantum signature algorithm for + Bitcoin should be designed with future STARK/SNARK-friendliness in mind. + + Note: While the mailing list post describes it as a soft fork, it appears to + be implemented as a flag-day disjunction in the P2WPKH verification path + which would be a hard fork. Further work would be necessary to develop a + soft fork client for this algorithm. + +- **SLH-DSA verification can compete with ECC:** Conduition [wrote][ml cond + slh-dsa] about his ongoing work benchmarking his post-quantum SLH-DSA + verification implementation against libsecp256k1. His results show that + SLH-DSA verification can compete with [schnorr][topic schnorr signatures] verification in common cases. ## Releases and release candidates @@ -73,6 +149,13 @@ FIXME:Gustavojfe {% include snippets/recap-ad.md when="2026-02-10 17:30" %} {% include references.md %} +[news386 jn hash]: /en/newsletters/2026/01/02/#hash-based-signatures-for-bitcoin-s-post-quantum-future +[delving jn shrings]: https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158 +[ml ap gcc]: https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg +[delving hc bithoven]: https://delvingbitcoin.org/t/bithoven-a-formally-verified-imperative-smart-contract-language-for-bitcoin/2189 +[arxiv hc bithoven]: https://arxiv.org/abs/2601.01436 +[ml gg falcon]: https://groups.google.com/g/bitcoindev/c/PsClmK4Em1E +[ml cond slh-dsa]: https://groups.google.com/g/bitcoindev/c/8UFkEvfyLwE [hornet del]: https://delvingbitcoin.org/t/hornet-utxo-1-a-custom-constant-time-highly-parallel-utxo-database/2201 [hornet website]: https://hornetnode.org/overview.html [lsmt wiki]: https://en.wikipedia.org/wiki/Log-structured_merge-tree From d54bcf69f2d1c5a9a00b8f8cc6a72793d4fd911d Mon Sep 17 00:00:00 2001 From: kevkevinpal Date: Wed, 4 Feb 2026 21:08:37 -0500 Subject: [PATCH 4/6] News391: add disposing of dust attack news --- .../en/newsletters/2026-02-06-newsletter.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/_posts/en/newsletters/2026-02-06-newsletter.md b/_posts/en/newsletters/2026-02-06-newsletter.md index 3ef4f2824..ad804a8fd 100644 --- a/_posts/en/newsletters/2026-02-06-newsletter.md +++ b/_posts/en/newsletters/2026-02-06-newsletter.md @@ -53,6 +53,41 @@ to popular Bitcoin infrastructure software. all paths requiring at least one signature and similar. Similar to miniscript, it can target various Script versions. +- **Discussion of dust attack mitigations**: Bubb1es [posted][dust attacks del] + to Delving Bitcoin about a way to dispose of [dust + attacks][topic output linking] in onchain wallets. A dust attack happens when + an adversary sends dust UTXO's to all the anonymous addresses they want to + know about. Hoping that some will be spent unintentionally with an unrelated + UTXO. + + The way _most_ wallets choose to handle this today is by preventing spending of the dust + UTXOs by marking them as dust UTXOs in the wallets client. This can become an + issue in the future if the user restores from keys and the new wallet client + doesn't know these UTXOs are marked and "unlocks" the dust UTXOs to be spent. + Bubb1es suggests another way to prevent this dust UTXO attack by + creating a transaction with the dust UTXO that uses the entire amount and has + an `OP_RETURN` output making it provably unspendable. This is possible because + Bitcoin Core v30.0 has a lower minimum relay fee rate (0.1 sats/vbyte). + + He then lists out a few risks with implementing a wallet that handles dust + UTXOs like this. + + 1. Fingerprinting issues if only a few wallets implement this. + + 2. If multiple dust UTXOs are broadcast at the same time, then there can be + correlation. + + 3. Rebroadcasting might need to be done if fee rates go up. + + 4. It can be confusing to sign for dust UTXOs in multi-sig and hardware + signing setups. + + AJ Towns mentioned that the minimum relay size is 65 bytes and explains that + using ANYONECANPAY|ALL with a 3-byte OP_RETURN would make it more efficient. + + Bubb1es then provides an experimental tool [ddust][ddust tool] to demonstrate + how this would be done. + ## Changing consensus _A monthly section summarizing proposals and discussion about changing @@ -161,3 +196,5 @@ FIXME:Gustavojfe [lsmt wiki]: https://en.wikipedia.org/wiki/Log-structured_merge-tree [hash map wiki]: https://en.wikipedia.org/wiki/Hash_table [libbitcoin gh]: https://github.com/libbitcoin +[dust attacks del]: https://delvingbitcoin.org/t/disposing-of-dust-attack-utxos/2215 +[ddust tool]: https://github.com/bubb1es71/ddust From 86af8d1df1ead4644e2963516126765970c8651b Mon Sep 17 00:00:00 2001 From: Gustavo Flores Date: Thu, 5 Feb 2026 14:15:39 -0600 Subject: [PATCH 5/6] News391: add merge summaries and release --- .../en/newsletters/2026-02-06-newsletter.md | 75 ++++++++++++++++++- 1 file changed, 73 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2026-02-06-newsletter.md b/_posts/en/newsletters/2026-02-06-newsletter.md index ad804a8fd..5d9e2bb93 100644 --- a/_posts/en/newsletters/2026-02-06-newsletter.md +++ b/_posts/en/newsletters/2026-02-06-newsletter.md @@ -167,7 +167,13 @@ _New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates._ -FIXME:Gustavojfe +- [LDK 0.1.9][] and [0.2.1][ldk 0.2.1] are maintenance releases of this + popular library for building LN-enabled applications. Both fix a bug + where `ElectrumSyncClient` would fail to sync when unconfirmed + transactions were present. Version 0.2.1 additionally fixes an issue + where `splice_channel` didn't fail immediately when the peer doesn't + support [splicing][topic splicing], makes the `AttributionData` struct + public, and includes several other bug fixes. ## Notable code and documentation changes @@ -180,10 +186,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 #33604][] corrects the behavior of [assumeUTXO][topic + assumeutxo] nodes. During background validation, the node avoids + downloading blocks from peers that don't have the snapshot block in + their best chain because the node lacks the necessary undo data to + handle a potential reorg. However, this restriction persisted + unnecessarily even after background validation had finished, despite + the fact that the node could handle reorgs. Nodes now only apply this + restriction while background validation is ongoing. + +- [Bitcoin Core #34358][] fixes a wallet bug that occurred when removing + transactions via the `removeprunedfunds` RPC. Previously, removing a + transaction marked all of its inputs as spendable again, even if the + wallet contained a conflicting transaction that also spent the same + UTXOs. + +- [Core Lightning #8824][] adds an `auto.include_fees` layer to the + pathfinding `askrene` plugin (see [Newsletter #316][news316 askrene]) + that deducts routing fees from the payment amount, effectively making + the receiver pay for the fees. + +- [Eclair #3244][] adds two events: `PaymentNotRelayed`, emitted when a + payment couldn't be relayed to the next node likely due to + insufficient liquidity, and `OutgoingHtlcNotAdded`, emitted when an + [HTLC][topic htlc] couldn't be added to a specific channel. These + events help node operators build heuristics for liquidity allocation, + though the PR notes that a single event shouldn't trigger allocation. + +- [LDK #4263][] adds a `custom_tlvs` optional parameter to the + `pay_for_bolt11_invoice` API, enabling callers to embed arbitrary + metadata in the payment onion. Although the low-level endpoint + `send_payment` already allowed for custom Type-Length-Values + ([TLVs][]) in [BOLT11][] payments, it wasn't properly surfaced on + higher-level endpoints. + +- [LDK #4300][] adds support for generic [HTLC][topic htlc] + interception, building on the HTLC holding mechanism added for [async + payments][topic async payments] and expanding the prior capability, + which only intercepted HTLCs destined for fake SCIDs (see [Newsletter + #230][news230 intercept]). The new implementation uses a configurable + bitfield to intercept HTLCs destined for: intercept SCIDs (as before), + offline private channels (useful for LSPs to wake sleeping clients), + online private channels, public channels, and unknown SCIDs. This lays + the groundwork for supporting LSPS5 (see [Newsletter #365][news365 + lsps5] for the client-side implementation) and other LSP use cases. + +- [LND #10473][] makes the `SendOnion` RPC (see [Newsletter + #386][news386 sendonion]) fully idempotent, enabling clients to safely + retry requests after network failures without risking duplicate + payments. If a request with the same `attempt_id` has already been + processed, the RPC will return a `DUPLICATE_HTLC` error. + +- [Rust Bitcoin #5493][] adds the ability to use hardware-optimized + SHA256 operations on compatible ARM architectures. Benchmarks show + that hashing is approximately five times faster for large blocks. This + complements the existing SHA256 acceleration on x86 architectures (see + [Newsletter #265][news265 x86sha]). {% include snippets/recap-ad.md when="2026-02-10 17:30" %} {% include references.md %} +{% include linkers/issues.md v=2 issues="33604,34358,8824,3244,4263,4300,10473,5493" %} + [news386 jn hash]: /en/newsletters/2026/01/02/#hash-based-signatures-for-bitcoin-s-post-quantum-future [delving jn shrings]: https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158 [ml ap gcc]: https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg @@ -198,3 +261,11 @@ FIXME:Gustavojfe [libbitcoin gh]: https://github.com/libbitcoin [dust attacks del]: https://delvingbitcoin.org/t/disposing-of-dust-attack-utxos/2215 [ddust tool]: https://github.com/bubb1es71/ddust +[LDK 0.1.9]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.9 +[ldk 0.2.1]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.2.1 +[news316 askrene]: /en/newsletters/2024/08/16/#core-lightning-7517 +[TLVs]: https://github.com/lightning/bolts/blob/master/01-messaging.md#type-length-value-format +[news230 intercept]: /en/newsletters/2022/12/14/#ldk-1835 +[news365 lsps5]: /en/newsletters/2025/08/01/#ldk-3662 +[news386 sendonion]: /en/newsletters/2026/01/02/#lnd-9489 +[news265 x86sha]: /en/newsletters/2023/08/23/#rust-bitcoin-1962 From b842eed2453419bf7a8046879b30c7a82115881b Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 6 Feb 2026 04:56:59 -0600 Subject: [PATCH 6/6] News391: add topics --- _topics/en/consensus-cleanup-soft-fork.md | 3 +++ _topics/en/miniscript.md | 3 +++ _topics/en/output-linking.md | 3 +++ _topics/en/quantum-resistance.md | 9 +++++++++ 4 files changed, 18 insertions(+) diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md index 0bc5c06fa..e24e779a8 100644 --- a/_topics/en/consensus-cleanup-soft-fork.md +++ b/_topics/en/consensus-cleanup-soft-fork.md @@ -80,6 +80,9 @@ optech_mentions: - title: "Discussion of BIP54's timewarp fix and its impact on the 2106 block timestamp overflow issue" url: /en/newsletters/2026/01/02/#relax-bip54-timestamp-restriction-for-2106-soft-fork + - title: "Addressing remaining points on BIP54" + url: /en/newsletters/2026/02/06/#addressing-remaining-points-on-bip54 + ## Optional. Same format as "primary_sources" above see_also: - title: Soft fork activation diff --git a/_topics/en/miniscript.md b/_topics/en/miniscript.md index de1ea83b2..e62ef09e5 100644 --- a/_topics/en/miniscript.md +++ b/_topics/en/miniscript.md @@ -100,6 +100,9 @@ optech_mentions: - title: "New library for encrypting descriptors and miniscript to the included public keys" url: /en/newsletters/2025/06/13/#descriptor-encryption-library + - title: "Bithoven: A formal, imperative language for Bitcoin Script similar to Miniscript" + url: /en/newsletters/2026/02/06/#bithoven-a-formally-verified-imperative-language-for-bitcoin-script + ## Optional. Same format as "primary_sources" above see_also: - title: "Miniscript: streamlined Bitcoin scripting" diff --git a/_topics/en/output-linking.md b/_topics/en/output-linking.md index 1e6841c51..3325dba60 100644 --- a/_topics/en/output-linking.md +++ b/_topics/en/output-linking.md @@ -81,6 +81,9 @@ optech_mentions: - title: "Proposed scheme to prevent BIP32 path reuse to avoid output linking and other problems" url: /en/newsletters/2025/05/09/#avoiding-bip32-path-reuse + - title: "Discussion of dust attack mitigations" + url: /en/newsletters/2026/02/06/#discussion-of-dust-attack-mitigations + ## Optional. Same format as "primary_sources" above see_also: - title: Uneconomical outputs (dust) diff --git a/_topics/en/quantum-resistance.md b/_topics/en/quantum-resistance.md index d8bedbe0c..82c4c8c74 100644 --- a/_topics/en/quantum-resistance.md +++ b/_topics/en/quantum-resistance.md @@ -100,6 +100,15 @@ optech_mentions: - title: "Brassard-Høyer-Tapp (BHT) algorithm and Bitcoin" url: /en/newsletters/2026/01/30/#brassard-hoyer-tapp-bht-algorithm-and-bitcoin-bip360 + - title: "SHRINCS: 324-byte stateful post-quantum signatures with static backups" + url: /en/newsletters/2026/02/06/#shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups + + - title: "Falcon post-quantum signature scheme proposal" + url: /en/newsletters/2026/02/06/#falcon-post-quantum-signature-scheme-proposal + + - title: "SLH-DSA verification can compete with ECC" + url: /en/newsletters/2026/02/06/#slh-dsa-verification-can-compete-with-ecc + ## Optional. Same format as "primary_sources" above see_also: - title: Taproot