Today DMND and RootstockLabs announce a new feature rollout intending to further the decentralization of Bitcoin mining. The new feature uses Stratum V2 to enable miners at the pool engaging in their own block template construction to also handle the selection and inclusion of merge-mined block commitments from the Rootstock (RSK) sidechain as well.

Merge-mining is a process by which multiple blockchains can share, or “reuse”, the same POW from the same set of miners. One blockchain, the child chain, structures its block headers to include the headers of the parent chain, i.e. the hash of the child chain’s block header is actually included inside a parent chain block (usually in the coinbase transaction), and software for the child chain is aware of this, actually validating part of the parent chain’s blocks in the process of verifying the child chain’s blocks.

This allows miners of the parent chain to mine multiple blockchains at once by simply including blockheader commitments in their coinbase transaction, and then mining blocks for the parent blockchain. When one is found for the parent chain, one is found for all of the child chains as well.

DMND’s integration allows miners to claim the sidechain rewards in rBTC (Rootstock’s bitcoin backed token whose reserves are managed by the federation operating the sidechain) directly on the sidechain, with no revenue sharing or intermediary pool custody.

There is potential for a dynamic like this to actually have the opposite impact on decentralization, but it is nonetheless an important development that will actually put such questions to the test in the real world.

Alejandro De La Torre, CEO and Co-Founder of DMND, had this to say: “The miner controls the merge mining and the miner gets paid for the merge mining. More delegation of control to miners is our key support for further decentralisation of the Bitcoin ecosystem.”

This post DMND and RootstockLabs Partner To Bring Stratum V2 To Merge-mining first appeared on Bitcoin Magazine and is written by Shinobi.

None of us can see the future. We don’t know what 2036 will bring. 

We all like to tell ourselves that we can, or do, and maybe we do actually see small pieces of it coming before we catch up to them, but none of us see the whole picture. That’s, at the end of the day, part of what it is to be human. 

Nevertheless we can’t seem to help ourselves from at least trying. 

Going into the second half of the 2020s we are coming out of a time period that marked wild and tumultuous disruption, with the world changing in both big and small ways that none of us could have imagined in our wildest dreams at the start of 2020. As we enter the second half of the decade, events around the world are starting to push us in a direction that seems like it will be even more disruptive and unpredictable than the first half of the decade. 

In this issue, we are going to do what we can’t help ourselves doing, we’re going to try to predict the shape of the next decade. I say shape, and not just the future itself, because that is the best that human beings can actually do. 

These pages are filled with pieces written by some of the most influential and intelligent people that engage in this space trying to look ahead and provide something of value to you, the reader. Some have given deep analysis of how larger geopolitical trends will unfold, others have written more lighthearted musings on what different aspects of our lives will be like day-to-day, and some have written what I can only call warnings or reminders of what to keep in mind while navigating the coming ten years. 

Every few generations, the world seems to go through some tumultuous upheaval. A radical shift that upends the order and institutions that maintained the previous shape of the world. I think we are entering that next period now, and we’ve probably been standing in its doorway since 2020. 

Chaos and change are not solely reasons to give in to fear, or anxiety, they are also reasons to have hope and optimism. When things fall apart, it doesn’t just mean the end of what was there before, it means there is space to build something new. It signals the beginning of something new in the exact same moment that it signals the end of something old. 

The next ten years are going to be the biggest opportunity yet for Bitcoin. We can either spend them optimistically building, putting our energy into bringing into reality the positive impact we see that Bitcoin can have on the world, or we can squander them doing the opposite. 

Ultimately, the shape the future has when it finally arrives at our doorstep will be the shape that all of our individual actions and choices mold it into. 

Make them count. 

Don’t miss your chance to own The 2036 Issue — featuring articles written by many influential figures in the space pondering the challenges of the next decade!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The 2036 Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

This post The 2036 Issue: Letter From The Editor first appeared on Bitcoin Magazine and is written by Shinobi.

The Stratum v2 Working Group announces today that ANTPOOL, Block Inc, F2Pool, Foundry, Spiderpool, MARA Foundation, and DMND have joined the working group to advance the adoption of the Stratum v2 protocol. 

The working group was founded in 2022 by Braiins and Spiral to develop and maintain the Stratum v2 protocol as an open and vendor-neutral specification usable by the Bitcoin mining ecosystem. The protocol is an upgrade to the original Stratum mining protocol, bringing massive efficiency gains, privacy, security, and functionality that can be used to improve overall mining decentralization. 

