All Activity

A recently shared research paper introduces a protocol designed to facilitate soft-agreement within the Bitcoin mempool before block discovery. This approach aims to accelerate block propagation throughout the network, thereby improving the efficiency of machine utilization during transaction processing and block creation.

The protocol leverages elements from several existing consensus mechanisms, synthesizing them into a system reminiscent of the Snowball protocol.

A comparative implementation of an Alice/Bob/Carol channel was conducted using three distinct approaches: APO+CTV, a CSFS+CTV rekey ladder, and, following the activation of OP_TEMPLATEHASH in Inquisition 29.4, scripts from @instagibbs’ 2026-01-eltoo_th BOLT draft utilizing TEMPLATEHASH, CSFS, and INTERNALKEY.

The most recent iteration intentionally published an outdated state to observe whether a newer update could supersede it—a core requirement for eltoo-style state channels. This process involved a sequence of transactions, beginning with funding (1163d3d5…9c259124), publishing an old state (22c0c67b…02188692), replacing it with a newer one (4a11cfca…dea15007), and finally settling the latest state (e7476180…e8001568).

Multiplication in Bitcoin Script has long been constrained due to the disabling of OP_MUL since 2010. Under BIP-342, multiplication must be synthesized using only OP_ADD and shift operations, with a strict requirement that every intermediate value fits within a 4-byte CScriptNum.

Bitcoin Core version 32.1 has been officially released, superseding earlier versions and rendering versions 29.x and older obsolete. With this update, those older versions are now at "End of Life" and will not receive any further updates or security patches.

The correct condition for the post is that num_dead should be greater than or equal to four times num_live, expressed as num_dead >= 4 * num_live. This clarification addresses an error in the previous version, ensuring that the logic accurately reflects the intended comparison between the values of num_dead and num_live.

Subjective information hazards present a unique challenge within blockchain ecosystems. Although there is no consensus on a universal, objective list of such hazards, it is widely acknowledged that these risks exist and can be perceived differently depending on individual perspectives.

A Merkle tree's depth significantly influences the size of a witness in cryptographic protocols. For a depth-1 tree, the witness is approximately 100 bytes.

The scheme under consideration simplifies its key architecture by reducing the threshold key to multiple MuSig2 instances. This structural choice enables the author to utilize the established MuSig2-in-MuSig2 proof, which is particularly relevant for Taproot channels.

Reproducibility is essential when demonstrating the effectiveness of a particular transaction mechanism. For instance, in scenarios involving high transaction fees, it is important to publish the exact setup used in any demonstration.

Ensuring a seamless transition between different cryptographic security models, particularly at the SHRINCS composition boundary, requires meticulous attention to several critical implementation details. Among these, one of the foremost priorities is to guarantee that the digest is finalized prior to any exposure of the WOTS public key, as premature revelation could undermine the intended security guarantees.

Furthermore, mechanisms must be put in place to prevent state rollback, an issue that could otherwise lead to the unintended reuse of keys.

Bitcoin’s trajectory as a payment method remains uncertain, with ongoing debate over whether its primary value lies in functioning as digital gold or as a viable everyday currency. Jack Dorsey has argued that true success for bitcoin comes when it becomes a daily-use currency rather than simply a store of value.

A new, user-friendly mirror of the bitcoin-dev mailing list archive has been established and is updated daily. This archive distinguishes itself from alternatives such as public-inbox by offering one dedicated page per discussion thread, where message quotes are folded for clarity.

Nodes enforce strict rules regarding the maturity of coinbase outputs, specifically rejecting any attempt to spend these outputs before they reach a maturity of 100 blocks. As a result, transactions that attempt to spend immature coinbase outputs cannot be placed in the mempool during this period.

SHA256 hash verification is an effective way to confirm file integrity, but its reliability depends heavily on the origin of the expected hash. When both the file and its hash are obtained from the same location, such as a single GitHub release, this approach does not offer protection if that source itself has been compromised.

A more robust method for ensuring file authenticity involves using signed releases or reproducible builds.

Ensuring the durability of a signing refusal before allowing any partial signature to exit the process is critical. If durability is not guaranteed at this stage, system crashes that occur between sending the signature and committing the database row may inadvertently reopen the path for conflicting signatures upon restart.

A sharechain has the capability to reject a miner’s submitted share if the coinbase transaction is invalid. However, it lacks the authority to enforce payout redirection on the actual Bitcoin mainchain.

Fault-injection testing plays a crucial role in validating the reliability of the compressed block format. By deliberately truncating records, corrupting data frames, and interrupting write operations, it becomes possible to assess how effectively the system detects and handles incomplete or damaged data.

Open systems commonly issue identifiers such as public keys with virtually no associated resource cost, resulting in a situation where the incremental expense of generating additional identifiers is negligible. This economic structure places the burden of filtering, storage, and abuse management on those who accept these identifiers, rather than on those who produce them.

