This week’s newsletter covers proposed changes to Bitcoin Core’s transaction replacement policies, details about the Hertzbleed side-channel vulnerability, conclusions from discussions on timestamp system design, and a review of a new Sybil-resistant protocol using Bitcoin UTXOs. Additionally, we highlight notable updates in Bitcoin client and service software, including new releases and significant changes across popular infrastructure projects.
News
Full Replace-by-Fee Option for Bitcoin Core
Two pull requests have been initiated to support a full replace-by-fee (RBF) option in Bitcoin Core, which would be disabled by default. If enabled, any unconfirmed transaction in the node’s mempool could be replaced by an alternative version that pays a higher fee, adhering to specific rules.
Currently, Bitcoin Core only allows RBF if the transaction being replaced has signaled opt-in as defined in BIP125. This poses challenges for multi-party contract protocols like the Lightning Network (LN) and Discreet Log Contracts (DLCs), where one party might remove the BIP125 signal to prevent replacements by others. Such actions can lead to delays or, in worst-case scenarios, financial losses in time-sensitive protocols like Hashed Timelock Contracts (HTLCs).
One of the pull requests has already garnered significant developer support. Since it only adds the capability for full RBF without enabling it by default, it does not alter Bitcoin Core’s current behavior. In the long term, some developers may advocate for enabling full RBF by default, prompting a discussion thread on the Bitcoin-Dev mailing list to gather feedback from service providers, application developers, and alternative full-node implementers.
Hertzbleed Side-Channel Vulnerability
A recently disclosed security vulnerability, Hertzbleed, affects many mainstream laptop, desktop, and server CPUs. When private keys are used to create signatures for Bitcoin transactions, this vulnerability could potentially allow attackers to extract those keys. Notably, the attack impacts signature-generation code specifically designed to use consistent CPU operations to prevent information leakage.
Exploiting Hertzbleed requires attackers to measure CPU power consumption or the duration of specific operations. The vulnerability is more likely to affect frequently used hot wallets, such as those employed by custodial services and LN routing nodes, especially in cases of address reuse. Cold wallets or those used in secure offline environments are less susceptible.
At this time, the full impact on Bitcoin users remains unclear. Many existing wallets, including popular hardware signing devices, use signature-generation code vulnerable to power and timing analysis. Users with higher security requirements should monitor developments and consider reaching out to software developers via support channels like Bitcoin Stack Exchange for specific guidance.
Timestamping System Design Debate
A prolonged debate on the Bitcoin-Dev mailing list regarding the design of Bitcoin-based timestamping systems, such as Open Timestamps (OTS), appears to have reached a conclusion. The discussion highlighted two distinct approaches to timestamping:
- Timestamped Proof of Existence (TSPoE): A Bitcoin transaction commits to a hash digest of a document. Once the transaction is confirmed in a block, the creator can prove to third parties that the document existed at the time of the block’s creation. Each timestamp is independent, allowing multiple timestamps for the same document without interlinking.
- Event Ordering (EO): A series of interconnected transactions commit documents in a way that allows any user to verify all commitments. This system enables the verification of when a document was first timestamped.
TSPoE systems, like OTS, are efficient and scalable, requiring minimal global storage since users store their own proofs. They are also simpler in concept and implementation. EO systems, by contrast, require all participants to store every document commitment, increasing complexity but enabling verification of initial publication timing.
The discussion did not lead to proposed changes for existing systems like OTS or transaction sponsorship but provided clarity for participants with differing views on timestamping implications.
RIDDLE: A New Sybil-Resistance Protocol
Adam “Waxwing” Gibson proposed a Sybil-resistant mechanism on the Bitcoin-Dev mailing list that uses Bitcoin UTXOs while preserving privacy. Users generate a list of UTXOs—one owned by the user and others by different parties—and create a signature provably from one UTXO owner without revealing which one.
Malicious users can generate multiple proofs but are limited by the number of available UTXOs, curbing their ability to consume network resources excessively. Spending a UTXO to acquire a new one incurs transaction fees, further discouraging abuse. Services can impose additional constraints, such as accepting only UTXOs with specific values or ages.
Gibson’s RIDDLE protocol supports both global and local contexts for membership proofs. Global proofs are shared among verifiers, allowing one proof per UTXO in a given context (e.g., one account registration per 1 BTC UTXO aged over a year). Local proofs are specific to individual verifiers or groups, enabling UTXO reuse across services.
High-value UTXOs can be treated as multiple lower-value ones, enhancing flexibility. While RIDDLE offers privacy advantages over other Sybil-resistance mechanisms, Gibson cautions that combining system data with external information could weaken privacy guarantees.
On the Lightning-Dev mailing list, developer ZmnSCPxj suggested RIDDLE could decouple Sybil-resistance from UTXO-based channel identifiers in the Lightning Network, improving privacy in the era of Taproot and signature aggregation.
Services and Client Updates
This section covers interesting changes in Bitcoin wallets and services.
- Zeus Adds Taproot Support: Zeus v0.6.5-rc1 introduces support for sending and receiving via Taproot for LND v0.15+ backends.
- Wasabi Wallet 2.0 Released: This release implements the WabiSabi protocol for improved coinjoin transactions and includes several other enhancements.
- Sparrow Enables Taproot Hardware Signing: By upgrading to HWI 2.1.0, Sparrow v1.6.4 adds Taproot signing support for certain hardware signing devices.
New Releases and Release Candidates
New versions and release candidates for popular Bitcoin infrastructure projects. Consider upgrading or helping test candidate versions.
- LND 0.15.0-beta.rc6: A release candidate for the next major version of this popular LN node implementation.
- LDK 0.0.108 and 0.0.107: These versions add support for large channels, zero-conf channels, and gossip synchronization for mobile clients, alongside other features and bug fixes.
- BDK 0.19.0: This release introduces experimental Taproot support via descriptors, PSBTs, and other subsystems, along with a new coin selection algorithm.
Notable Code and Documentation Changes
This week saw significant developments across key Bitcoin projects:
- Bitcoin Core GUI #602: Changes made via the GUI are now written to a configuration file also loaded by the headless daemon (
bitcoind), ensuring consistent configuration regardless of startup method. - Eclair #2224: Adds support for short channel identifier (SCID) aliases and zero-conf channel types, improving privacy and enabling channel references before full confirmation.
- HWI #611: Introduces single-signature support for Bech32m addresses on BitBox02 hardware signing devices.
👉 Explore real-time development tools
Frequently Asked Questions
What is replace-by-fee (RBF)?
RBF allows replacing an unconfirmed transaction with a new version that pays a higher fee. This is useful for accelerating confirmations but requires opt-in signaling under current Bitcoin Core rules.
How does Hertzbleed affect Bitcoin users?
Hertzbleed is a CPU vulnerability that could leak private keys during signature generation. It primarily impacts hot wallets and services with frequent signing operations, though offline wallets remain relatively secure.
What are the benefits of Taproot?
Taproot improves privacy and efficiency by making all transactions appear identical on the blockchain. It also enables complex smart contracts with lower fees and enhanced scalability.
How does RIDDLE prevent Sybil attacks?
RIDDLE uses Bitcoin UTXOs to create proofs of ownership without revealing specific details. This limits users’ ability to create multiple identities while maintaining privacy.
What is the difference between TSPoE and EO timestamping?
TSPoE provides independent proofs of existence for documents, while EO enables verifiable event ordering, showing when a document was first timestamped.
Why are zero-conf channels important?
Zero-conf channels allow Lightning Network participants to use channels before they are fully confirmed, reducing open/close delays and improving user experience.