The onboarding of the new members, all substantial players in the mining ecosystem, represents a big leap forward for the working group’s progress in ensuring proper functioning and compatibility across real-world mining operations at scale. It also shows a growing consensus in the mining ecosystem that Stratum v2 is the direction to take going into the future. 

“We’re proud to support the broader adoption of Stratum V2. Aligning around an open, interoperable standard enables the industry to collaborate more effectively and drive improvements in efficiency, security and decentralization,” said Andy Zhou, CEO of ANTPOOL. 

Stratum v2 supports mechanisms for more efficient management of large fleets of miners, is end-to-end encrypted, and allows individual miners to produce their own block templates with supporting pools (among other features). 

Kenway Wang, CTO of Spiderpool had this to say: “Decentralization is core to our mission. Stratum V2 supports this by enabling miner-constructed templates, while also improving efficiency, especially for miners in bandwidth-constrained environments.” 

About the Stratum V2 Working Group

The Stratum V2 Working Group is an open collaboration initiative dedicated to advancing the development, adoption, and interoperability of the Stratum V2 mining protocol. It maintains a public specification and provides a coordination layer between developers and industry stakeholders.

This post ANTPOOL, Block Inc, F2Pool, Foundry, Spiderpool, MARA Foundation & DMND Join Stratum v2 Working Group first appeared on Bitcoin Magazine and is written by Shinobi.

Today Presidio Bitcoin, a Bitcoin hub located in the Bay Area in California, has launched a knowledge repository/living report on Github to track the current state of research related to Bitcoin’s quantum vulnerability.

The report aims to be a central location where people in the ecosystem can easily keep track of and analyze the current state of research around the issue.

It currently takes a comprehensive look through the state of:

• The current state of quantum computing, as well as research into different quantum computing technologies that could lead to material engineering progress towards a viable device.
• The level of exposure, i.e. how many coins and how much overall value is currently vulnerable to long-range attacks by a capable quantum computer.
• Post-quantum cryptographic schemes, as well as the current state of research in developing variants of such schemes more heavily optimized for Bitcoin’s unique architecture and way of functioning.
• Different ways of implementing post-quantum cryptography in Bitcoin, and the trade-offs between these different paths.
• Different mechanisms for safely migrating vulnerable coins to quantum-safe addresses in the event that a powerful enough quantum computer is created before users migrate to post-quantum cryptography.
• An analysis of different ways that the actual migration could play out under different circumstances.

They plan to regularly update the repository/report as new research comes out, and solutions and plans are further refined and updated.

The announcement comes after growing claims that Bitcoin developers are not doing anything to acknowledge or address the issue, and aims to highlight the on-going research and development into solutions to the issue conducted by developers.

Read the current version of the report here.

This post Presidio Bitcoin Releases Quantum Readiness Paper first appeared on Bitcoin Magazine and is written by Shinobi.

In two days, on Wednesday April 8th, a handful of Bitcoin Core developers are going to be doing a demonstration of “attack blocks” designed to take an inordinate amount of time to verify on Signet.

The demonstration will take place at 10 AM EST (2 PM UTC). Anyone who wishes to participate can run Bitcoin Core node on Signet and watch the blocks be mined and processed by their node in real-time.

Instructions can be found here to spin up a node and follow along (including how to check your node’s logs to see the verification times for the attack blocks).

The demonstration is not going to show the worst case of the attack (the script and transaction structure required has not been publicly revealed to not give malicious actors even more information about the attack), but it will produce blocks that take orders of magnitude more time to verify than your average block.

The aim of the demonstration is to show users the severity of one of the four severe consensus vulnerabilities that the Great Consensus Cleanup aims to address with BIP 54.

Two more demonstrations will take place at 6 PM EST (10 PM UTC) on April 8th, and at 5 AM EST (9 AM UTC) on April 9th, to allow for Bitcoin users in different global timezones to directly participate as well.

The Signet blockchain is currently at around 32-33 GB, so if you have any device with ample storage space, go ahead and spin up a Signet node to participate.

For your awareness the following software patch was quickly put together for this demonstration and not audited thoroughly (though it is just a basic terminal based-GUI). If you are spinning up a brand new Signet node just for this demonstration on a machine without any funds on it, you should be fine even if you are the paranoid type like me.