Testnet-2 has been operational since 24 October 2026, introducing the transition of the leader Verifiable Random Function (VRF) to RFC 9381. While the mainnet is yet to be launched and testnet coins hold no real-world value, detailed status updates and a streamlined one-command node setup are accessible on the official repository and project website.

The current development phase emphasizes rigorous independent critique of several foundational claims before advancing to mainnet deployment.

Between versions v25.02 and v26.04, Core Lightning (CLN) contained a vulnerability that allowed a node to crash when it received a channel_announcement message where both endpoints—node_id_1 and node_id_2—were set to the same node. This occurred because CLN did not verify that these two node IDs were distinct, contrary to the intended protocol design in BOLT 7, which expects the sender to order the node IDs lexicographically, implying they must be different.

Ensuring Bitcoin’s resilience against future quantum attacks presents a dilemma when dealing with legacy outputs vulnerable to key exposure, such as early pay-to-public-key (P2PK) or long-dormant wallets. Traditional solutions have focused on either implementing a “hard freeze”—permanently locking unmigrated coins after a predetermined deadline—or taking no action, leaving these funds perpetually exposed to potential quantum-enabled theft.

The eCash fork and the associated developments around BIP300, drivechains, and blind merged mining present a significant evolution in blockchain scalability and sidechain functionality. Among the more detailed critiques and technical explorations available online, resources such as discussions on stacker.news and Peter Todd’s analysis at petertodd.org provide insight into both the practical and theoretical implications of these proposals.

A central discussion point is the mathematical validity and real-world application of Proof of Work (PoW) puzzles in securing sidechains.

Over the past two years, a series of projects have been developed to address persistent user experience issues that hinder merchant adoption of Lightning payments and contribute to centralization around custodial providers. One significant advancement is the Electrum CLINK plugin, designed to facilitate receiving unsolicited Lightning payments without requiring merchants to expose their wallets to the internet or manually generate invoices for every transaction.

A transaction filtering policy domain-specific language (DSL) was developed and integrated into satd, a Rust-based, full Bitcoin node implementation. This feature empowers node operators to explicitly define which transaction patterns their nodes will relay or include in block templates, ensuring that these local policies never interfere with consensus rules.

FinalisCore introduces a novel approach to Layer-1 blockchain protocol design with the goal of achieving strict deterministic finality within a UTXO-based framework, while simultaneously enforcing transactional privacy from the genesis block. The architecture employs deterministic Byzantine Fault Tolerance (BFT) state transitions, avoiding traditional longest-chain consensus and related reorganization risks.

btc-verified has been developed as a minimal model of Bitcoin consensus, with an emphasis on formalizing the protocol layer by layer. Formalization helps uncover subtle aspects of how systems work; yet, it is essential to recognize that even the most precise models may not fully capture the complexities of real-world implementations.

Groth16 provides a powerful proof system enabling the demonstration of complex computational statements via succinct proofs, expressible with just three group elements. In typical applications, this allows a prover to convince a verifier that a statement is true with minimal data transfer and verification complexity.

Floresta has recently integrated an implementation of SwiftSync, a method designed to optimize synchronization processes. This advancement leverages the implicit deletions technique for Utreexo, which aims to improve efficiency in managing unspent transaction outputs (UTXOs).

Secure multiparty signing protocols are evolving to address the growing need for privacy and security in Bitcoin transactions, especially with the advent of Silent Payments. The proposed protocol integrates established cryptographic techniques from various Bitcoin Improvement Proposals (BIPs) and focuses on elliptic curve cryptography over the secp256k1 curve.

Bitcoin, initially conceptualized as a decentralized electronic cash system to empower individuals without relying on traditional financial intermediaries, appears to be diverging from its founding ideals. Over the years, Bitcoin has transformed significantly; it is now increasingly perceived not merely as a currency but rather as a reserve asset.

The latest release candidate for Bitcoin Core, version v32.0rc4, is now available for download. This version represents a significant step towards the final release of Bitcoin Core v32.0, assuming no critical problems are identified during testing.

btc-safe, an open-source project, has been developed as a watch-only Bitcoin multisig coordinator. This tool enhances the security and efficiency of managing multisignature transactions by allowing one owner to propose transactions which are then accessible in a shared queue for all co-signers.

Luke Carriere has introduced a draft that establishes a standardized policy format for governing the criteria under which a co-signer is authorized to sign a transaction. This proposal is designed to unify disparate approaches and innovations in the domain of co-signed transactions, including methods such as Halseth's blinded co-signers, Chain Code Delegation, predicate blind signatures, and bonded co-signers, along with platforms like Liquidium and Lendasat.

