Bitcoin’s price usually steals the headlines, but the work that sustains the protocol follows its own schedule. That work is recorded in the repository and in the forums where developers discuss every change before it reaches the main network.
Research into Bitcoin’s official GitHub repositories, open pull requests, the threads with the highest number of replies on Delving Bitcoin and the bitcoindev mailing list, along with the weekly Bitcoin Optech summaries (especially issues 417 and 418 from August 2026), identified the lines of work with the greatest volume of technical discussion in recent weeks.
BIP-54 aims to fix inherited consensus flaws
Bitcoin Improvement Proposal 54 (BIP-54), known as Consensus Cleanup and written by Antoine Poinsot and Matt Corallo, corrects four specific technical problems in the protocol.
The most discussed conflict targets the so-called timewarp attack, a technique by which an attacker with the majority of the network’s computing power can manipulate block timestamps to trick the algorithm that adjusts mining difficulty—the parameter that determines how hard it is to find a valid block and that the network recalculates every 2,016 blocks to maintain an average of ten minutes between each one.
An earlier fix for that attack left open a variant that Poinsot himself later detected together with the pseudonymous researcher Zawy. It consists of setting the timestamps of two difficulty periods far into the future to force an artificial drop. BIP-54 closes that variant, known as the Murch-Zawy rule, by requiring that the last block of a difficulty period never has a timestamp earlier than the first one.
The other two fixes in the proposal limit the number of signature operations a legacy transaction can contain, to prevent so-called “poison blocks” that can take minutes or hours to validate, and invalidate transactions of exactly 64 bytes, which can be confused with internal nodes of the Merkle tree.
The BIP-54 specification has already been merged into the official Bitcoin repository, meaning its technical design is now closed, although it is not yet activated on Bitcoin’s main network.
Data on a Bitcoin proposal
The underlying technical discussion took place in a Delving Bitcoin thread that revisits an original proposal by Corallo from 2019 and has accumulated 92 replies—the highest number on that site.
In April 2026, Poinsot and developer Anthony Towns also publicly demonstrated on the Signet test network the second problem the proposal addresses: valid but deliberately slow-to-validate blocks, nicknamed “poison blocks.”
Full implementation of the four rules is advancing in the official Bitcoin repository through a pull request opened on July 24 by Poinsot himself. In parallel, other pull requests tackle specific pieces of the same implementation, such as the one that specifically strengthens the Murch-Zawy rule inside the mining code, opened on August 11 by developer fjahr.
The fight over data inside a block
The discussion about what kind of data should be allowed to be stored inside a Bitcoin block is not new. OP_RETURN is an opcode that lets arbitrary data (such as text, images, or files) be attached inside a transaction without that content being processed by the network as a monetary transfer.
In October 2025, Bitcoin Core, the network’s reference software, raised the default limit for that field from 83 to 100,000 bytes, making it easier to store much larger volumes of non-financial information. That change deepened the dispute between those who defend Bitcoin’s neutrality toward any type of data and those who want to reserve block space for strictly monetary use—the same underlying discussion that led to the BIP-110 proposal (which has already been marked as closed).
Against that background, developer MrHash published the Segregated Data (SegData) draft, which has accumulated 47 replies on Delving Bitcoin and is one of the most active threads in recent weeks.
SegData does not touch the OP_RETURN limit. Instead, it creates a new block region, separate from the scripts that define a transaction’s spending conditions, designed to host data such as those currently circulating through protocols like Runes.
That region would be prunable, meaning the data could be deleted once validated by nodes without losing the ability to verify the rest of the chain, and it would be committed via a reference included in the coinbase transaction—the first transaction of each block, with which the miner claims the reward.
Quantum-resistant addresses
BIP-360 is one of the technical proposals currently advancing to harden Bitcoin against the eventual arrival of a quantum computer powerful enough to break the cryptography that protects the network’s keys. Both on Bitcoindev and Delving Bitcoin, it is one of the most active debates, with dozens of threads in both forums.
The proposal defines a new address type called Pay to Merkle Root (P2MR), based on the Taproot format (Bitcoin’s most modern format, which allows more complex spending conditions), although P2MR eliminates the spending path that exposes the public key in those Taproot addresses. In this way, BIP-360 prevents a future quantum attacker from using that visible key to derive the private key and access users’ funds.
BIP-360 was incorporated into the official Bitcoin proposals repository on February 11, 2026, and still has no activation date, as CriptoNoticias has already explained.
On the same discussion, developer Pieter Wuille proposed on June 25 on the Bitcoin developers mailing list a mechanism that would guarantee the future deactivation of elliptic-curve cryptography (currently used to protect digital signatures in Bitcoin) in output types prepared to resist the presumed attack from quantum computers.
What are developers discussing in Bitcoin Optech?
The weekly Bitcoin Optech summaries from the first weeks of August 2026 show that developers continue pushing other improvements that are lower-profile but equally constant.
One of the most commented is a new network message called Stale Tip Relay, so that nodes can announce when a valid block falls outside the main chain—something that is currently hard to track because that block stops propagating as soon as the competing chain wins. Having that signal would help detect propagation problems or anomalous network behavior earlier.
CISA is also advancing; it combines the different inputs of the same transaction into a single signature and thereby reduces the size of operations that spend multiple inputs at once.
In parallel, Bitcoin Core is preparing for its version 32.0, with changes that make node resource usage more efficient. One of them replaces the per-connection limit on relayed transactions with a global limit, so that an activity spike does not suddenly saturate the machine’s CPU or memory.
Added to that is the update of the cryptographic library libsecp256k1 to version 0.8.0, which added native support for Silent Payments and speed improvements in signature verification.
All of this is discussed openly in the same forums and repositories that anyone can consult. Overall, the picture shown by Optech issues 417 and 418 is one of constant development without spectacular leaps, but with practical advances in performance, privacy, and network resilience.
https://www.criptonoticias.com/tecnologia/bitcoin-desarrolladores-consenso-mineria-debates/