For those who don’t want to just poke at log files, AJ Towns provided a patch to the “bitcoin-tui” project, a Terminal based GUI for Bitcoin Core to display the attack blocks during the demonstration. The project creator is working on a proper release in time for the demonstration, but you can also compile it yourself.

Run these commands on Linux (git commands will work on other OSes, and you should be able to find the equivalent CLI commands for your OS easily online):

git clone https://github.com/ajtowns/bitcoin-tui.git

cd bitcoin-tui

git switch 202604-bip54blocks

From there you should be able to just follow the build instructions at the repository here. After compiling, make sure your bitcoind has “server=1” set in the config file, and start up bitcoin-tui. You should find a “Slow Blocks” tab on the right of the top bar.

This post Demonstration of “Attack Blocks” On Bitcoin’s Signet Test Network first appeared on Bitcoin Magazine and is written by Shinobi.

Segregated Witness (BIP by Pieter Wuile, Eric Lombrozo, and Johnson Lau) and Taproot (BIPs by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns) are the two largest changes ever made to the Bitcoin protocol. 

The former fundamentally changed the structure of Bitcoin transactions, and in the process Bitcoin blocks, to address inherent limitations of the previous transaction structure. The latter rearchitectured some aspects of Bitcoin’s scripting language, how complex scripts are structured and validated, and introduced a new scheme for creating cryptographic signatures. 

Those are both massive changes in comparison to say, adding a single opcode like CHECKTIMELOCKVERIFY (CLTV) that does nothing more than allow the receiver to opt into preventing their coins from moving for a certain amount of time. 

These changes were made to address very real shortcomings and limitations of Bitcoin as a system. As a foundational layer to maintain a global consensus on the overall state of Bitcoin, i.e all the unspent coins, Bitcoin is an invaluable and brilliant innovation. As a means to directly enable everyone to transact with those coins, it is woefully inadequate to the task. 

In the years since Segregated Witness and Taproot activated, many of the shortcomings they addressed have been forgotten. The reasons and rationale behind the design decisions have been distorted in a game of telephone as time passed as well. 

Both of these changes to the Bitcoin protocol were solutions to large problems in their own right, but they also each laid the groundwork for solving other problems or making other improvements in the future. 

At a time where many new people have joined the network since these changes activated, it is worth going back over and contextualizing the design choices. 

Segregated Witness (BIP 141¹)

When a Bitcoin transaction spends coins, it references them by the output index and transaction ID (TXID) of the transaction that created them. This ensures that a transaction’s inputs can be uniquely identified and be verified with absolute certainty to have never been spent before. 

Prior to Segregated Witness, a transaction structure looked like this:

[Version] [Inputs] [Outputs] [Locktime]

The TXID is a hash of this data. The problem is the ScriptSig (the signatures, hash preimages, etc.) that prove the transaction is valid are part of the inputs. You can change the little program instructions in a ScriptSig, or even change the cryptographic signatures themselves without invalidating them. 

These “malleations” change TXIDs. This is a big problem for pre-signed transactions. 

The Lightning Network, Ark, Spark, BitVM, Discreet Log Contracts (DLCs), all of these scaling tools depend on pre-signed transactions. They require creating an unsigned funding transaction, and pre-signing all the transactions that guarantee proper execution and safety of funds before signing and confirming the funding transaction. All of these systems use multisignature authentication to guarantee safety regarding double-spending (this will be important later). 

If that funding transaction is malleated, and its translation ID changed before it is confirmed in a block, then all of the pre-signed transactions securing second layer funds are invalidated. None of these tools work in an environment where anyone can alter your funding TXID as it propagates across the network. 

Segregated Witness uses an undefined opcode as a sort of blinding curtain where the ScriptSig previously was in the inputs, and moves all of that data to a new transaction field called the “witness.” The new transaction structure looks like this:

[Version] [Marker/Flag] [Inputs] [Outputs] [Witness] [Locktime]

The “blinding curtain” in the inputs allows old nodes to just mark everything behind it as valid by default, and newer nodes to actually apply the appropriate validation logic. A traditional TXID will now no longer change due to altering ScriptSig data in the witness. This solved the problem for pre-signed transactions, and opened the door to every scaling solution being built today that uses them. 

But the transaction merkle tree in a block header only commits to the traditional TXID of a transaction, this creates a problem. There is no commitment to any witness data in a block. This requires the witness commitment, and the witness transaction ID (WTXID). Much the same way that the normal merkle tree of TXIDs is constructed, a tree of each transaction’s WTXID is constructed and committed to in the coinbase transaction’s witness. 