Bitcoin's payment landscape is evolving with multiple layers and platforms attempting to facilitate seamless transactions across these layers. Arkade introduces the Intents protocol, which significantly simplifies the routing of payments by utilizing various solvers that operate on behalf of users.

The Writz Protocol represents an innovative approach in the cryptocurrency lending space by using Bitcoin as collateral on its native blockchain, while disbursing loans in USDC on the Stellar network. This system is still under development in a testnet phase and has not undergone a formal audit, highlighting the need for thorough review especially of its Bitcoin handling mechanisms.

Expanding Bitcoin’s descriptor system to handle hash preimages introduces a significant enhancement to how wallets can manage and automate complex script conditions. Presently, descriptors support both public and private key representations but lack direct provisions for specifying the preimages required in scripts utilizing functions like sha256 or hash160.

The issue discussed revolves around the challenge of preventing double-spending in transactions without relying on existing punitive models like those used in Lightning Network channels or requiring soft forks for implementation. The primary concern is to ensure that Alice, the payer, cannot pre-broadcast a transaction an instant before completing a payment to Bob, thereby causing Bob's subsequent transaction to be recognized as a double-spend.

The recent update to Eclair, version 0.14.1, addresses two critical vulnerabilities that were present in previous versions up to v0.14.0. These vulnerabilities are essential for users and operators to understand to ensure the security and functionality of their nodes.

The first vulnerability identified as LNF-2026-0003 involves a denial-of-service (DoS) exploit related to the channel opening process.

Digital wallets that facilitate both on-chain and Lightning Network Bitcoin transactions present a unique usability challenge, especially for those inexperienced with the distinctions between these two payment types. Many users, regardless of technical background, tend to conflate on-chain and Lightning payments as simply "BTC." This widespread misconception necessitates thoughtful design choices in wallet interfaces, particularly concerning how and when information about transaction types is presented to users.

The latest release candidate for Bitcoin Core, version 32.0rc2, is now available for download. This version signifies a major update, and interested users can access the binaries from Bitcoin Core's official site.

The recent updates to the Signing Room and the stateless PSBT coordination BIP draft have introduced significant enhancements, particularly in security and access control management. The release of version 3.4.0 of the coordinator and version 1.2.0 of the SDK marks a shift towards Role-Based Access Control (RBAC).

The bitcoin-rs project emerges as an innovative reimagining of a Bitcoin full node, leveraging the strengths of Rust to deliver enhanced performance and reliability. By integrating both the UTXO set and a script-index model directly into the core architecture, this implementation achieves efficient validation and caters to common wallet and blockchain explorer queries without reliance on external Electrum indexers.

Forwardable Peerswaps is an innovative protocol designed to address several liquidity and privacy issues associated with the Lightning Network, particularly in comparison to current splicing methods. This new approach offers a more sophisticated mechanism for managing liquidity that provides substantial benefits in terms of incentive compatibility and privacy.

The primary advantage of Forwardable Peerswaps over splicing lies in its ability to ensure truthful representation of inbound liquidity.

The recent release of Eclair v0.14.0 addresses two critical denial-of-service (DoS) vulnerabilities that were present in earlier versions up to v0.13.1. It is highly recommended for users to update their nodes to this latest version to enhance security and stability.

In a comprehensive analysis of Bitcoin's mainnet filters, data was collected from blocks 709,656 to 965,089, encompassing 255,434 blocks without any sampling. The study compared the storage requirements of different types of filters and tweaks applied over these blocks, providing significant insights into their efficiency and applicability.

The basic BIP-158 filter required 5.78 GB in total or roughly 2.84 MB per day, whereas the Taproot-only filter showed a dramatically reduced size, requiring only 0.33 GB in total or 0.14 MB per day.

The evolution of Bitcoin softfork development has undergone significant changes over recent years. Initial enthusiasm for covenants—a mechanism that allows contractual conditions to be attached to transactions—gradually dissipated as the community shifted its attention toward emerging topics such as ordinals, inscriptions, and divisions within core development teams, which ultimately led to a major hardfork.

Shielded Bitcoin represents a significant advancement in the pursuit of privacy-preserving transactions within the established Bitcoin ecosystem. Its architecture introduces the use of encrypted notes—digital representations that encapsulate both transaction amounts and recipient identities—without exposing this sensitive information on the public blockchain.

In the realm of ethical hacking and responsible disclosures, the principles guiding interactions between security researchers and vendors are critical, especially considering the potential for financial gain from exploiting vulnerabilities. A notable example is the CVE-2020-26895 vulnerability in bitcoin L2s security research, which highlighted the temptation to use discovered exploits for personal profit.

The framework designed to enhance L1 throughput under Nakamoto security introduces several innovative mechanisms that collectively aim to shift propagation latency challenges from a physical bottleneck to a more manageable, configurable validation window. The core of this approach is the Asynchronous Pipeline Consensus which involves key elements such as Decoupled Mining Initiation and Deferred Declaration.