The only difference is the root of the tree is hashed with a reserve value, and that is what is included in the coinbase witness. This allows for that value to be used in future for committing to other new data fields in consensus rules. Prior to the invention of this witness tree commitment (which was thought of by Luke Dashjr), it was assumed Segregated Witness would require a hardfork due to the transaction structure change and the need for a separate witness commitment in the block header. 

The “blinding curtain” design also allows arbitrary upgrades to the scripting system because all new data is ignored and not validated by nodes not supporting it. This allows a new script system to bypass all restrictions of the legacy script system. Flexibility in upgrade paths here is what allowed Schnorr signatures to be integrated, and will allow quantum resistant signatures if necessary (quantum resistant public keys are generally larger than the legacy 520-byte data item limit, as are signatures). 

Segregated Witness solved the fundamental problem of transaction ID malleability that was holding back the development of scalable second layers that can bring Bitcoin to more users, but it also laid the groundwork for whatever scripting improvements were necessary to support and improve those second layers. 

Schnorr Signatures²

Schnorr signatures were invented in 1991 by Claus Schnorr, and promptly patented. In fact, the ECDSA signature scheme was invented because of the patent on Schnorr signatures. The patent on Schnorr signatures expired in February 2010, a little more than a year after the launch of the Bitcoin network. 

If it weren’t for the patent, it is likely that Satoshi (and the rest of the world) would have just used Schnorr signatures from the start. 

There are a few major benefits that Schnorr signatures have over ECDSA:

• Schnorr signatures are provably secure. The mathematical proof that Schnorr signatures are unforgeable/unbreakable is much stronger, and makes less assumptions, than that for ECDSA. Having stronger security guarantees for the cryptography that rests at the heart of Bitcoin is obviously a huge positive. 
• Schnorr signatures are inherently non-malleable, meaning that the types of issues with ECDSA that allowed altering a signature without invalidating it are simply not possible with Schnorr signatures.
• Schnorr signatures have a linearity that allows for simple and efficient additive key construction, distributed key generation, and distributed signature generation. This allows users to simply “add” individual Schnorr public keys together, and produce signatures for those aggregate public keys together as a group. 

They’re more secure, not malleable by third parties, and open the door to all kinds of efficient and flexible cryptographic schemes to improve multisignature authentication. 

Earlier when discussing transaction malleability I mentioned that everything building off-chain using pre-signed transactions depended on multisignature authentication to secure user funds. This created an implicit scaling ceiling when it comes to shared control of funds. Legacy multisig can only be so big. There are transaction size limits, and for version 0 (Segregated Witness) witnesses, there is a witness size limit. Only so many participants could join a multisignature address, so implicitly only so many participants could share control of funds. 

Schnorr based multisignature schemes escape this limit by aggregating public keys into a single group public key rather than constructing a script with each member key explicitly included individually. Prior to Segregated Witness a multisignature address could only have 15 participants, after Segregated Witness the maximum size possible was 20 participants. 

With Schnorr based multisignature schemes like MuSig⁵ and FROST⁶ these limitations don’t exist, at least at the consensus level. Multisignature scripts can be as large as users want as long as it is practical to coordinate the signing process within a group of the chosen size without disruption or refusal to participate. 

The same properties that allow key aggregation like this also allow for efficient adaptor signatures, a scheme that allows someone to produce a signature that remains invalid until after a secret piece of information is revealed. Those properties also allow for a zero-knowledge proof powered scheme for a signer to produce a signature over a message they cannot see. 

Taproot^3,4

Taproot is an evolution of an old concept called Merkelized Abstract Syntax Trees (MAST)⁷, which is itself a kind of extension of Pay-to-script-hash (P2SH)⁸. P2SH was originally created to deal with two major problems: 

• When using large custom scripts, the resulting unspent output is larger, requiring more space to store in the UTXO set.
• When using large custom scripts, the sender pays a higher fee, as the payment output in their transaction is larger, thereby disincentivizing people from paying potentially more secure custom scripts. 

Rather than explicitly include the entire script in the output, a hash of that script is included instead, and at spending time the recipient must provide the entire script in the input being spent to be verified against the hash. This solved the problem of unspent output storage space, and puts the cost of using larger scripts on the person using them rather than those sending them funds. 

This still leaves a problem. Custom scripts can include multiple ways to spend them, but at spending time the user must still reveal the entirety of the script, including script branches that are not necessary to verify the condition under which the coin is actually spent. This is incredibly space inefficient, and leaves the spending user with a higher cost than is necessary. 

The idea behind MAST is to take each individual spending condition in a multi-branch script and separate them, constructing a merkle tree of each individual spending path. Each path is then hashed, and the root of that merkle tree is the user’s address. At spending time the user simply provides the spending path they are using along with the merkle proof that it is a leaf in the tree, along with the data necessary to satisfy that script. 

This merkle tree structure solves all the same problems as P2SH, as well as optimizing the spending costs of the MAST user (and improves their privacy as well!). 

Taproot takes this concept and integrates in a more privacy-preserving way by taking advantage of the linear properties of Schnorr signatures. Most types of contracts people want to build are going to have an optimistic outcome, where both users simply agree on how to disperse funds. In such cases they can just sign a transaction. Taproot takes the MAST root and “tweaks” a Schnorr public key, resulting in a new public key. By “tweaking” the private key with the same MAST root, you arrive at the corresponding private key to the new public key. 

Users can now either simply spend an output using that tweaked key, leaving no trace that a MAST tree is present at all, or reveal the original public key and MAST root along with the spending path they are actually using. As well, if you wish to not include a key path, a special NUMS (Nothing Up My Sleeve) value which is provably unspendable can be used instead of a normal public key, leaving only MAST scripts as valid spending paths. 

Taking advantage of the design choices of Segregated Witness, Taproot also introduced tapscript, a new scripting system. The major changes here are deactivating OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. They are replaced with OP_CHECKSIGADD, which allows a more efficient way to verify multiple signatures. This in combination with Schnorr key aggregation allows the same multisignature functionality as legacy script. 

Tapscript additionally modifies OP_CHECKSIG and OP_CHECKSIGVERIFY to only work with Schnorr signatures, and introduces OP_SUCESS as a replacement for OP_NOP (undefined opcodes in legacy script). OP_SUCCESS is designed to allow cleaner and safer opcode upgrades than OP_NOP. 

Witness Limits

Two aspects have been left undiscussed until now. The blockweight limit introduced in Segregated Witness, and the witness size limit increase in Taproot. 

Both of these decisions have become a point of contention among a very active minority of power users in the ecosystem. I won’t be discussing the blocksize increase that was part of introducing the blockweight limit, this was a compromise at the time with dissenting users pushing for a hardfork blocksize increase and deemed safe by network participants at the time; but the dynamic of the witness discount itself is important. 

Bitcoin transaction fees are based on the amount of data in a transaction. This has no relationship to the amount of value being transferred. It is solely the number of inputs and outputs (and witnesses) and how many bytes of data they are. Recall earlier I mentioned the fact that the ScriptSig, or signatures and other data, were included in the transaction inputs prior to Segregated Witness. This is a large amount of data included in inputs that is not included in outputs.

That means inputs are more expensive than outputs in a transaction, and by a wide margin. This creates a long term incentive for users to also prefer spending large outputs and creating new change ones as opposed to collecting and spending lots of smaller outputs. This is a long term economic incentive encouraging users to perpetually grow the UTXO set which is necessary for all fully validating nodes. 

The witness discount is meant to correct that price margin, making it miniscule as opposed to massive. This is incredibly important to economically incentivize responsible UTXO management, at least in vacuum for economically rational users simply transacting. 

Taproot removed existing size limits on the witness field of a transaction. In Segregated Witness that limit was 10,000 bytes. This was done because the design of Taproot mitigated the potential construction of expensive to verify transactions, and trying to introduce such limits in tapscript introduced a large degree of complexity in Miniscript. The problem such limits existed to prevent did not impact Taproot, and it introduced complexity for a tool meant to make custom scripts safer and more accessible for both developers and users.

The Big Picture

Both of these changes to Bitcoin removed massive roadblocks to scaling it so more people can use it in a self-custodial way, but they necessitated similarly massive changes to fundamental parts of the protocol. 

I hope now that readers previously unfamiliar with all of these design choices, and the rationale behind them, can appreciate the care and forward-thought with which they were designed. Bitcoin is an amazing innovation, it truly is, but it cannot provide its benefits to anything remotely approaching a sizeable percentage of the population.