The email delves into the concept of validating a threshold signature in Bitcoin Script without using hash-based constructions, specifically discussing a scenario where a threshold signature scheme like FROST is used in place of traditional methods. The sender explores utilizing elliptic curve scalar multiplication instead of one-way hash functions to create a verifiable and non-equivocating signature verification process within Bitcoin's scripting language.

The discussion outlines how each bit of a message could be verified in Bitcoin Script by employing an innovative technique involving R-committed keys for each bit or digit of the message.

Bitcoin’s consensus protocol relies on carefully crafted timewarp rules to prevent timestamp manipulations that could undermine the integrity and predictability of block creation. Two principal constraints serve as safeguards: the first limits the initial block’s timestamp in a retarget period to being no more than 7200 seconds earlier than its immediate predecessor, effectively mitigating the ArtForz timewarp attack; the second ensures that the final block in a retarget period cannot have a timestamp preceding that of the period’s first block, which counters potential exploits such as the Murch-Zawy alternating attack.

Ahmet Kurt and his team at East Texas A&M University have developed PQLN, a pioneering post-quantum extension for the Lightning Network, implemented in rust-lightning. This design aims to secure all off-chain surfaces of Lightning against potential quantum computing threats by upgrading various elements like transport layers and payment invoices without requiring consensus changes.

The email discusses a protocol designed to scale Bitcoin usage by allowing billions of users to safely own, send, and receive Bitcoin with minimal on-chain footprints. The protocol introduces "depots," which are mechanisms that enable many thousands or millions of users to hold Bitcoin in off-chain Lightning channels securely, without the reliance on custodial solutions like exchanges.

The recent discussions surrounding the implementation of an unspendable NUMS key within a script-only Taproot policy have led to several decisions aimed at standardizing this approach without overstepping existing Bitcoin Improvement Proposals (BIPs). The primary decision was the establishment of a placeholder, denoted as _, for representing the unspendable NUMS key in transaction descriptors.

Utreexo represents a significant advancement in Bitcoin transaction output (TXO) management by employing a dynamic accumulator structured as a forest of perfect Merkle trees. This architecture enables nodes to maintain only the root hashes of these trees, dramatically reducing both storage and computational requirements.

The analysis of simplified Bitcoin vault constructions presented in the shared report offers a detailed comparison across several key parameters, including partial withdrawals, withdrawal address commitment timing, flexibility in managing transaction fees, operational complexity, and on-chain costs. The study evaluates various mechanisms like presigned transactions, CTV (CHECKTEMPLATEVERIFY), APO/APOAS (Anyprevout/Anyprevout Anyscript), TXHASH, CCV (Concurrent Consensus Voting), and CAT-based (Covenant Assembly Tree) Purrfect Vault construction.

In the findings, it is evident that each construction method caters to different needs and challenges.

The discussion around the integration of post-quantum cryptographic signatures in Bitcoin, specifically through the use of SNARKs (Succinct Non-interactive ARguments of Knowledge), is gaining traction due to recent advancements in efficient binary circuit provers. The concept, often referred to as "BitZip," aims to compress these signatures effectively to mitigate the increased storage and bandwidth costs associated with their large size.

The current discussion involves the proposed enhancements and classifications in the exposure of public keys within Bitcoin Improvement Proposals (BIPs), specifically addressing the nuances and implications of BIP 360 and BIP 361. The classification system introduces four categories: EXPOSED_AT_REST, EXPOSED_ON_SPEND, NOT_EXPOSED, and UNDETERMINED.

The email details a comprehensive approach to implementing a protocol that addresses the challenges of conditional payments in blockchain technology. The primary focus is on establishing a mechanism that allows for the reconciliation of off-chain protocol messages with the on-chain timeline, ensuring that agreements on conditional payment states are accurately reflected and verifiable.

The summer project discussed involves a sophisticated construction in cryptocurrency vault mechanisms, where certain operational choices have been highlighted for their uniqueness and efficacy. Unlike traditional discussions that often overlook these elements, the implementation of an enforced operational delay by two independent actors is notable.

The ongoing evolution of multi-party custody solutions such as 2-of-3 multisig, MuSig2 Taproot aggregates, and covenant-free time-locked vaults highlights significant complexities in managing the coordination of Partially Signed Bitcoin Transactions (PSBTs) and signing rounds. Central coordination, typically handled by a wallet vendor's coordinator, presents potential risks including central points of failure or surveillance.

The debate regarding the necessity and advantages of running a node in decentralized networks, particularly within the cryptocurrency sphere, reveals a complex interplay between ideology, practicality, and individual user needs. While proponents often advocate for universal node operation as a means to bolster personal security and network robustness, the direct benefits for the average individual remain ambiguous and are frequently contested.