Segregated Witness and Taproot laid two cornerstones in the foundation that were absolutely necessary in order to attempt to address Bitcoin’s scalability shortcomings. Without these two proposals, or some alternative protocol changes that addressed the same problems, all of these growing scalability layers and systems we have today would not be here. 

 Lightning, Ark, Spark, BitVM, DLCs – none of them would be possible to build. 

That is the big picture. The Bitcoin of today isn’t perfect, but it actually stands a good chance of scaling to a meaningful enough group of people to make a real impact on the world, to offer a true alternative to people looking to opt out. That is because of these two protocol upgrades, and the very fundamental barriers they removed. 

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki 

[2] https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki 

[3] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki 

[4] https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki 

[5] https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki 

[6] https://github.com/siv2r/bip-frost-signing 

[7] https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki 

[8] https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 

This post The Core Issue: Why Bitcoin Needed A Remodel With Segwit and Taproot first appeared on Bitcoin Magazine and is written by Shinobi.

Cluster Mempool¹ is a complete reworking of how the mempool handles organizing and sorting transactions, conceptualized and implemented by Suhas Daftuar and Pieter Wuille. The design aims to simplify the overall architecture, better align transaction sorting logic with miner incentives, and improve security for second layer protocols. It was merged into Bitcoin Core in PR #33629² on November 25, 2025. 

The mempool is a giant set of pending transactions that your node has to keep track of for a number of reasons: fee estimation, transaction replacement validation, and block construction if you’re a miner. 

This is a lot of different goals for a single function of your node to service. Bitcoin Core up to version 30.0 organizes the mempool in two different ways to help aid in these functions, both from the relative point of view of any given transaction: combined feerate looking forward of the transaction and its children (descendant feerate), and combined feerate looking backwards of the transaction and its parents (ancestor feerate). 

These are used to decide which transactions to evict from your mempool when it’s full, and which to include first when constructing a new block template. 

How Is My Mempool Managed?

When a miner is deciding whether to include a transaction in their block, their node looks at that transaction, and any ancestors that must be confirmed first for it to be valid in a block, and look at the average feerate per byte across all of them together considering the individual fees they paid as a whole. If that group of transactions fits within the blocksize limit while outcompeting others in fees, it is included in the next block. This is done for every transaction.

When your node is deciding which transactions to evict from its mempool when it is full, it looks at each transaction and any children it has, evicting the transaction and all its children if the mempool is already full with transactions (and their descendants) paying a higher feerate. 

Look at the above example graph of transactions, the feerates are shown as such in parentheses (ancestor feerate, descendant feerate). A miner looking at transaction E would likely include it in the next block, a small transaction paying a very high fee with a single small ancestor. However, if a node’s mempool was filling up, it would look at transaction A with two massive children paying a low relative fee, and likely evict it or not accept and keep it if it was just received. 

These two rankings, or orderings, are completely at odds with each other. The mempool should reliably propagate what miners will mine, and users should be confident that their local mempool accurately predicts what miners will mine. 

The mempool functioning in this way is important for:

• Mining decentralization: getting all miners the most profitable set of transactions
• User reliability: accurate and reliable fee estimation and transaction confirmation times
• Second layer security: reliable and accurate execution of second layer protocols’ on-chain enforcement transactions

The current behavior of the mempool does not fully align with the reality of mining incentives, which creates blind spots that can be problematic for second layer security by creating uncertainty as to whether a transaction will make it to a miner, as well as pressure for non-public broadcasting channels to miners, potentially worsening the first problem. 

This is especially problematic when it comes to replacing unconfirmed transactions, either simply to incentivize miners to include a replacement sooner, or as part of a second layer protocol being enforced on-chain. 

Replacement per the existing behavior becomes unpredictable depending on the shape and size of the web of transactions yours is caught in. In a simple fee-bumping situation this can fail to propagate and replace a transaction, even when mining the replacement would be better for a miner. 

In the context of second layer protocols, the current logic allows participants to potentially get necessary ancestor transactions evicted from the mempool, or make it not possible for another participant to submit a necessary child transaction to the mempool under the current rules because of child transactions the malicious participant created, or the eviction of necessary ancestor transactions. 

All of these problems are the result of these inconsistent inclusion and eviction rankings and the incentive misalignments they create. Having a single global ranking would fix these issues, but globally reordering the entire mempool for every new transaction is impractical. 

It’s All Just A Graph

Transactions that depend on each other are a graph, or a directed series of “paths.” When a transaction spends outputs created by another in the past, it is linked with that past transaction. When it additionally spends outputs created by a second past transaction, it links both of the historical transactions together. 

When unconfirmed, chains of transactions like this must have the earlier transactions confirmed first for the later ones to be valid. After all, you can’t spend outputs that haven’t been created yet. 

This is an important concept for understanding the mempool, it is explicitly ordered directionally. 

It’s all just a graph. 

Chunks Make Clusters Make Mempools

In cluster mempool, the concept of a cluster is a group of unconfirmed transactions that are directly related to each other, i.e. spending outputs created by others in the cluster or vice versa. This becomes a fundamental unit of the new mempool architecture. Analyzing and ordering the entire mempool is an impractical task, but analyzing and ordering clusters is a much more manageable one. 

Each cluster is broken down into chunks, small sets of transactions from the cluster, which are then sorted in order of highest feerate per byte to lowest, respecting the directional dependencies. So for instance, let’s say from highest to lowest feerate the chunks in cluster (A) are: [A,D], [B,E], [C,F], [G, J], and last [I, H]. 

This allows pre-sorting all of these chunks and clusters, and more efficient sorting of the whole mempool in the process. 

Miners can now simply grab the highest feerate chunks from every cluster and put them into their template, if there is still room they can go down to the next highest feerate chunks, continuing until the block is roughly full and just needs to figure out the last few transactions it can fit. This is roughly the optimal block template construction method assuming access to all available transactions. 

When nodes’ mempools get full, they can simply grab the lowest feerate chunks from every cluster, and start evicting those from their mempool until it is not over the configured limit. If that was not enough, it moves on to the next lowest feerate chunks, and so on, until it is within its mempool limits. Done this way it removes strange edge cases out of alignment with mining incentives. 

Replacement logic is also drastically simplified. Compare cluster (A) to cluster (B) where transaction K has replaced G, I, J, and H. The only criteria that needs to be met is the new chunk [K] must have a higher chunk feerate than [G, J] and [I, H], [K] must pay more in total fees than [G, J, I, H], and K cannot go over an upper limit of how many transactions it is replacing. 

In a cluster paradigm all of these different uses are in alignment with each other. 

The New Mempool

This new architecture allows us to simplify transaction group limits, removing previous limitations on how many unconfirmed ancestors a transaction in the mempool can have and replacing them with a global cluster limit of 64 transactions and 101 kvB per cluster. 

This limit is necessary in order to keep the computational cost of pre-sorting the clusters and their chunks low enough to be practical for nodes to perform on a constant basis. 

This is the real key insight of cluster mempool. By keeping the chunks and clusters relatively small, you simultaneously make the construction of an optimal block template cheap, simplify transaction replacement logic (fee-bumping) and therefore improve second layer security, and fix eviction logic, all at once. 

No more expensive and slow on the fly computation for template building, or unpredictable behavior in fee-bumping. By fixing the misalignment of incentives in how the mempool was managing transaction organization in different situations, the mempool functions better for everyone. 

Cluster mempool is a project that has been years-long in the making, and will make a material impact on ensuring profitable block templates are open to all miners, that second layer protocols have sound and predictable mempool behaviors to build on, and that Bitcoin can continue functioning as a decentralized monetary system. 

For those interesting in diving deeper into the nitty gritty of how cluster mempool is implemented and works under the hood, here are two Delving Bitcoin threads you can read:

High Level Implementation Overview (With Design Rationale): https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393 

How Cluster Mempool Feerate Diagrams Work: https://delvingbitcoin.org/t/mempool-incentive-compatibility/553 

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[1] https://github.com/bitcoin/bitcoin/issues/27677 

[2] https://github.com/bitcoin/bitcoin/pull/33629 

This post The Core Issue: Cluster Mempool, Problems Are Easier In Chunks first appeared on Bitcoin Magazine and is written by Shinobi.

Bitcoin is a distributed system. 

That means there is no center. To make a pun, no “core.” Bitcoin exists because of everyone participating in some way; buying and hodling, sending and receiving, running a node, mining, building some service or protocol on top of it. It exists as the culmination of everyone adding their contributing piece of the whole. 

But underneath all of those contributions and pieces, Bitcoin is ultimately a network run by software. Without that software, no one can buy and hodl, no one can send and receive, or run a node, or mine, or contribute any piece to form any whole. Without software, there is no Bitcoin. 

Software doesn’t write itself. People have to write that software. 

Many people have filled that role over the years. The first was Satoshi Nakamoto, Bitcoin’s pseudonymous creator. After him came people like Martti Malmi, Hal Finney, and many others in the years after. All of them are why Bitcoin is still here functioning today. 

Because software development is such a highly specialized field, much of the work of Bitcoin developers goes unnoticed, unappreciated, and in many cases not even understood by a large swath of the people around the world who own and use bitcoin. 

This issue aims to bring a greater depth of understanding of the work done on Bitcoin Core, the predominant software implementation of the Bitcoin protocol. The articles inside go through past work done to improve Bitcoin Core, as well as the Bitcoin protocol in general, work coming to fruition in the near future, and some of the general thinking behind how developers approach different problems.

Many of the articles are written by developers contributing to Bitcoin Core themselves. 

It has been my absolute pleasure to work on taking this issue from an idea to the physical copy you hold in your hand right now, and help these developers to explain their work to you themselves. 

Hopefully you walk away with a greater understanding of what it has taken to keep Bitcoin functioning all of these years, and what it will take for many years to come. 

-Shinobi

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

This post The Core Issue: Letter From The Editor first appeared on Bitcoin Magazine and is written by Shinobi.

DMND, a new mining pool built around Stratum V2 which began taking applicants for a soft private launch earlier this year, is now open for all miners to create accounts. Miners can register here to begin onboarding. 

DMND’s full public launch comes after a successful SOC 2 Type 2 audit, proving compliance with security policies necessary for large scale miners. 

“With our SOC 2 Type 2 compliance and streamlined business verification practices, the DMND pool is built for operators who value security, transparency, and professional-grade standards,” said DMND Co-Founder & CEO, Alejandro De La Torre. “Combined with miner-controlled block construction, we’re enabling miners to reclaim meaningful control over the network.”

Stratum V2 support takes a significant step on the road to further decentralization of different functionality in the mining industry, namely block template construction, the process of selecting transactions to include in the block being mined. 

Stratum V2 provides a mechanism to defend Bitcoin’s censorship resistance, allowing individual miners to produce their own block templates while mining with supporting pools (as well as sourcing templates from any third party provider they choose who is operating Stratum V2). Additionally, Stratum V2’s end-to-end encryption protects miners from hashrate hijacking attacks which can silently siphon a miner’s revenue. 

DMND’s public launch provides miners with another step forward for Stratum V2 on the network, and for progress towards improving the mining ecosystem’s level of decentralization. 

This post DMND Pool Now Open To All Miners, With SOC 2 Compliance and Stratum V2 Support first appeared on Bitcoin Magazine and is written by Shinobi.

Brink, the Bitcoin development organization, recently funded the first ever independent security audit of Bitcoin Core conducted by a third party (the full report is available here). The audit was conducted by Quarkslab, a software security firm, with the help of the Open Source Technology Improvement Fund (OSTIF) and collaboration with Bitcoin Core developers Niklas Gögge, from Brink, and Antoine Poinsot, from Chaincode Labs. 

This security audit marks a milestone in the development history of Bitcoin Core, the most widely adopted and reference client of the Bitcoin network and protocol. 

While Bitcoin Core security policies and practices have been steadily hardened and revised to be more thorough and comprehensive over the last few years, an external audit by a third party specialized in security review is a new bar to meet. It was met. 

The audit involved manual code review, static and dynamic analysis with automated tools, and advanced fuzz testing, which takes automatically generated input and runs it through different code paths attempting to reveal unexpected or detrimental behavior. 

No critical, high, or medium-severity bugs were discovered in the audit. Two low-severity issues were different, and thirteen other issues that are not classified as vulnerabilities under Bitcoin Core’s vulnerability classification criteria. 

The entire process also resulted in improvements in Bitcoin Core’s testing infrastructure, including new fuzz testing infrastructure for block connection and chain reorganization scenarios, a new area to be covered by testing, file system improvements speeding up and improving fuzz testing in general, new utilities for testing back sliding code performance, and suggestions for improving code readability for reviewers and new developers. 

Some of these improvements are already being worked on for eventual review and merging into the Bitcoin Core repository. 

The results of this independent security audit have reinforced that Bitcoin Core’s improvements over recent years in security policy, testing, and overall quality review have had a meaningful impact on the project. 

This post Brink Funds First Third Party Security Audit of Bitcoin Core By Quarkslab first appeared on Bitcoin Magazine and is written by Shinobi.