Quantum this, quantum that…who put a stupid cat on-chain!?
Ahem.
Alright, let’s be serious. The threat that a viable, actually functioning, quantum computer would pose to Bitcoin if it were to be built is very serious. It is the concrete example of an existential threat, in every sense of the word.
One of the bedrock foundations that Bitcoin rests upon is the assumption of a functioning cryptographic system that can be used to produce unforgeable signatures, i.e. that if you follow that system’s protocol properly when signing things, there is no way that anyone but a bitcoin’s rightful owner could produce a signature needed to spend it unless the rightful owner failed to secure their private key from theft.
Quantum computers toss that right out the window. There goes the integrity of the entire mechanism that is used for owners of bitcoin to authenticate their ownership for the protocol to process their legitimately authorized transactions, and ONLY their legitimately authorized transactions. There’s no way for anyone to actually own anything in the context of the Bitcoin protocol if that assumption breaks.
Bitcoin breaks if that assumption breaks.
Thankfully, there are many different cryptographic systems that exist, and not all of them rest on assumptions that a quantum computer breaks. That’s the good news. The bad news is that its all a set of tradeoffs, none of them are ideal, and there are going to be some hard choices that have to be made.
But there are solutions to just about every one of the problems that a viable quantum computer would create…except the problem of choosing which solutions to use. So in light of that, here is The Quantum Issue.
This issue is a lot more structured than most past issues, and that is to ensure that it guides a reader through the entirety of the problem space and solution space without assuming any prior understanding (this is a very deep and technical subject).
The first set of articles goes through the general issue of quantum computing itself, how it differs from classical computing, why that matters, how likely it is one is developed soon, etc.
The second set examines Bitcoin’s exposure. How is it exposed? How badly is it exposed? How can that degree of exposure change?
The third set examines concrete (or developed enough to not be too hard to get to a concrete place) solutions to securing your bitcoin in a quantum safe way, and handling a network wide migration to those solutions.
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Quantum Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
Last week on August 14th DMND, the Stratum V2 mining pool, announced an integration with Mempool Accelerator to introduce new transaction acceleration functionality to Stratum V2 miners. This will put individual miners in control of transaction acceleration and prioritization.
This is a fundamental shakeup to the legacy model of a transaction accelerator. These products have been historically offered by mining pools, rather than actual miners, and as such the pools have traditionally been the ones to both decide which transactions to prioritize in their templates and pocket the additional revenue for accelerating them.
Now, individual miners at DMND can handle the prioritization selection using Stratum V2, and when a block template containing such accelerated transactions is mined, the individual miner who found that block collects additional revenue for the acceleration.
“Our premise is simple: when miners build their own blocks through DMND’s Stratum V2 implementation, they unlock revenue streams that were never available to them before,” said Alejandro De La Torre, CEO of DMND. “Accelerated transactions are one of those streams. The pool used to prioritise them and the pool used to collect for them. On DMND the miner does both. It is a paradigm shift in how miners earn.”
This is a first of its kind integration of a transaction accelerator system, and opens the door for new revenue streams for individual miners. Now that this type of direct revenue sharing with additional streams of income has been demonstrated, it begs the question of why are other mining pools that own or integrate with accelerator services not doing similar revenue sharing?
This type of design and revenue sharing was made directly possible by Stratum V2.
“Mempool Accelerator lets anyone get their stuck transaction confirmed by paying an out of band fee, which prioritizes their transaction with over 80% of the network hashrate. DMND’s integration is the first of its kind, Stratum V2 miners using Job Declaration can now earn their share of that revenue.” – Orange Surf, Head of Strategy & Research at mempool.space
TLDR: Coldcard MK2, MK3, MK4, MK5 and Q are being drained. A bug lets attackers find your seed phrase without any action on your part. Only wallets generated using the dice roll method are safe, assuming you rolled at least 50 dice. If you don’t know, don’t remember, or aren’t sure, move your funds immediately.
This is a critical issue that requires immediate action. If you used a Coldcard to generate a word seed and did NOT use the recommended 50+ dice rolls to provide your own entropy after the end of 2020, your word seed is not secure. It was generated without a sufficient amount of randomness, and can be brute forced by a malicious attacker. Wallets are actively being drained now. This issue also affects any ephemeral keys and session keys for Clone Coldcard or Key Teleport features, and BIP 85 seeds generated from a compromised seed. YOU MUST STILL MOVE YOUR FUNDS.
This attack is being actively exploited, with around 1000 BTC seen moving on-chain connected to the vulnerability.
Breath, and relax. You must move your funds to a new word seed, or a word seed generated by a different device, in order to secure your funds.
– If you have another hardware wallet that is not a Coldcard, send your funds there. This is the quickest and simplest way to get them someplace secure.
– If you do not have another hardware wallet, and only have a Coldcard, generate a passphrase using at MINIMUM six seed words from the BIP 39 word list. Use this guide to select your words for the passphrase,do NOT pick them yourself. Check your wallet fingerprint (or an address), power down your device, restart it and re-enter the passphrase. Confirm that the fingerprint (or address) matches, and send your funds to the passphrase wallet. This is not a permanent solution. This is simply giving you enough security that an attacker will not be able to brute force your keys in a matter of days, and you can generate a new seed without being in a state of panic. Make sure your passphrase is written down securely.
– If you have no other options, or are uncomfortable with using the device at all, Nunchuck wallet available on mobile and desktop. Take your time, don’t rush yourself too fast, and make sure that all of your backups are done properly. After you have verified backups, send your funds to this wallet. If you are managing significant sums, Nunchuck has support for multisig. You can create one using multiple devices. Blockstream Green and Bluewallet are two other options for software wallets.
Once your funds are secure, take a minute and relax. Coldcards are still safe to use as long as the word seed is generated securely. A firmware patch has been released here. Any word seed generated after this firmware update should be secure (and you can use the dice roll option too). If you have transferred your funds to a hot wallet, or something less secure, your Coldcard is safe to use after applying the firmware update and generating a new seed.
Once you have secured your own funds, stop and take stock. Reach out proactively to anyone you know who might be using a Coldcard that was vulnerable when they generated their seed. Inform them of the issue, and if needed (and you are capable) help walk them through migrating their funds. Everyone doesn’t pay attention to Bitcoin news on a regular basis, so many people might be unaware that they are even vulnerable.
Disclaimer:This article is for informational and educational purposes only and does not constitute financial, legal, or technical advice. Readers are solely responsible for managing their own private keys and executing fund transfers. Bitcoin Magazine and the author assume no liability for any loss of funds, technical errors, or operational missteps resulting from actions taken based on this content. Always independently verify security alerts directly through official project channels before taking action.
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.”
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.
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.
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.
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.
Our Quantum Bitcoin Summit last July helped push bitcoin’s quantum discussion forward.
Today we're publishing Bitcoin's Quantum Readiness, a living paper on bitcoin's exposure, mitigation menu, upgrade paths, and plausible transition scenarios. pic.twitter.com/XHdiSJFrlB
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.
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.
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):
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.
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 1411)
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:
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 Signatures2
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 MuSig5 and FROST6 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.
Taproot3,4
Taproot is an evolution of an old concept called Merkelized Abstract Syntax Trees (MAST)7, which is itself a kind of extension of Pay-to-script-hash (P2SH)8. 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.
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.
Cluster Mempool1 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 #336292 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:
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.
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.
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.
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.
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.
Today marks seventeen years since Satoshi Nakamoto’s publication of the Bitcoin Whitepaper on the cryptography mailing list in 2008. Back then Bitcoin was nothing more than a proposal for a new niche technology, the latest in a long lineage of niche technologies created by the cypherpunks of the 1990s.
Bitcoin has gone through many massive transformations since that day 17 years ago. It went from a niche internet collectible, to a decentralized network powering illegal dark net markets, to a mainstream speculative investment for retail, to Wall Street and governments all over the world’s favorite new asset class. We have all had front row seats to the first explosive global technological revolution to the internet, and it’s been a wild ride.
On this anniversary I think it’s important to touch on a concept that is very relevant, POSIWID, or the Purpose Of A System Is What It Does. The basic idea is that when you have a complex system, it is pointless to try to define it based on what you want it to do, what really matters is what the pieces of that complex system are actually doing. That is all that matters at the end of the day.
We have once again found ourselves in a time period where people are calling back to the whitepaper as a placeholder for some kind of founding document, or definition, or blueprint. The whitepaper is none of those things. It is simply a high level abstract explanation of a Proof-of-Work blockchain being used to implement a digital currency. It is the idea of a cart with wheels, versus the actual blueprint of the cart (the source code).
Bitcoiners seem to periodically fixate on the whitepaper in this manner, and inevitably use that as a justification for acting antagonistic towards some use case or idea of improving Bitcoin that they disagree with. Maybe we will eventually get past this, maybe we won’t, but it is an unhealthy attitude to have towards such a potentially impactful technology such as Bitcoin.
People didn’t recite the writings and speeches of Alexander Graham Bell when digital modems were invented to allow the first tendrils of the early internet to reach out between devices and facilitate digital signals flowing between them. They embraced it as a valuable technological innovation, and in the world today that dynamic has completely inverted itself. Most telephonic signals are now actually conveyed by communication mediums specifically constructed for digital communications.
Telephone networks were used to bootstrap the digital medium of the modern internet in a way that Alexander Graham Bell might have had only the barest inklings of, reshaping the entire world in ways that would have been impossible to conceive for people of his generation.
Satoshi did not give us a founding document to be shackled and constrained by when he released the whitepaper, he gave us a high level description of the software that followed.
That is the actual gift he gave us, the software. And he gave it to us completely freely, open-source, to do with what we decide to do.
“BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it’s easy for lots of users and small devices.” -Satoshi Nakamoto, 2010
This quote is always brought up in the context of the blocksize limit, or Bitcoin enabling multiple functionalities, but the thing that has always stood out the most to me is “users might get.” In the end before his disappearance, Satoshi is clearly being explicitly deferential to the wishes of users, and in the context of a critical and foundational decision like the blocksize limit.
Bitcoin isn’t Satoshi’s anymore, it’s ours, and collectively with how we actually use our bitcoin, we decide what the purpose of the system is. It’s important to remember that.
In computing, a denial-of-service attack (DoS attack; UK: /dɒs/ doss US: /dɑːs/ daas[1]) is a cyberattack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to a network. -The Wikipedia definition of denial-of-service attack.
This is a very basic concept. Someone makes use of their own resources to disrupt the functioning of other machines on a network.
DoS attacks have been an issue for as long as the internet existed. One of the commonly argued “first Distributed Denial-of-service (DDoS) attacks” was against the Internet Service Provider (ISP) Panix in the mid-90s. There were of course many prior technical examples on older internet services, but this was one of, if not the, first major examples of such an attack on the modern World Wide Web.
This attack had numerous computers start to initiate a Transmission Control Protocol (TCP) connection with the ISPs servers, but never finishing the handshake protocol that finalized the connection. This consumes the server’s resources for managing network connections and prevents honest users from accessing the internet through the ISP’s servers.
Ever since this “initial” DDoS attack, they have been as common on the internet as storms are in nature, a regular occurrence that massive pieces of internet infrastructure have been built to defend against.
The Blockchain
The blockchain is one of the core components of Bitcoin, and a required dependency for Bitcoin’s functionality as a distributed ledger. I am sure many people in this space would call so-called “spam” transactions a DoS attack on the Bitcoin blockchain. In order to call it that, you would have to define the “service” that the blockchain is offering as a system, and explain how spam transactions are denying that service to others in a way not intended by the design of the system.
I’d wager a bet that most people who believe spam is a DoS attack would say something like “the service the blockchain offers is processing financial transactions, and spam takes space away from people trying to do that.” The problem is, that is not specifically the service the blockchain offers.
The service it actually offers is the confirmation of any consensus valid transaction through a real-time auction that periodically settles whenever a miner finds a block. If your transaction is consensus valid, and you have bid a high enough fee for a miner to include your transaction in a block, you are using the service the blockchain provides exactly as designed.
This was a conscious design decision made over years during the “Block Size Wars” and finalized in the activation of Segregated Witness and the rejection of the Segwit2x blocksize increase through a hard fork pushed by major companies at the time. The blockchain would function by prioritizing the highest bidding fee transactions, and users would be free to compete in that auction. This is how blockspace would be allocated, with a global restriction to protect verifiability and a free market pricing mechanism.
Nothing about a transaction some arbitrarily define as “spam” winning in this open auction is a DoS of the blockchain. It is a user making use of that resource in the way they are supposed to, participating in the auction with everyone else.
The Relay Network
Many, if not most, Bitcoin nodes offer transaction relay as a service to the rest of the network. If you broadcast your transactions to your peers on the network, they will forward them on to their peers, and so on. Because the peering logic deciding which nodes to peer with maintains wide connectivity, this service allows transactions to propagate across the network very quickly, and specifically allows them to propagate to all mining nodes.
Another service is block relay, propagating valid blocks as they are found in the same manner. This has been highly optimized over the years, to the point where most of the time an entire block is never actually relayed, just a shorthand “sketch” of the blockheader and the transactions included in it so you can reconstruct them from your own mempool. In other words, optimizations in block relay depend on a transaction relay functioning properly and propagating all valid and likely to be mined transactions.
When nodes do not have transactions in a block already in their mempool, they must request them from neighboring nodes, taking more time to validate the block in the process. They also explicitly forward those transactions along with the block sketch to other peers in case they are missing them, wasting bandwidth. The more nodes filtering transactions they classify as spam, the longer it takes blocks including those filtered transactions to propagate across the network.
Transaction filtering actively seeks to disrupt both of these services, in the case of transaction relay failing miserably to prevent them from propagating to miners, and in the case of block propagation having a marginal but noticeable performance degradation the more nodes on the network are filtering transactions.
These node policies have the explicit purpose of degrading the network service of propagating transactions to miners and the rest of the network, and view the degradation of block propagation as a penalty to miners who choose to include valid transactions they are filtering. They seek to create a degradation of service as a goal, and view the degradation of another service resulting from that attempt as a positive.
This actually is a DoS attack, in that it actually is degrading a network service contrary to the design of the system.
Where From Here?
The entire saga of Knotz vs. Core, or “Spammers” vs. “Filterers”, has been nothing more than a miserably ineffective and failed DoS attack on the Bitcoin network. Filters do absolutely nothing to prevent filtered transactions from being included in blocks. The goal of disrupting transaction propagation to miners has had no success whatsoever, and the degradation of block relay has been marginal enough to not be a disincentive to miners.
I see this as a huge demonstration of Bitcoin’s robustness and resilience against attempted censorship and disruption on the level of the Bitcoin Network itself.
So now what?
A BIP by an anonymous author has been put forward to enact a temporary softfork that would expire after roughly a year making numerous ways to include “spam” in Bitcoin transactions consensus invalid through that time period. After realizing the DoS attack on the peer-to-peer network has been a total failure, filter supporters have moved to consensus changes, as many of them were told would be necessary over two years ago.
Will this actually solve the problem? No, it won’t. It will simply force people who wish to submit “spam” to this forked network, if they actually follow through on implementing it, to use fake ScriptPubKeys to encode their data in unspendable outputs that will bloat the UTXO set.
So even if this fork was met with resounding support, activated successfully, and did not result in a chainsplit, it would still not achieve the stated goal and leave “spammers” no option but to “spam” in the most damaging way to the network possible.
Recent threats against the rights of bitcoiners to transact in the manner they deem fit led to the creation of Save Our Wallets. Done in collaboration with the Bitcoin Policy Institute, CoinCenter, the Bitcoin Design Foundation, and many regional Bitcoin hubs around the United States, the organization recently launched the “Satoshi Needs You!” campaign.
Satoshi needs all of you to rally together to ensure that the Blockchain Regulatory Certainty Act (BRCA) provisions are included in the coming version of the CLARITY Act, to ensure that self-custodial software tools in the Bitcoin ecosystem remain a protected thing, unencumbered by financial regulations designed to restrict businesses actually taking control of users’ funds.
The trials this summer prosecuted by the Department of Justice (DOJ) against the developers of Samourai Wallet and Tornado Cash have set dangerous precedents by prosecuting developers of open-source and self-custodial software, which at no time gave developers control over user funds in any way, and flies directly against standing guidance from both the DOJ as well as FinCEN, the regulator in charge of the application of the relevant regulations from both cases.
The “Satoshi Needs You!” campaign aims to raise awareness of the current threats to bitcoiners’ rights and rally people to get involved in the push to cement these rights in explicit regulation.
“This is a moment of both great danger and great opportunity for the bitcoin network” said Kyle Olney, co-founder of SaveOurWallets.org. “We can’t take anything for granted until our fundamental rights to economic liberty in the digital realm have been codified into law. We need EVERY bitcoiner to get involved, contact their representatives in Washington DC, and ensure this congress continues to execute on pro-Bitcoin policy. We have a responsibility to fight for our freedoms like the right to transact, and to pass those rights on for future generations.”
Visit SaveOurWallets.org to learn more about the CLARITY Act and how you can get involved in the fight to include the BRCA provisions.
Wall Street has unequivocally arrived. The long awaited phase shift is here. We have discussed for years what this time period and shift will be like, many cheering it on in anticipation of the economic implications and shockwave it would cause in terms of liquidity and price movement.
In the last few years it has undeniably come to dominate the narrative, shaping dialogue and focus across the entire ecosystem. Where before large communities of people would spring up around technological innovations, or philosophical schools of thought on how Bitcoin can positively shape the direction of the world in a time of tumultuous change and metaphorical ground shifting out from under us, now the cultural zeitgeist is driven by the phenomenon of treasury companies.
There is an entire wave of recent entrants into the space who have never held their own keys, never directly interacted with the protocol themselves at all, they have simply acquired proxies such as treasury company equity or ETFs. This is a massive cultural, and philosophical/logistical shift, for the entire ecosystem. It is not going to wind itself back. This is a new presence and a new attitude that we are going to have to confront. It’s here to stay.
So what are the implications of that? Bitcoin is a peer-to-peer system, its very essence and nature is defined by the people who choose to participate directly in that system itself. By those who do interface with the protocol directly, who do not resort to TradFi wrappers such as ETF products and equity in holding companies.
It is one giant inter-subjective hallucination manifested through and verified with software. So what does it mean that a massive section of the population who chooses to interact with it financially avoid ever participating in that hallucination themselves? What does that mean for its nature, its functioning?
That is very much an existential question, and one that we are all going to have to grapple with over the coming years. Bitcoin is for anyone, and there is nothing we can do to stop people from using it in whatever fashion they so choose, no matter what the wider implications of those people’s choices might be.
Economic Consensus And Wall Street
The nature of Bitcoin, i.e. the consensus rules that nodes (and therefore its users) enforce, is defined by those who actually engage in economic activity on the network. In its most abstract sense Bitcoin is just a system composed of people “just doing things,” and the only reason that it is a singular coherent system, rather than a random collection of individuals doing very different and incompatible things, is because of the economic incentive to do the same thing.
Think of it in some ways as similar to a black hole. That black hole forms in the first place after reaching a point of “critical mass”, after which it literally implodes on itself and the resulting gravitational force begins pulling in everything around it, increasing its mass, and expanding the radius in which things are sucked into its dark maw.
The incentive to voluntarily choose to participate in one particular “set of rules” over another is the “black hole” of Bitcoin, and its gravitational pull is directly proportional to the economic mass of the system as it exists today. Unlike a black hole though, it is not truly a “singular” thing. Rather it is a number of different things (or entities), all holding themselves together to emulate being a singular thing. Unlike a blackhole, these entities can choose to defy the incentives to remain together, or follow counter-incentives against doing so, and enforce or follow different rules.
The reason this does not frequently happen at scale (such as the fork of Bitcoin Cash in 2017), is the complexity of coordinating all of those individual entities switching to the same thing at the same time, so as to maintain the same collective “gravitational force” as they had under the previous rules.
So what happens when the number of those entities starts shrinking? What happens when they condense and combine, and you wind up with fewer and fewer larger ones?
That complexity of coordination starts getting less complex.
Centralization Is Efficient, But It is Poison to Bitcoin
Bitcoin’s entire promise is to be an apolitical and neutral platform for economic activity. It is to be an unshifting and solid foundation for you to stand surely on, devoid of concerns that it could shift out from under your feet and throw you into economic chaos. ‘
That entire promise of stability is purely a result of Bitcoin being sufficiently distributed, i.e. being composed of independent actors performing their own self-validation of the system in large enough numbers that their ability of coordinating amongst themselves to change fundamental properties of the system is either exceedingly difficult, or literally impossible.
When the set of economic actors participating in self-validation collapses in size, when it turns into fewer and fewer entities operating on behalf of other stakeholders, that promise of stability and neutrality collapses in lockstep with it. Bitcoin must maintain some minimum degree of distribution of self-validating actors, that make up a substantial portion of economic activity, or else the core promise of stability and neutrality evaporate.
Wall Street isn’t going away, so this is something that we are going to have to confront. There is no shaming them away, or chasing them off. That is simply not possible in a system like Bitcoin, that at least for now, is robust in its distribution and decentralization. This is a war of incentives and counter-incentives.
We must create positive incentives to encourage more direct self-validating use of Bitcoin rather than legacy financial wrappers like ETFs and treasury companies, or Bitcoin will be confronted with a fundamental crisis as to whether its core promise was ever really possible.
How did 115 orphaned children end up on their first bus ride to a zoo to celebrate a real-world Bitcoin transaction 15 years ago? It’s a question I found myself asking in disbelief as I coordinated their entrance at the Uganda Wildlife Education Centre — commonly known as the Entebbe Zoo — on Bitcoin Pizza Day, May 22. The morning sun was warm, and the air buzzed with excitement and laughter. Children who had rarely strayed beyond their rural village in Bugiri, Uganda, were now getting off buses, eyes wide at the expectation of giraffes and elephants. Many of these kids had never even heard of a zoo before, let alone seen one. Yet here they were, grinning ear to ear after breakfast, ready to celebrate a quirky Bitcoin holiday. How on Earth did we get here?
As I watched those 115 children — children from the Orphans of Uganda Children Center — marvel at animals and enjoy their very first pizza party later that afternoon, I felt a swell of emotions in my chest. I saw joy, wonder, and a sense of belonging wash over kids who have known too much hardship in their young lives. For me, this wasn’t just a fun day out. It was the culmination of an incredible journey of hope, community, and innovation. Bitcoin Pizza Day commemorates the first real-world Bitcoin transaction when, back in 2010, Lazlo famously bought two pizzas for 10,000 BTC. For most Bitcoiners, it’s a lighthearted celebration. But for us in Uganda this year, Pizza Day became something deeply personal — a day when an internet myth reached into our world and made a real difference. Bitcoin paid for those pizzas the children ate, yes. But it also paid for the buses, the zoo tickets, and the chance for these orphans to leave their district for the first time in their lives. It was, in every sense, the biggest Bitcoin Pizza Day celebration ever seen.
The Road to Bitcoin Pizza Day
Standing in that zoo, I couldn’t help but reflect on the road that led us here. Just months before this event, our team, led by Orphanage Director Isma, achieved something I once thought nearly impossible. Feeding over a hundred children has always been our largest expense here at the orphanage, and for the past years, we’ve been experimenting with a new idea: What if we could do it all with bitcoin? Sat by sat, we were building a small Bitcoin economy around the orphanage. In fact, by consistently honoring our commitments and showing the usefulness of this strange digital money, we even earned the trust of our most important supplier. I’m proud to say that our loyal food supplier, the woman who sells us bulk maize, beans, and other staples, now accepts bitcoin as payment. That was a big win for us. It meant we could buy food for the kids directly with the sats donated by generous Bitcoiners worldwide, without always having to convert to cash. It meant our bitcoin could stay bitcoin from donor to dinner, closing the loop in our little circular economy.
That achievement didn’t happen overnight. It was the result of months of education and relationship-building in our community. We knew that to really help these children long term, we needed more than one-off donations; we needed sustainability. So we set out ambitious goals for ourselves: make the orphanage self-sustaining and integrate bitcoin into daily life in Bugiri.
We brainstormed ideas like starting a poultry farm for eggs to improve the children’s nutrition and generate income, or acquiring sewing machines so the older kids could learn tailoring skills, thanks to Bitcoin Dada ladies in Uganda. Each initiative was aimed at empowering the orphans with tools and knowledge to eventually take care of themselves. And woven through all these plans was Bitcoin, the monetary network that allowed a global community of supporters to be part of our local solutions. We wanted the shopkeepers, market vendors, and school teachers in our town to see the same potential we saw. If more of our neighbors would trade in bitcoin — if they could save it, spend it, and trust it — then the orphanage’s lifeline wouldn’t depend solely on distant donors. It would be rooted in the community, powered by the people and businesses right here at home. Little by little, that’s exactly what is happening. Our Bitcoin Kampala project has doubled down on outreach in the village, showing anyone who listens how to download a Bitcoin wallet, how to make a Lightning payment, and why this technology isn’t just “internet money” but something that can change their lives. One by one, new allies are coming on board. Our food vendor was one; a local clinic that treats our kids became another; the local engineering company joined the freedom train, too. The circle of trust in Bitcoin is widening.
My own trust in Bitcoin had been cemented by one particularly urgent moment. I’ll never forget the day I truly saw the power of this technology again beyond my personal life. One morning not long ago, the orphanage’s food store was empty — we had no food left to cook for the children’s lunch. The usual funding we relied on was delayed, and local stores wouldn’t give us any more on credit. In desperation, Isma and I reached out to a friend in South America. I told him about our situation, and he didn’t hesitate. He sent a $60 bitcoin donation across the world to Isma immediately. Within seconds, the transaction popped up on Isma’s phone — confirmed. He walked into our now Bitcoin food vendor’s shop that very morning, showed the shopkeeper the bitcoin his wallet, and he worked out a quick exchange in order to pay for just enough maize and beans for lunch. By 1:00 p.m., the children were eating a hot meal. There were no banks involved, no remittance offices open (it was a Sunday, after all), no waiting until the next day for funds to clear. Just hungry kids at an orphanage in Uganda and a caring friend in South America connected by this borderless money. That day, bitcoin literally put food on empty plates in the nick of time. I often think back to how miraculous it felt. For the first time, I had a tool that could summon help from anywhere on the planet, just when we needed it the most.
In fact, the very first bitcoin donations I’d ever received personally had gotten me to the biggest Bitcoin conference in Europe within a month; still, this lunch meal paid instantly was way more amazing than anything I’d ever known about Bitcoin. From day one, Bitcoin proved its worth to me not in theory, but in person: Hungry children eat because of it?! After that, I was convinced that this technology was more than just an idea for rich investors or tech enthusiasts. It was a lifeline for the forgotten ones in society — like our kids out in Bugiri, many of whom had been orphaned by disease or tragedy and had nobody but us to care for them. Bitcoin was helping us keep them alive and healthy.
It still amazes me how an unlikely series of events brought us to this point. Truth be told, I never set out deliberately to be part of a “Bitcoin orphanage project” until a Machankura Ugandan representative named Satstacker connected me with the orphanage. A couple of years ago, I was just a Bitcoiner in Kampala, running a little educational meetup under the moniker Gorilla Sats. I was inspired by places like El Zonte in El Salvador (the famous “Bitcoin Beach”) and similar projects in South Africa and Brazil. My goal after attending BTC Prague in 2023 was to spark a Bitcoin circular economy somewhere in Uganda — anywhere. Who knew it would end up being in a rural orphanage?
Originally, I thought Makerere University students might lead the way — or entrepreneurs. I hosted talks, met fellow enthusiasts, and dreamed big. But fate complemented all the above efforts in the form of a Twitter contact: I learned about this orphanage out in the Bugiri district that was struggling, and Isma, the caretaker, was curious about Bitcoin. These were genuine, honest people doing good work with almost no resources. They had heard that Bitcoin might help them receive donations more easily. So we connected. I taught them what I knew, helped set up a Lightning wallet, taught them self-custody, and shared their story online. What happened next was beyond my expectations. Bitcoiners from around the world — people we’d never met — started sending support. What started as a trickle of sats soon grew into a stream of love and generosity from every corner of the globe. And the orphanage and now school staff, in turn, began to fully embrace this new tool. They learned to secure seed phrases, make payments, and keep records. They became proud members of the Bitcoin community. In the process, 113 children (now 115) inadvertently became some of the youngest participants in a global Bitcoin economy. Not because anyone forced them to, but because it simply worked for them. In a way, these kids accidentally demonstrated what voluntary Bitcoin adoption looks like at its purest. They had a need; Bitcoin filled it. It was as simple as that.
Africa Needs Bitcoin, and Bitcoin Needs Africa
Moments like the zoo trip put into perspective why all of this matters. We often say that Bitcoin solves real problems in Africa — things like costly remittances, lack of banking access, corruption, and currency instability. I have seen that truth with my own eyes. Here in Uganda, if you don’t have a national ID to get access to mobile money or if you live far from a bank branch, the traditional financial system shuts you out. But with nothing more than a feature phone (via Machankura) and an internet connection (if on a smartphone), Bitcoin lets anyone participate in the economy. Donations that would have taken days and hefty fees to arrive via wire transfer now reach us in minutes with pennies in fees. When we need construction works, medical supplies, school fees, or food, Bitcoin is often the fastest and most transparent way to get funds and pay for it. Africa needs Bitcoin because it can leapfrog a lot of the infrastructural challenges that have held us back. It puts power directly in the hands of the people who need it — whether it’s an orphanage in Uganda, refugees in a camp who can’t open bank accounts, or a women’s savings group looking for a way to store their hard-earned savings. It provides an alternative when local currencies collapse or when inflation eats away at savings. It creates the possibility for a more level financial playing field.
But the other side of this story is something I’ve come to believe just as strongly: Bitcoin needs Africa. It needs the energy, the stories, and the real-world use cases that our communities provide — in places like Uganda, Nigeria, Kenya, South Africa, and beyond, Bitcoin isn’t just an investment toy or a speculative asset — it’s a tool of survival and empowerment. We are stress-testing Bitcoin in the most human ways. We’re finding out how it can feed children, fund education, and build businesses from the ground up. By doing so, we are giving Bitcoin a purpose far greater than price charts and inflation hedges. We’re imbuing it with our values of community and solidarity. A friend of mine, Fernando from the Praia Bitcoin project in Brazil, who has mentored me greatly, told me something that has stuck in my mind. Seeing our work with the orphanage since 2023, he said:
“This is the most successful usage of Bitcoin so far. It’s starting the peaceful revolution with over 100 forgotten ones.”
Coming from someone halfway across the world, who’s also fighting to spread Bitcoin for social good, that meant a lot. It reminded me that what we’re doing in this little corner of Uganda is part of a much larger story — a peaceful revolution uniting those whom the old financial system left behind.
Back at the zoo, I felt that revolution in my bones. I saw it in the way the Kampala Bitcoin community members showed up en masse to support these kids — many volunteers traveled hours to be there, paying their own way just to share in this joy. I saw it in how eagerly the children shared pizza slices with our guests, as if to say thank you for being there. At that moment, any barriers between “rich Bitcoiners,” if there were any in attendance, and “poor orphans” melted away; we were just people together, celebrating hope and possibility. By the end of the day, we had gathered over 160 people to celebrate and I knew this was a story worth telling far beyond our borders. On Twitter, we’ve been documenting our journey from the start, and I’m thrilled to share that a short documentary of this Bitcoin Pizza Day at the zoo is coming. It will capture the smiles, the songs the children sang, their experience on the bus, and the sheer amazement on their faces meeting wildlife for the first time. I invite you to follow Bitcoin Kampala on X (Twitter), on YouTube, and even on Nostr, so you can see when the short film is released and stay updated on our next chapters.
The buses have long since left the zoo, carrying the children back to Bugiri, but the impact of that day still lingers in our hearts. I’m writing this back in Kampala, reflecting on how far we’ve come. It’s hard to believe that a simple idea — using bitcoin to help those in need — would snowball into a community and movement that’s changing lives. I think about the future a lot — about those kids and what opportunities we can create for them as they grow up. There’s so much more to do. We want to build them a Bitcoin school where they can feel safe and loved while acquiring multiple life skills and learning about Bitcoin. We want to expand our little Bitcoin economy so that by the time these children are young adults, they’ll have a thriving local market to participate in, one that understands and accepts the money of the future. We want to show more people across Africa what is possible when Bitcoin meets compassion.
As I wrap up my thoughts, I return to that opening question and realize it isn’t so impossible after all. How did 115 orphaned children end up on a bus to the zoo on Bitcoin Pizza Day? They did it because hundreds of people — from Uganda to South America to Europe and beyond — decided to care. They did it because a decentralized network allowed those caring people to coordinate and contribute instantaneously. They did it because when Bitcoin is guided by heart, it can achieve truly beautiful things. This experience has left me deeply hopeful. If a handful of Bitcoin enthusiasts and a struggling orphanage can join forces to accidentally spark a “peaceful revolution” for over a hundred forgotten children, then what else is possible? The mission we’re on is bigger than bitcoin’s price or any buzzwords; it’s about human dignity and connection.
Bitcoin has given all of us, but especially these children, a chance at a better life. It’s given me a renewed purpose. In turn, these children have given Bitcoin a story that cuts through the noise and gets to its true essence. I believe that story is only just beginning. After all, as we like to say in our Bitcoin in Africa Monthly Twitter Space: Africa needs Bitcoin, and Bitcoin needs Africa.
This piece is an article featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here to show the ideas explored throughout the full issue.
Let’s look at two things that Bitcoin Knots users claim to be proponents of and champions for in their crusade against Bitcoin Core:
Mining decentralization
Bitcoin’s use as money
They claim to fight for mining decentralization, with OCEAN mining pool held out as a primary example of this. OCEAN’s DATUM protocol is ostensibly designed to further mining decentralization, specifically the actual template construction process that decides what transactions go into a block.
They also claim to fight for Bitcoin’s use as a monetary network, i.e. a network that facilitates the transmission of bitcoin in economics transactions, ensuring security for those transactions.
These are both incredibly important goals. Bitcoin’s mining network remaining decentralized is absolutely critical in order to maintain its censorship resistance. A clear majority of miners must exist and operate in a state free from the possibility of coercion from the state (or any other party) to engage in censorship. Without existing in this state, a simple majority of miners coerced in such a fashion would be capable of perpetually preventing any transaction from confirming in the blockchain, completely undermining Bitcoin’s core value proposition.
Scaling Bitcoin’s use as money is also incredibly important. The only mechanisms to transact with bitcoin in a censorship resistant fashion are ones that are truly anchored to the blockchain itself in a manner where the end user can on their own enforce ownership of their current balance of bitcoin.
Both of these things are absolutely necessary for Bitcoin to meaningfully contribute to any positive change in the world.
So let’s look at what they claim to stand for versus what they are actually doing.
Actions Versus Words
So firstly, developers have been working on a protocol called Stratum v2, a replacement for the current Stratum v1 protocol miners use to interact with mining pools. This has been a massive project, all completely open source, to allow individual miners to select transactions that are included in blocks themselves as opposed to the pool operator (the pool still controls payouts).
What did OCEAN (run by the largest Knots supporters) do to support Stratum v2? Nothing. They created their own proprietary alternative DATUM (they have pledged to open source everything in future but have not yet done so). In both solutions the pool operator is capable of rejecting proposed blocks from individual miners, which would leave the miner continuing to do work they are not getting paid for. Stratum v2 supports immediately switching to another pool in such a case to ensure the miner continues getting paid, OCEAN does not. It simply defaults to solomining.
Given that it is not even open sourced yet, no other pool can adopt it. It is essentially a vendor lockin for OCEAN pool, who can still reject any template a miner proposes, with no way to trivially opt out if a miner’s block template is rejected and switch to another pool.
To top it off, the practice of filtering transactions slows down the propagation of blocks across the network. When a miner finds a block, they don’t relay the whole block, they relay the header with a compressed “list” of all the transactions in it for a node to reconstruct and verify the block with the transactions in their mempool. When nodes do not have those transactions, it takes longer for them to fetch them from peers, validate the block, and relay it onward.
This disproportionately hurts smaller miners. If a large pool has a block orphaned because of this, i.e. another miner finds a block before the other one propagates across the network, that larger miner has a very high chance of finding the next block building on their orphan, thus “saving it” to be included in the blockchain.
Smaller miners do not have those high odds of finding the next block in this situation. This disadvantages them, making the highest fee paying transactions something that could actually lose them money, as opposed to larger miners who will likely find the next block and not have their first one orphaned.
In multiple ways OCEAN (and Knots supporters) are actively harming mining decentralization while proclaiming themselves defenders of it.
Now let’s look at the use of Bitcoin as money. Ephemeral anchors are an optimization to make Lightning function more efficiently, for a deeper explanation of them you can read this, but the important point is they allow Lightning users to be much more efficient with fees they pay to close channels on-chain.
The latest release of Knots by default filters these transactions, and will not relay them across the network. When a Lightning user has to non-cooperatively close, they are doing so in order to protect their funds. Lightning implementations are all in different phases of shifting over to using them. Knots actively attempts to prevent these transactions relaying to miners.
How does that help advance the use of Bitcoin as money? Again, just like with mining decentralization, they act in a complete opposite manner than what they say. Citrea is yet another example, a Bitcoin Layer 2 designed to scale financial transactions. The Knots OP_RETURN filter will not relay the transactions needed to enforce correct operation of the Layer 2.
What They Do Matters, Not What They Say
Knots supporters proclaim themselves defenders of Bitcoin, here to ensure it remains a decentralized censorship resistant money. But their actions push towards the exact opposite goal.
The things they do to “champion” mining decentralization actually create dynamics that worsen its centralization.
While proclaiming Bitcoin is money, and defending its use as such their chief goal, the software they release and run actively undermines multiple Layer 2s whose entire purpose is to scale Bitcoin’s use as money.
They are literally fully engaged in a campaign with the end goal of preventing certain kinds of Bitcoin transactions from being made, while proclaiming themselves defenders of Bitcoin.
At the end of the day, this is an open network, and people can run whatever software they want to interact with that open network. That is a critical and important aspect of Bitcoin. This is not about software, this is about people.
This is about the stated goals, the stated values of people in this space, being the complete opposite of the actions they engage in. I hope that Bitcoiners are smart enough to eventually see the Orwellian newspeak that has been dominating the entire dispute around Bitcoin Core and Knots over the last few years.
“The party told you to reject the evidence of your eyes and ears. It was their final, most essential command.”
This is the third in a 10-episode video series focusing on Bitcoin privacy, filmed at bitcoin++ Privacy Edition in Riga and elsewhere. Each episode will touch on some aspect of Bitcoin privacy, tools to use Bitcoin privately or surveillance techniques.
Privacy is heads, censorship resistance is tails. They’re two sides of the same coin.
Everything people do together is inherently interactive. When those interactions cannot be conducted privately, when they become common public knowledge, the participants can be subjected to external pressure. They can be shunned, shamed, jailed or penalized in many other ways.
Without privacy, you have no censorship resistance. Without privacy, most people will censor themselves.
In this first episode, I sit down with Yuval Kogman from Spiral to discuss Bitcoin privacy. We go all the way back to Section 10 (Privacy) of the Bitcoin Whitepaper, and trace the path from there to the modern day.
We discuss how privacy can be degraded based on how you use Bitcoin, the different specific ways you leak private information, as well as the lineage of tools that have been created over the years to help users prevent those leaks and protect their transactional privacy.
This is the first in a 10-episode video series focusing on Bitcoin privacy, filmed at bitcoin++ Privacy Edition in Riga and elsewhere. Each episode will touch on some aspect of Bitcoin privacy, tools to use Bitcoin privately or surveillance techniques.
Privacy is heads, censorship resistance is tails. They’re two sides of the same coin.
Everything people do together is inherently interactive. When those interactions cannot be conducted privately, when they become common public knowledge, the participants can be subjected to external pressure. They can be shunned, shamed, jailed or penalized in many other ways.
Without privacy, you have no censorship resistance. Without privacy, most people will censor themselves.
In this second episode, I sit down with Calle, the creator the Cashu ecash protocol, to discuss the loss of privacy on the modern internet. In an era where large internet platforms are accessible for free, the real cost of these platform is paid for by sacrificing your privacy in the name of advertising revenue.
This economic model of the internet is a wild departure from the original vision of users paying for accessing to resources. The “402 Payment Required” error message was a part of the HTTP protocol from the very start.
We discuss how Cashu as a vehicle for bitcoin micropayments offers a chance to turn things around, and build the privacy respecting internet the early designs of the world wide web envisioned to begin with.
Watch the talk below:
Here is the second video in the Privacy Series. In this episode I sat down with @callebtc to discuss his work on Cashu, and how Bitcoin can be used as a tool to claw back privacy on the modern internet. pic.twitter.com/iXX08rtjse
This is an inescapable technological reality. Money itself is simply a ledger, a record of who has what. Even physical cash is simply distributing that “database” in the real world. You no longer have to check against some central ledger to verify anything because the simple act of handing it to you is that process of verification. The “entries” in that ledger are passed around disconnected from some central record. Bitcoin is simply a digital database attempting to replicate the most important property of that physical one known as cash: not needing a database operator’s permission to spend your money.
Imagine the futility of trying to stop people from defacing dollar bills. How many of you have stamped “Buy Bitcoin” onto fiat currency? Defacing a banknote in the United States is a federal crime. You can spend 6 months in jail for it. Does that stop anyone?
Do you seriously think that could be enforced anywhere? Do you remember Where Is George? People would stamp a website on dollar bills so people could enter serial numbers when they got them and track where cash notes were circulating geographically.
Artists do innate murals and collages on cashnotes. You literally cannot stop it.
Why is there a strain of magical thinking that believes this is possible simply because the database is digital?
By its very nature Bitcoin requires supporting the inclusion of arbitrary data (read: data that it is impossible to know or define ahead of time) in order to allow users to transact. You don’t know ahead of time how much money you will send (the satoshi field in outputs), where you will send it (the script field), what blockheight you might wish to spend it at (the nLocktime field in a transaction, or the nSequence field in a transaction input).
Without allowing for these pieces of arbitrary data, it is not possible for Bitcoin to exist as a system.
Metaprotocols
A Bitcoin metaprotocol is a protocol layered on top of the base protocol, Bitcoin, that interprets the data and actions of the underlying protocol through the lens of additional rules that do not exist on that base protocol.
A historical example of this would be the Counterparty (XCP) protocol. Using OP_RETURN, an opcode in Bitcoin script that simply pushes arbitrary data to the stack creating an unspendable output that can be ignored by the UTXO set, XCP embeds its own metaprotocol messages.
These messages facilitate the issuance of new tokens, the transfer of tokens by defining how much is being sent and where, as well as other messages that enable on-chain trustless exchanges between XCP itself and any other tokens issued using the protocol.
The Bitcoin protocol itself doesn’t understand, or care, about any of these messages. They are interpreted by extra software run on top of Bitcoin. It is completely possible for anyone using Bitcoin to craft totally invalid XCP messages and get them confirmed on-chain, but XCP software will not recognize it as valid. The person crafting these invalid messages is simply wasting their own money creating pointless transactions.
Absolutely nothing can stop people from interpreting valid data on Bitcoin through the lens of extra rules external to the Bitcoin protocol in this manner.
Ordinals function in a very similar way. Users assign a unique ‘serial number’ to every single satoshi that is mined, and have created their own accounting system to interpret the input and output ordering in a transaction to follow where “individual satoshis” are sent in the course of transacting.
The Bitcoin protocol itself is completely unaware of this external protocol, and nothing at all can be done to stop users from interpreting valid Bitcoin transactions in this manner. Anyone can interpret the data published on the blockchain however they want, applying whatever additional constraints they choose that do not conflict with the base Bitcoin protocol rules.
Nothing stops people from crafting invalid or malicious metaprotocol messages, and confirming those in the blockchain, but users running metaprotocol clients will simply ignore them as invalid. This is the key difference between the Bitcoin protocol itself, and metaprotocols. Bitcoin consensus rules prevent protocol invalid messages from ever being included in the blockchain, metaprotocols don’t (or rather can’t).
Data Embedding
The difference between the two metaprotocols above is that one requires embedding extra data on-chain in order to function (XCP), and the other does not (Ordinals). So you might be assuming that you can simply prevent protocols that require embedding extra data by simply preventing that data from being embedded in the first place.
While it is true that specific mechanisms of data embedding could be prevented by softforking that particular mechanism out of the protocol, i.e. rendering transactions that make use of that mechanism invalid, you cannot prevent data from being embedded in general.
Take for instance the “Inscription envelope.” This is simply a specific method for guaranteeing that the data embedded in a spending witness is never actually executed. This is done by using OP_FALSE, which pushes a 0 (or False value that will fail verification) onto the stack before the OP_PUSHes that actually embed the data. This causes the script interpreter to simply skip verifying the data after the OP_FALSE. The key functionality required is putting a 0 on the stack.
If you invalidate by consensus the use of this specific script format, there are other ways to put a 0 on the stack, or to ensure the script interpreter scripts the verification and execution of subsequent chunks of scripts. Just trying to stop this specific class of data embedding, and by that I mean the use of OP_FALSE in general, itself becomes a game of cat and mouse with many other options users can turn to.
Disabling each of them requires the deployment of a softfork, a massive coordination effort across the entire ecosystem, and right after succeeding users can trivially modify their software to use another method. Metaprotocols can adapt much faster than Bitcoin. Mind you, this is solely dealing with this one class of ways to embed data.
Let’s entertain the hypothetical reality where all mechanisms using OP_FALSE have been restricted (ignoring both the complication in identifying all of them and coordinating the fork, as well as the potential for unintentionally restricting other use cases of Bitcoin), users can simply create fake public keys. There is nothing in the Bitcoin protocol that verifies a public key is a valid public key, it is simply a random arbitrary string included in an output’s locking script.
Now imagine a world where Bitcoin did include a mechanism that forced validation of a public key before allowing money to be sent to it. That would solve that problem right?
Wrong.
You can embed the data indirectly using the private key. But private keys don’t ever actually get put on-chain right? No they don’t, but a signature nonce is. A nonce is a random value used in the construction of a cryptographic signature. This is required to protect your private key, because without using one a cryptographic signature is insecure, and can leak your private key to an attacker. Even using a poorly selected, or weak, nonce can allow that to happen.
People can intentionally use a weak nonce, and actually use the arbitrary data itself as a private key. The only way this can be prevented is a centralized authority whitelisting private keys, i.e. completely centralizing the ability to use Bitcoin behind a gated authority.
These examples are not even comprehensive, there are many other methods I can think of to embed arbitrary data in the blockchain, and I am certain many more that I can’t.
Attempting to play whackamole with all of them simply wastes the time and resources of the entire ecosystem trying to coordinate softforks to address each of them, a massively complex and costly effort, and at the end of the day there are still methods that are not possible to prevent at all without completely breaking the core Bitcoin protocol itself.
Why User Will Continue Doing This
I am sure plenty of people reading this are thinking “we just have to do this a few times and people will stop trying, they won’t go through all the extra effort.” That attitude is completely disconnected from reality for multiple reasons.
I want you to think about the two reasons that people would engage in this type of behavior in the first place. Either it is providing real utilitarian benefits to them, i.e. serving a real purpose in their lives that provides value not purely rooted in speculation, or it is pure speculation.
Let’s look at the first case. There is some meaningful utility value provided, that cannot be provided in some other way, or at least not to the same extent, or same security guarantees, etc. Why would these users not keep adapting their protocol to route around whatever restrictions are put in place to prevent their use case at the consensus level?
This hypothetical protocol is a real thing to these people, something providing some necessary or valuable functionality to them. All of them have an incentive to adapt the protocol to work around whatever new restrictions are added.
Now let’s look at the second case, it is purely a speculative use case, i.e. NFTs or some form of collectible or token. These types of things are fueled by pure speculative mania, massive amounts of money are thrown at them in a game of musical chairs with everyone playing to get out the door with profit because the mania dissipates and collapses on itself.
These things are always cyclical, never persistently maintained, and come and go. What makes you think that restricting one form of creating such assets will disincentivize people from making new ones? I’ll remind you at this point that the “transfer of ownership” with these things on Bitcoin occurs through Ordinals. That particular metaprotocol is literally impossible to block or prevent by any means at all.
Nothing about restricting specific mechanisms to embed data on-chain prevents the transfer or resale of assets previously created using that mechanism, so nothing can be done to prevent those assets that already existed from being traded.
People who engage in these activities are degenerates, they blindly chase whatever opportunity they can find for a quick buck. Do you think preventing them from making new assets of a certain type will stop them? Forcing them to use new mechanisms will probably actively drive demand for those new types of assets. It won’t be a disincentive, it will be a proactive incentive.
The new mechanism will become desirable to them because of the controversy value. This is simply a losing game, which as I demonstrated in the section above ends with the use of mechanisms that are literally not possible to prevent.
The Rational Course of Action
It is impossible to stop the embedding of arbitrary data in general in Bitcoin. It is possible to stop some specific methods of embedding data, but not the practice in general. So why are we fighting these things?
All we can do at the end of the day is keep pushing these use cases into more inefficient methods that cause a large negative impact on the network as a whole. Leaving the currently supported means, which in the grand scheme of things are very efficient in terms of network resource use, is the rational move to make.
Trying to expunge the practice of embedding data in Bitcoin is both impossible, but trying is ultimately self destructive. It leads us down a path that ultimately constrains and limits Bitcoin’s use as money, and still in the end ultimately fails.
It is simply cutting your nose off to spite your face.
A major NPM developer, qix, has had their account compromised. It was used to push malware that targets and searches for bitcoin and cryptocurrency wallets on users devices. If detected, the malware would patch the code functions used to coordinate transaction signing, and replace the address a user is trying to send money to with one of the malware creator’s own addresses.
This should mostly be a concern for web wallet users, so in the Bitcoin ecosystem Ordinals or Runes/other token users, as unless an update for your normal software wallet happened to be pushed just earlier today with the compromised dependency, or if your wallet dynamically loads code directly from the wallet back end bypassing the app-store, you should be fine.
NPM is a package manager for Node.js, a popular Javascript framework. This means it is used to grab large sets of pre-written code used for common functionality to be integrated into different programs without the developer having to rewrite basic functions themselves.
The targeted packages were not cryptocurrency specific, but packages used by countless numbers of normal applications built with Node.js, not just cryptocurrency wallets.
If you are using a hardware wallet in combination with your web wallet, take extra care to verify on the device itself that the destination address you are sending too is correct before signing anything.
If you are using software keys in the web wallet itself, it would be advisable to not open them or transact until you are certain you are not running a vulnerable version of the wallet. The safest course of action would be waiting for an announcement from the team developing the wallet you use.
Today Nunchuk Wallet releases support for fully generalized Miniscript use, bringing a degree of flexibility and control to their users not seen before.
For those unfamiliar with Miniscript, it is a policy language invented by Core developer and former Maintainer Pieter Wuille to make the creation of customized Bitcoin scripts easier and safer. Miniscript takes the most commonly used pieces of Bitcoin script, i.e. signature locks, timelocks, hashlocks, etc. and creates a “higher level” programming language for users to create custom scripts.
This higher level language is designed to be safely analyzable and composable, meaning that once users create a customized script they can be sure that it will behave exactly how they expect it to.
Nunchuk provides two basic templates users can use, simply needing to fill in the keys they wish to use in the wallet. One is a decaying multisig, where after a timelock expires less keys are required to spend in order to ensure that key loss does not result in losing funds. The other is an expanding multisig, where over time other keys can sign for a transaction beyond the core key set. I.e. initially a 2-of-2 is required, but after a timelock a third key can sign instead.
In addition to these basic templates, more advanced users can import any custom Miniscript template they have created themselves.
Miniscript templates can be applied to both Native Segwit wallets as well as Taproot wallets.
Out of the gate, the following hardware wallets will support Native Segwit Miniscript: Coldcard, Tapsigner, Blockstream Jade, and Ledger.
The following will support Taproot Miniscript: Coldcard and Ledger.
MuSig2 use with Miniscript will be limited to software only keys for the time being.
Nunchuk’s end-to-end encrypted communication function has full support for Miniscript templates, allowing collaboration between users in constructing and using template based wallets.
In addition, Nunchuk has compiled a 101 Technical Guide for users who wish to make use of Miniscript in their wallets. For those more inclined to dive into the nuts and bolts themselves, here is also a website put together by Pieter Wuille with a breakdown of Miniscript itself and some basic tools.
The cultural tone of the entire ecosystem has shifted wildly in the last few years. “Bitcoin Maximalists” have essentially faded off into the background in terms of having any kind of cultural influence or impact at all.
Dominant narratives, actual actions, and real impact has become completely dominated by either the Suitcoiners, clownish Wall Street types building the exact same kind of degenerate leveraged financial products on top of Bitcoin that caused the 2008 financial crisis, or the Degens, completely degenerate Ordinals obsessed cypherpunks with a moronic fixation on the notion of ascribing ownership to jpegs stored on the blockchain.
It’s frankly kind of disgusting and embarrassing that things have gotten to this point in this space. All meaningful drivers to growth and adoption are pulling people into a culture of brain dead suit-think completely devoid of any understanding or grasp of the true value that Bitcoin offers, censorship resistance and decentralization, or a culture of using those things for the stupidest most meaningless drivel imaginable rather than truly impactful uses that can change lives in a positive way.
But here we are nonetheless.
These two opposite and self-reinforcing echo chambers are dominating the stage. They are running the biggest booths ushering new entrants into the ecosystem. Yes, individuals can and will walk their own path, and some newcomers might stumble down some of those, but most won’t. Most will wind up following the Suitcoiners or the Degens.
In that political reality, I will stand with the Degens.
Everything they engage in is inane, moronic, pointless imaginary nonsense, but they at least appreciate and understand censorship resistance and the decentralization that creates it. They appreciate the value of self custody and tools that allow them to do what they want with their own money without needing to seek permission from someone else.
The Suitcoiners understand none of these things. They don’t care about self custody. They think that decentralization is just a magic buzzword, or some characteristic set in granite rather than a dynamic property that can ebb and flow. They don’t care about the value a censorship resistant unstoppable monetary network can bring to society. They just care about making dollars in the safe walled garden of the legacy system.
Bitcoin begins to lose all of the properties that give it a chance at resetting the world, of creating a level and neutral playing field for everyone, if its decentralization is eroded away. Without those things it becomes nothing more than a scarce asset trapped in the legacy walled garden. No permissionless money, no native currency of the internet, just a new stonk people buy like an S&P index fund.
That is the direction the Suitcoiners will take us in if left unchecked or unopposed. So begrudgingly, I have to side with the Degens. I may have nothing in common with them except an actual appreciation and regard for censorship resistance, but that’s what really matters at the end of the day.
This article is a Take. Opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
“It’s just writing down 12 words, anyone can do it.”
This is probably one of the most frequently uttered sentences in this ecosystem when it comes to discussing Bitcoin self custody practices. It’s just keeping some words safe, it’s super easy, anyone can do it right? All the criticisms and reasons people give for someone to not self custody are just Fear, Uncertainty, and Doubt. All that FUD can be cut through with that one sentence, right? Get your coins off Coinbase now!
Wrong.
This fallacious framing and line of argumentation is no different than saying “shooting a gun is just pointing and pulling a trigger, anyone can do it.” There is so much more than just pointing and pulling a trigger to shooting a gun safely. To start, there is actually having the appreciation for what a gun is, and the consequences using one can have. Consequences you cannot take back.
A gun is not a toy, it is a tool that can kill people. Without truly appreciating that, people can be careless in handling a gun, and if they were to cause harm to someone else while being careless there is no undo button.
There is no way to wind back time and bring someone back from the dead, just like there is no way to rewinding a bitcoin transaction.
Writing down 12 words doesn’t just solve everything. First users have to actually appreciate what those 12 words are. They have to really understand that those 12 words are their money. That they must be kept secret and secure in order to safeguard their bitcoin. Just having those 12 words written down doesn’t equate to having that appreciation.
Next, they need to actually physically secure that copy of 12 words to keep it secret.
Can they actually physically secure that mnemonic seed anywhere? Do they own a safe? Do they live with other people? Is there a spouse or children to consider? Does living with them mean that other people will be in your residence? Are they trustworthy?
What about con artists, hackers and social engineers? Is someone aware enough to discern when they are interacting with one of them? Do they understand the lines malicious actors are trying to cross in terms of access to their keys? Do they know how to verify software they download from outside of an App Store? Are they even observant enough to detect the signs that software in the App Store is fraudulent and malicious?
What about long-term compatibility? Does a certain device or piece of software do anything non-standard? Weird derivation paths? Custom backup schemes? Do users even understand these things to deal with them, or will this inevitably, in the long run, force them to trust a third party who could defraud them to deal with their wallet or backup not working with modern solutions in, say, ten years?
That’s not even touching on hardware devices. Can someone verify a device’s integrity? Hell, let’s go back before that: Can most people even assess whether a hardware device’s architecture and the company producing it are reputable?
I am not saying any of this to scare people away from self custody, or to be defeatist. This is a reality check. Bitcoin needs people to self-custody their funds and use them directly to remain decentralized in the long term. People will not do that if it is a terrifying, dangerous and unfamiliar experience.
It’s that simple. Just telling people over and over again to not fuck up won’t magically stop them from fucking up. Telling people over and over again to not be scared and anxious won’t magically make them stop being scared and anxious. Pretending that very real technical footguns don’t exist because they are trivial for you or I to deal with doesn’t make them stop existing for normal people.
We have a lot of tools to deal with these problems. Multisignature schemes allow key rotation and the potential to have a helping hand to fix mistakes. Schnorr multisignature schemes optimize this even further, creating less extra complexity for users. Both types of multisignature scripts can benefit from other improvements to create privacy.
How user interfaces are designed can do a lot to deal with scammers. The architecture different wallets or devices use can potentially remove attack surfaces entirely, or make them irrelevant if only exploited with one device or piece of software.
To this day, ten years or more after I used a Bitcoin multisignature wallet for the first time, it is still unintuitive, obnoxious and sometimes not possible to create a multisignature wallet using multiple independent pieces of software.
If we want people to actually self-custody at scale, which is necessary for Bitcoin itself to maintain real decentralization, these issues need to be addressed. Things need to actually be intuitive. Things need to be compatible across vendors and software. Users actually need something analogous to the helping hand they are used to with fiat money services.
If these things do not change, if they are not built and smoothed out, if compatibility doesn’t improve, then people just won’t self-custody their funds.
These things need to be experimented with, tested and refined, and ultimately cater to what your average person actually needs to not only feel safe with self custody, but to actually be safe.
If it doesn’t feel safe to them, people just won’t do it.
This is the first in a 10-episode video series focusing on Bitcoin privacy, filmed at bitcoin++ Privacy Edition in Riga and elsewhere. Each episode will touch on some aspect of Bitcoin privacy, tools to use Bitcoin privately or surveillance techniques.
Privacy is heads, censorship resistance is tails. They’re two sides of the same coin.
Everything people do together is inherently interactive. When those interactions cannot be conducted privately, when they become common public knowledge, the participants can be subjected to external pressure. They can be shunned, shamed, jailed or penalized in many other ways.
Without privacy, you have no censorship resistance. Without privacy, most people will censor themselves.
In this first episode, I sit down with Yuval Kogman from Spiral to discuss privacy in the modern digital era. Bitcoin is a digital money, and like everything else in our lives that has been digitized by computing technology and the internet, it leaves bread crumbs everywhere by its nature.
These bread crumb trails, in combination with the computing technology that created them in the first place, has radically changed the environment in which people interact with each other, particularly where some form of power asymmetry exists (i.e., the governing vs. the governed).
Those with the capability to pick up and analyze those breadcrumbs can apply technology to exert disproportionate control over other people.
What is the Lightning Network? It is generally spoken about in analogies, metaphors or direct explanations of purpose.
“It’s the checking account, versus on-chain as the savings account.”
“It’s a series of tubes like the internet, with bitcoin flowing through them.”
“It’s a quick, instant-settlement layer of bitcoin.”
What it really is is a network of payment channels, where people lock bitcoin into a multisignature address, and update the state of balance distributions off-chain. It’s how we are going to scale Bitcoin — or at least part of how we are going to scale Bitcoin.
In the short “Explainer” series in this magazine, I explain the mechanics of how Lightning works: how the pre-signed transactions that make up a Lightning channel work, how payments are routed across the network, ways that liquidity is managed, etc. Read those, and you should have a solid understanding of the underlying mechanisms that make the Lightning Network work.
The problem is, when it comes to asking what the Lightning Network is, all of those individual pieces are modular and replaceable. What if we structured the pre-signed transactions differently? Or what if we used a different mechanism to route payments across the network? What about totally rethinking the way we even select routes for payments in the first place?
What if we replaced all of them over time, so that none of the individual pieces of the protocol or network are the same? Is that still the Lightning Network? Like the Ship of Theseus, is the ship still Theseus’ ship after every plank and screw has been replaced?
Is the Lightning Network still the Lightning Network if we change how all the individual pieces work?
Channel Designs
Lightning channels are sets of pre-signed transactions. The purpose of these transactions is to commit to, and give users a mechanism to enforce, a balance distribution of a shared UTXO that neither party has unilateral control over.
Those channels, or transactions, currently take the form of a Poon-Dryja channel. These transactions use the revocation key mechanism invented by Tadge Dryja in the original Lightning Networkwhite paper. This is a very specific transaction structure for a payment channel, but it is by no means the only one.
Let’s look at a concept called “timeout trees” to look at something with minimal differences from the way channels currently work.
A timeout tree is one of the most basic possible forms of multiparty channels (a channel with more than two members in it). A Lightning service provider (LSP) creates a tree of transactions branching out from a single on-chain UTXO, and ending along each branch with a Lightning channel between the LSP and some user. Each tree has an expiry time, after which the on-chain UTXO (or any of the intermediary ones between it and the Lightning channels) can be spent unilaterally by the LSP. The idea is that users can simply swap their funds from channels in the expiring tree to a new one before that point, and let the LSP reclaim the liquidity it locked up with its users after expiry.
This was proposed as a use case for CHECKTEMPLATEVERIFY (CTV), an opcode that prevents a UTXO from being spent any way other than the transaction that matches a predefined hash; in principle, it could be done without it using pre-signed transactions with the trade-off of introducing more coordination complexity and risk of failure to initialize a tree.
The Lightning channels would essentially work just the same as Poon-Dryja channels, but also need to include all the extra pre-signed transactions involved in unfurling the tree, and subject to the expiry time of the tree as a whole.
Is this Lightning? Or is this something else?
What about LN-Symmetry? That is a proposal using CTV and CHECKSIGFROMSTACK (CSFS), an opcode that lets you check a signature against arbitrary data in a transaction to completely replace the revocation key and revocation mechanism.
Instead of the revocation system, LN-Symmetry creates the concept of a floating signature or floating transaction. The LN-Symmetry script has two ways to spend it, either a CTV branch locking the spend to the transaction representing the balance distribution for that channel state, or a CTV + CSFS branch that lets any transaction matching a CTV template signed by a specific key set in the script spend it. This, in combination with the use of different timelock values, allows any commitment transaction to spend the output of any prior commitment transaction, i.e., to replace older states with more recent ones.
Rather than penalizing a party who used an old transaction, LN-Symmetry “corrects” the old transaction to distribute balances based on the current state instead. Is this still Lightning? Or is this too different?
Payment Forwarding Protocols
Hash-time lock contracts (HTLCs) are used to route payments across the Lightning Network. Each HTLC either finalizes the payment moving forward with the revealing of a preimage to a hash, or allows it to be refunded backward if that preimage is not revealed in time. This is the mechanism safely enforcing that every hop of a payment either moves forward to the receiver, or backward to the sender (if it could not be completed).
This is not the only way to accomplish that goal.
Point timelock contracts (PTLCs) are another mechanism that could be used in place of HTLCs. PTLCs make use of adapter signatures as opposed to preimages and hashes to provide atomic guarantees between all the hops in a payment. Adapter signatures are cryptographic signatures that have had a data value added to them — or removed from them — in order to render them invalid. The signature can now only be made valid again by adding (or removing) the “adapter value” that was used in the first place.
Payments along a route are signed with adapter signatures, with the recipient of the payment releasing the information needed to render them valid again. But this isn’t that radically different from an HTLC; it just uses a different mechanism for facilitation.
Let’s look at something wildly different: packetized payments. This is an old proposal to completely do away with HTLCs in order to forward payments. The idea is to break up a single payment into numerous payments of very small value, say 100 satoshis, and then just blindly forward them to a peer with routing instructions.
The recipient can tell the sender every time a “payment packet” arrives successfully, and if one does not arrive, the sender knows that one hop along the route is not honestly forwarding the money. They can stop using that route and try another one, only losing 100 satoshis in the process.
Is this still Lightning, or something completely different? The channel transactions would work the same way and the routing protocol would be identical, but is it still Lightning?
Routing Protocols
What if we completely replace the routing protocol? Lightning currently uses the gossip protocol in order to ensure that all Lightning nodes on the network have a relatively good map of the different channels across the network, how much bitcoin is in them, and the fees they charge — all the information necessary for each node to fully select the routing path for its payments on its own.
Ant Routing is a proposal to do away with all of that entirely: to route payments across the network without any gossip protocol, without any map of the network, and without the sender picking the path that their payment takes.
The design to accomplish that is built around “pheromone trails” and “pheromone seeds,” special messages that are broadcast out across the entire network in order to facilitate payments. Together, the sender and receiver generate a large random number, and create a partial hash of that (the pheromone seed). Both parties then broadcast the seed to all of their immediate peers with a counter that increases by +1 every time the seed is passed along.
Eventually, one node in the network will receive both seeds, and know that they are the connecting point for a complete path between sender and receiver. At this point, that node will send a response message back in both directions, and when the sender and receiver both confirm the response they can coordinate the payment.
It will be passed back along the route to the connection point, and from there to the receiver, all without anyone along the path, including the sender and receiver, having to construct the route themselves or having any idea what the complete route is.
Is this still the Lightning Network? Or is this too radically different?
What Is It?!
The Lightning Network is a series of pre-signed transactions to enforce a balance distribution between users, plus the other mechanisms involved in updating that distribution and synchronizing those updates between users all across the network.
But doesn’t that also describe Ark? Or statechains? Yes. That’s my point.
The core idea of Lightning is just updating agreements about how to distribute funds off-chain, while ensuring that the most recent version of that agreement can be enforced on-chain if needed, without room for an involved party to “cheat the system” and enforce a more favorable past agreement.
There are many different ways to achieve that goal. The way used currently is simply the first concrete way that was specified. There are, and can be, more and different ways to do that. Over time the methods and tools for accomplishing that goal will change.
Maybe some new way will completely obsolete an older way. Maybe some new way works better in a certain scenario or situation. But new ways will definitely come, and that’s okay.
Some things will completely change, others will only be slight variations of what came before, but Lightning will shapeshift over time. It needs to in order to continue scaling in the long term, to solve its own problems, to help bitcoin function as a money.
Lightning will evolve.
Don’t miss your chance to own The Lightning Issue — featuring an exclusive interview with Lightning co-creator Tadge Dryja. It dives deep into Bitcoin’s most powerful scaling layer. Limited run. Only available while supplies last.
This piece is an article featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here to show the ideas explored throughout the full issue.
Yesterday’s guilty verdict for Roman Storm on the count of conspiracy to operate an unlicensed money service business is absolutely insane.
FinCEN, the regulator responsible for licensing, monitoring, and enforcement actions concerning criminal activity in money transmission has itself explicitly stated that self-custodial tooling that facilitates the transmission of value using cryptocurrencies are not money transmitters and are not subject to the relevant regulations.
So, how did we get here? Eight months after the election of a president who describes himself as a Bitcoin and cryptocurrency advocate, after the Department of Justice themselves have explicitly stated that they are not going to engage in regulation by prosecution, or prosecute mixing services, how was Roman Storm found guilty?
There is nothing to describe this situation except pure, unbridled insanity. Incoherence. Hypocrisy and contradiction. There is a lesson here, though, one that I think it’s time more people in this space learn.
The government’s word is worthless. It means nothing.
They will continue cracking down on privacy, they will continue pushing KYC surveillance through things like the GENIUS Act and through the backdoor, applying them to just stablecoins (for now). They will continue treating the desire for privacy as evidence of criminal intent. They will do all these things while talking out of the other side of their mouth about supporting Bitcoiners and the “importance of self custody.”
This is what the government does. This is what politicians do. It is inherent in their very nature.
We need to stop treating these people as our friends. We need to stop pretending and lying to ourselves that they can be won over and become powerful allies to push the values and tools that we wish to see in the world. They are not our friends. They will not become allies, sharing a common cause with us. They are our enemies.
It is time to stop pretending. These people must be treated as hostile, and dealt with as such.
We need to stop begging them for clauses and riders in bills. We need to take them to court. We need to stop kissing their ass and pandering to their egos and notion of public persona. We need to call them out as the two-faced spineless people they are.
If there is any legitimacy whatsoever to the legal foundations of the United States government, we do not need new laws, we do not need these people’s permission — we have the Constitution. Remind them of that in court.
If, at the end of all of that, this system is so corrupt and hypocritical that it functionally ignores the constitutional rights of Americans (and non-Americans), then we need to ignore them. Civil disobedience is the last mechanism we have to hold the government accountable to the foundational constraints they are built upon short of violence. It is time to use it.
Free human beings do not ask for their freedom; they take it. In a digital age creeping ever closer to Orwellian totalitarianism, that is the only way you will ever attain it.
That shouldn’t be read to mean that Bitcoin, the asset, or different ways to use it don’t scale. But Bitcoin’s blockchain does not scale. This is a fundamental and undeniable reality of its architecture. We’ve known this definitively since the Blocksize Wars (well, Bitcoiners have known this). Some people, such as James A. Donald — an anonymous cryptographer who was the first person to reply to Satoshi on the cryptography mailing list — and Hal Finney himself, knew this from the very beginning.
It is not possible for every person on Earth to have to receive, verify and retransmit the transactions of every other person on the planet. The notion that this is a viable idea is actually quite insane.
But this is fundamentally how Bitcoin works. Its security and integrity is only guaranteed through the process of every user receiving and verifying the activity that is processed on the blockchain. So how do we reconcile these two contradictory things?
We find inventive ways to commit to transactions without using the blockchain, essentially “caching” them until an appropriate time to actually engage in final settlement on-chain.
The Lightning Network is the first and most mature example of a system designed to accomplish this reconciliation in a decentralized fashion.
Lightning has not exactly evolved as we hoped it would — a pure end-user payments network — but it has undeniably demonstrated itself as the first viable second-layer scaling solution for Bitcoin. It might wind up becoming more of an aggregate settlement layer, or a network more suitable for businesses and services than end users (though not impossible for them to use), but it is so far a resounding success.
It has been an absolute pleasure and honor to act as the Editor-in-Chief for this issue, as this topic is something very close to me personally. Bitcoin is something that must scale in order to create the positive and impactful change that I want to see it create.
I’d like to thank all the contributors and team members who have made this issue happen, and, most importantly, Aaron van Wirdum’s stewardship and help during the process of passing the torch to me.
I hope you all enjoy gaining a better understanding of one of the most important projects in this space since Bitcoin itself was launched.
Shinobi
Don’t miss your chance to own The Lightning Issue — featuring an exclusive interview with Lightning co-creator Tadge Dryja. It dives deep into Bitcoin’s most powerful scaling layer. Limited run. Only available while supplies last.
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
Cypherpunks used to dream of true disruption. Many still do, but many have also tempered their aspirations and imagination.
Most things being built in this space these days are basic consumer applications. New payments tools, new marketplaces for digital assets and collectibles, ways to scale more payments tools, etc. Nothing has been done in a while to truly rock the boat in a new way. The last thing produced in this space that truly did that is probably the last thing anyone would think I would say: Initial Coin Offerings (ICOs).
Say what you want about them, but it truly shook up the world order. 99.99% of ICOs were impractical scams, pump-and-dump schemes, or outright fraud. But they shattered barriers, they broke down moats. They let anyone, anywhere, invest in anything, with no legal frameworks being applied (or even enforceable, depending on the jurisdictions issuers operated from).
A lot of the last few years has just produced more ways to integrate with the old order, to placate them, to adapt to them rather than vice versa. There isn’t much driving at disrupting the old order. The spark seems mostly gone.
Let’s try and find it looking at infamous cypherpunk Jim Bell’s idea for disrupting the system: assassination markets.
Jim Bell proposed the concept in his 1995-96 essay “Assassination Politics” published on USENET. Its core premise was aligning incentives through the use of a prediction market where participants would wager on the date that certain individuals would die. The idea was that market actors who placed large bets on certain dates would therefore have an economic incentive to bring about that individual’s death somehow, directly or indirectly.
As the pot of money grew for a specific individual, eventually it would grow large enough (at least that was the idea) that someone would act and actually arrange for the individual’s death, if not take care of it themselves.
This is technically possible to do now with Bitcoin privacy tools and trustworthy oracles. All you need is tools to keep your bets (or winnings) in bitcoin anonymous, and oracles people will trust to disperse funds honestly after a “victim’s” death.
This is obviously a highly unethical, immoral, and wildly dangerous idea. But it’s also a powerful one, and revolutionary. A successful assassination market working at scale would radically alter the calculus of the governing interacting with the governed.
How different would the world be if leaders had to weigh the risk of inciting an evergrowing pot of money incentivizing their untimely demise if they did something unpopular or detrimental to those they governed?
Obviously in the real world, building an assassination market is insane, if you can find oracles that wouldn’t just steal the money and run. But it’s conceptually possible. What happened to thinking about ways to actually disrupt? To resist and overturn the existing order?
Jim Bell also had a second, less extreme, idea: Federal “Justice” Shutdown. While everyone has a right to a trial by jury, almost no one criminally prosecuted actually goes to trial. Most people plead guilty or take a plea deal to escape the risk of harsher sentences at trial. Mr. Bell proposed crowdfunding money to pay attorney’s fees for anyone being charged with a victimless crime to go to trial.
The idea was to subject the federal court system to a Denial of Service attack. Without the vast majority of people taking deals or pleading guilty, the federal court system would not have the resources to hear all of these trials in a timely fashion. It would clog up the court system. This could be used as leverage to force the government to repeal illogical laws surrounding victimless crimes.
This is possible right now with nothing more than basic Bitcoin wallet software and internet communications channels. It’s not as cool or “wow” in a gritty cyberpunk fashion, but just like his original assassination market idea, it could have a profound impact on resisting and upending the old order.
Cypherpunks need to dream of true disruption again. People can do all kinds of things if they want to, they just need to imagine them first.
It was designed to facilitate payments not dependent on trusted third parties, and in order to accomplish this the system needs to be verifiable for all users to ensure payments are valid without trusting the word of a third party.
These two things are diametrically opposed.
If the system facilitates everyone who wants to transact doing so on the blockchain, then the cost for people to verify all of these transactions increases enormously, forcing most people to trust a third party who can afford those costs. If the system maintains a low cost of verification for participants, then everyone who wants to cannot cost effectively transact on the blockchain.
So we’ll scale Bitcoin with Layer 2s, right? But what does that mean? I’m sure most people reading this hear the word scaling and immediately think purely in terms of transactions per second. The more transactions we can do with bitcoin the asset per second, the more we have scaled, right?
I would argue no. That is a huge component of it, but that is not the only thing we are trying to scale. We are trying to scale the important properties of Bitcoin as a censorship resistant system. If we didn’t care about that aspect of scaling, we could already call it a day. We have exchanges, banks, and other centralized custodians.
Trustlessness
We want solutions we build for throughput scalability to preserve trustlessness. Users should not have to depend on the honesty of another party in order to guarantee the security of their funds. Within some constraints users must have the ability to guarantee the ownership of their funds while depending on the action of no party other than themselves.
This doesn’t necessarily mean the same security model as the blockchain, i.e. send your funds to an address and then no other action is required beyond keeping your keys safe. Users might need to stay online, or check in online periodically within some defined time window, or store data that can’t be deterministically regenerated, but they should be capable of unilaterally ensuring that their funds remain in their control.
Settlement Finality
Users need to have a high degree of certainty that transactions they have conducted are final, and cannot be wound back. This is the entire core function that the blockchain fulfills in the system, processing a transaction and ensuring settlement finality.
Currently no Layer 2 system actually provides settlement finality off-chain. What they provide is a settlement guarantee backstopped by a third party, such as a federation, custodian, or system operator, or an option to exercise settlement finality when the user wants in the form of pre-signed transactions.
The theoretically ideal Layer 2 system would provide actual settlement finality itself off-chain. While this might not actually be possible, we should be searching for stronger settlement guarantees provided by third parties, and more flexible and efficient designs for finality “options” in the form of unilateral exit schemes for Layer 2s.
Cost
We must minimize the cost for users to utilize these systems. This relates very heavily to settlement finality efficiency. If the exercising of a settlement finality option is too expensive, users will opt for systems where they delegate finality guarantees to third parties.
The cost of using a blockchain is based on how much data your use of it requires. The more data, the more expensive. As blockspace becomes more demanded and fees increase, users must be able to afford to exercise a finality option.
Liveness Requirements
All current Layer 2s that actually provide an option for settlement finality have some form of liveness requirement, i.e. the user must remain online or get online periodically in order to guarantee the trustless nature and settlement properties of that Layer 2.
Systems like Lightning require you to be online all the time, use a third party to be online and monitor the blockchain for you, or explicitly trust the people you have channels open with not to try to steal your money with old states. A system like Ark requires you to check in online and rotate your coins because an Ark batch expires and the operator can sweep all funds.
The only way out of this is to delegate settlement finality and trustless security of funds to a third party. We need to be reducing the liveness requirements as much as possible for systems that do not delegate control to a third party.
Putting It All Together
Only after we think about these properties that we want to retain while scaling throughput can we actually start to think about the functionalities needed in the Bitcoin protocol itself to facilitate that scaling.
For current Layer 2s to be trustless, the users themselves must be involved in authorizing balance updates off-chain. This requires users to interact with each other to approve updates. Obviously then, any opcode or change to Bitcoin that would allow users to interact with each other more efficiently and quickly to pre-sign transactions enforcing settlement finality would be beneficial for maintaining trustlessness while scaling.
To go even further, an opcode that allowed some portion of a UTXO to be freely used by one authorized user, but the rest of the balance remained restricted and only accessible to other users, could maintain trustlessness while doing away with the need for users to all coordinate together at all, or minimize that need to only the starting point of a protocol.
Thinking about the end result we want, in specific terms of the desired properties we want it to have, is what is necessary to actually scale this protocol in a meaningful way long term. Only then can we take a step back and think about the concrete functionality that the desired end result will need on a technical level.
To scale Bitcoin is more than just increasing the number of transactions it can process per second. We can do that right now with custodians. To scale Bitcoin is to increase the number of transactions that can occur trustlessly, with censorship resistant finality, without burdensome requirements of liveness placed on the user, and for a cost that a larger set of users can afford.
If we can’t scale those properties, then Bitcoin hasn’t actually scaled, no matter how many transactions a second are occurring with bitcoin the asset.
I won’t pretend to deeply understand quantum physics, or quantum computing specifically, I don’t, but I grasp enough to know that the theory underlying it is sound.
For certain classes of parallelizeable computations, the physical properties of quantum computers’ qubits allow searching for correct answers in very large search spaces exponentially more efficiently than classical computers. We have proven mathematical algorithms for these faster computations for a number of different computational problems, and there are many more that don’t yet have proven algorithms.
The question is whether it is practical to achieve from an engineering perspective, i.e. can we actually build machines that are efficient, reliable, and powerful enough to actually take advantage of quantum theory in a way that is useful at solving real problems?
That’s why I went to the Quantum Bitcoin Summit at the Bitcoin Presidio in San Francisco.
The small day and a half summit was attended by experts in both the quantum computing industry as well as Bitcoin developers. There were presentations on the current state of quantum computing, the specific risks to Bitcoin we would have to deal with after the development of a practical quantum computer, potential solutions we have to post-quantum cryptography, as well as debates over how to handle different aspects of the problem.
The State Of Things
There are four different architectures being developed by the different companies working on quantum computing projects. Neutral atoms, trapped ions, superconducting circuits, and photonics. All of these different physical platforms present themselves with different trade offs in terms of computational speed, stability, and scalability of the underlying physical architecture.
Most of the research for these different platforms has chiefly focused on one issue up to this point: error correction. The entire concept of quantum computing is based on the qubit, the quantum version of a bit. In traditional computers, physical hardware maintains a single bit of information using an electrical charge to represent either a 1 or 0. Qubits can exist in a superposition of both states, which is what makes them useful for certain parallelizable problems.
The issue is the physical constructs designed to implement qubits are very prone to noise interfering with computation, hence the focus on error correction. Because of this, the implementation of physical qubits has been highly redundant, in some cases requiring up to a thousand physical qubits to implement a “logical qubit” that can remain stable and coherent during computation.
Recent improvements have been made lowering the physical to logical qubit ratio, but another massive challenge still remains on the horizon: connecting multiple logical qubits together in a manner that can physically scale to large numbers of logical qubits. Currently no major progress has been made publicly on this challenge.
Threat To Bitcoin
Shor’s Algorithm is a quantum algorithm capable of breaking elliptic curve cryptography (ECC), if a quantum computer performant enough to run it in reasonable time is developed, then Bitcoin has serious problems to worry about. Bitcoin has many different script templates and address types at this point, but there are two major “classes” of addresses to consider when concerning ourselves with quantum computing: those that reveal the raw public key prior to spending coins, and those that don’t.
Coins that haven’t revealed their public keys prior to spending are safe from quantum theft until their owner goes to spend them, which necessitates revealing the public key, if quantum computers are powerful enough to reverse a public key to a private key before a transaction is confirmed. This is because these addresses use public key hashes rather than raw public keys. These coins are vulnerable to “short range attacks.” Coins that have already revealed their public keys are vulnerable to theft at any time. These coins are vulnerable to “long range attacks.”
Coins vulnerable to long range attacks include pay-to-public-key (P2PK), pay-to-multisig (P2MS), taproot address (P2T2), and any kind of address scheme that has reused addresses. Everything else is only vulnerable to short range attacks.
This presents a problem with two needed solutions: new cryptographic schemes that are quantum safe for users to migrate to, and a method to migrate coins vulnerable to short range attacks to protect users in case the threat materializes unexpectedly or users still haven’t migrated by the time it manifests.
There is still one major issue presented to the users operating Bitcoin: what to do with coins vulnerable to long range attacks that haven’t migrated by the time the problem appears.
Confiscate Or Not
There are almost 2 million coins locked in P2PK addresses that are vulnerable to long range quantum attack. That is almost 10% of the entire supply of bitcoin. Many Bitcoiners are very concerned about the possible implications the theft of such a large amount of coins could have on the price of bitcoin if dumped onto the open market.
As such, many ecosystem participants have proposed the idea of burning these coins and rendering them forever unspendable in the event of a quantum computer capable of attacking Bitcoin is developed. This has turned into the core of an ethical conundrum: do we take a confiscatory action to protect the wider ecosystem, or do we allow quantum vulnerable coins that have not migrated to be swept and stolen by a quantum attacker?
There are also middle ground proposals, such as Hourglass by Hunter Beast and Michael Casey. This proposes rather than freezing quantum vulnerable coins, they simply be throttled or rate-limited. Hourglass would only allow 1 UTXO of quantum vulnerable coins to be mined per block after activation, thereby limiting the effect stolen coins could have on the market, and giving the actual owner a slim chance of recovering some of their coins if they still possess the private keys.
One way or another, if a quantum attacker does manifest with a powerful enough computer, this issue will need to be decided.
The Tools We Have
As far as quantum safe cryptography is concerned, we have two broad options to choose from, lattice based cryptographic schemes or hash based cryptographic schemes. Lattice based schemes introduce new cryptographic assumptions, but support features we have come to assume when building, such as key aggregation schemes. Hash based schemes do not support key aggregation schemes, or even deterministic public key generation without private key material, but introduce no new cryptographic assumptions. Hash functions are known to be generally quantum resistant, and the hardness of hash functions is the only assumption made regarding cryptographic security.
Hash based signature schemes produce much larger signatures than lattice based schemes, but both are significantly larger than ECC signatures. Regardless of what scheme was chosen, there would be a massive reduction in throughput of the blockchain with the adoption of post-quantum signature schemes. This would either need to be accepted, or a proportional increase in block weight with a large quantum witness discount would be needed, heavily increasing the cost of running a full node.
In terms of migration schemes, there are two major paths that could be taken: commit-reveal schemes, or a zero-knowledge proof scheme proving control of secrets related to your private keys. The latter would only work for coins stored on keys generated by hierarchical determinic wallets using mnemonic word seeds.
Commit-reveal schemes invalidate spending short range attack vulnerable coins without first committing to a hash of the spending transaction. Users could then use quantum safe coins to commit to their vulnerable coins being spent, and only after that was buried under a sufficient amount of proof-of-work could the actual transaction migrating to a quantum safe address be confirmed.
Zero knowledge schemes could be used to generate a zero knowledge proof that you control a related key or secret generated in a derivation path from your mnemonic seed that has never revealed the public key. All vulnerable coins could be restricted to require such a proof in order to be spent. Since the proof must be generated using a key that the attacker could never discover, because the public key is never revealed, this proof should be impossible for the attacker to generate. However, it would be unusable for coins that are stored in addresses made prior to the invention of determinstic wallets.
So What Do We Do?
The theory of quantum computing is legitimate, and Bitcoin is systemically vulnerable to a powerful quantum computer, so what should we do?
I am personally not confident that the massive fundamental breakthroughs are right around the corner, but I am also not confident that they are impossible to make. It’s frankly above my ability to truly independently assess. What I do know is that we have the bare minimum of tools necessary to take defensive action against the possibility of those breakthroughs occurring.
Not reusing addresses and not using vulnerable address types will keep your coins safe from long range attacks, and able to use migration protocols. It is especially important for large exchanges and economic actors to take such basic actions. If this is a concern for you, then take such action, or be prepared to migrate to such addresses if it does become a concern.
As far as proactive changes go, hash based signature schemes are known to be quantum safe with no new assumptions, both Hourglass v1 and outright coin confiscation are simple to make changes to deal with systemic market risks (and doing nothing regarding this issue is even easier), and commit-reveal and zero knowledge migration schemes give us a means to migrate coins after the threat has already become real.
We should get these simple proposals in a ready-to-deploy, or place where getting there is a minimized workload, and then simply keep an eye on the situation while the people who are concerned continue debating and researching the subject.
The sky is not falling today, and maybe it never does at all. This is not an issue that should be keeping people up at night, but it is also not something we should completely ignore. We are already capable of minimal viable solutions now, we should get those into a reasonable state and then continue monitoring the situation for signs that we should collectively allocate more resources to the issue.
The one thing we definitely shouldn’t do, however, is panic and start blindly pouring time and resources into this over all other problems.
If you want to learn more about these issues, keep an eye out for coming interviews with attendees of the Summit. You can also watch the recorded presentations here:
Last week I touched on the nuances and complexities of “Trustodial” systems, systems that can’t be fully categorized as non-custodial or custodial, and how this causes issues when it relates to us categorizing different tools in this space. This is not the only issue being oversimplified in general conversation as it relates to categorizing ways of using Bitcoin.
Another major factor, with its own bag of complexity and nuances, is the cost of self custody.
I laid out these two core requirements for something to be considered self-custodial in the last article:
A user has unilateral control over their funds, or the ability to regain it.
No other party (or parties) has the ability to prevent the user from spending their funds, or regaining their ability to, or to spend them without the involvement of the user.
Let’s add another core requirement:
A user must be able to cost effectively exert their control over their funds, i.e. it must not cost an inordinate percentage of the funds under their control to actually transact with or enforce their ownership over them.
If a user has claim to some funds through some enforcement mechanism, but it would cost 95% of those funds to actually exercise that enforcement mechanism, does he actually have self custody of those funds?
The Core Problem
This is one of the chief scaling limitations of existing Layer 2 designs, such as Lightning, Statechains, Ark, etc. Any Layer 2 that makes use of pre-signed transactions to function is subject to this problem. Bitcoin has a blocksize limit, and whenever the pending transaction demand in the mempool is greater than the throughput capacity of the blockchain, fees go up. We have no mechanism, despite what some big blockers might say, to maintain a constant low fee level for users. Blockchains don’t scale without destroying their core value propositions.
This leaves us with no option but to construct off-chain scaling mechanisms, and so far the only viable trustless and self custodial solution is to use pre-signed transactions to facilitate this. That means that if a user ever has to actually make use of those pre-signed transactions, they have to pay the fees for them.
Because of this, the structure, size, and number of transactions that are necessary to enforce ownership are the deciding factors when it comes to the cost to enforce ownership claims on-chain. The more complex the script, the larger the transactions, the higher the number of transactions necessary, the more expensive it becomes to enforce ownership. All of these factors ultimately add up to create a minimum viable value to self custody with these systems.
If it is going to cost 10,000 satoshis to enforce ownership on-chain, then the idea of holding less than 10,000 satoshis in that system is just economically irrational. You would pay more in fees than the value you have a claim to is worth. Even 10,000 satoshis is too small in practice, would you want to pay 100% of the value you have in order to actually enforce ownership?
To be realistically cost effectively self-custodied, the value being secured must be some comfortable multiple of the cost to enforce it, say 3-5x. If it isn’t, then that value cannot actually be enforced on-chain, it will be eaten by fees if someone tries.
But It’s Not Custodial Either
Just like Trustodial systems, this introduces an ambiguous gray area. After considering the new third requirement to be considered self-custodial, a small value below the fees required to enforce it on-chain is clearly not self-custodial, but it’s not custodial either. While the rightful owner might not be able to cost effectively enforce their ownership on-chain, whatever party they are interacting with in a Layer 2 protocol cannot cost effectively steal it either.
This creates a sort of Mexican stand off when it comes to lower values secured on what would otherwise be unambiguously self-custodial Layer 2s. The rightful owner cannot cost effectively enforce their ownership on-chain, but because any other users participating in the Layer 2 cannot as well, they have no positive incentive to try to steal it by using old off-chain state transactions or refusing to cooperate to update balances off-chain. They can burn the rightful owner’s money by forcing them to submit transactions on-chain, but they gain nothing themselves in doing so.
This creates a dynamic where as long as the involved parties continue cooperating, these small values can be utilized and exchanged off-chain, but in the event that cooperation breaks down these small value balances essentially evaporate when they cannot be cost effectively enforced on-chain.
It Gets Worse
This problem is exacerbated in two ways. The first is fees going up. The bigger the transactional demand is for blockspace, the higher the feerates go, making the minimum viable self-custodial value higher. This is an unavoidable consequence of demand for Bitcoin increasing (as long as that demand is for bitcoin itself and not custodial balances with some service).
The second is actually a result of the current solutions for the first problem. The higher feerates get, the more expensive on boarding and off boarding from Layer 2s gets, necessitating coming up with designs that allow more people to share an individual UTXO, allowing on-chain fees (at least in the cooperative situation) to be spread between more people. This requires using either larger transactions, or more transactions, generally structured as trees that split up funds until eventually distributing them to individual users, to account for more users.
This means that not only has the baseline fee for a single transaction gone up, but users need to pay fees for either larger than average transactions or more than one transaction to enforce their ownership in non-cooperative situations!
So What Do We Do?
To tell a harsh truth, this might be a fundamentally unsolvable problem, at least in the scope of maintaining a security model that is more or less the same as Layer 1. The crux of the problem comes down to this: in higher fee environments the cost to enforce ownership on-chain goes up, necessitating finding ways for more and more people to share a single UTXO. While reducing the fees to utilize funds in the cooperative case, this increases the cost (magnified by whatever the higher feerate is) in the noncooperative case. However, the ability to exercise the noncooperative case is what actually enforces ownership.
As of right now, the best we can do is find more blockspace efficient ways to enforce ownership noncooperatively. This would mean new opcodes, specifically covenants, that would allow a single user to withdraw their share of funds from a shared UTXO while at the same time guaranteeing that the rest of the funds go back into the covenant to ensure other users can do the same.
This could prevent creating the problem of more users requiring more transactions to enforce ownership, but it still doesn’t deal with the fundamental problem of feerates going up themselves. Even in the theoretical best case a user would still need to make a single transaction to enforce their ownership over funds, and in higher feerate environments that will be more expensive. This is the aspect that might be fundamentally unsolvable.
Whether solvable, insolvable, or somewhere in between, this is a dynamic that is critical for users to understand. It is a gray area in which things can go wrong, and when things go wrong it can result in users losing their funds.
Bitcoin is a decentralized and censorship-resistant network built around independent participants maintaining and verifying their own copy of the database, storing its historical transaction record.
Its entire purpose for existing is to function in a manner that prevents anyone from being shut out of the system, or prevented from using it. That is its raison d’être.
People will use Bitcoin for things that it wasn’t intended for, or things that some people disapprove of, or some things that almost everyone will agree is abhorrent. These things will happen because Bitcoin works, you can’t stop people from using it.
The entire conversation around this reality in the last year or so hasn’t even really touched on the core dynamics of competing use cases, it has just been an argument between people advocating trying to stop people from using Bitcoin in certain ways, and people explaining the futility of that. There is an inescapable underlying reality that the entire discourse, debate, or whatever you want to call it, is almost entirely ignoring: there are different use cases for blockspace, with different needs of blockspace, and these all compete with each other.
That is writ large.
So what do we do about that? There is nothing to do but adapt. Blockspace is a competitive free market, it is Darwinian. Different use cases are very much like organisms, existing in an environment called the blockspace market. Like all environments, it can change and become dominated by new conditions. Anomalous and extreme events or changes in that environment can occur. It’s a dynamic system.
Like any organism in any changing or dynamic environment, use cases must adapt to those changes.
Blockspace Density
One of the core considerations when it comes to a use case adapting is density. How “dense” can a single use case’s utilization of blockspace be?
To put another way, how much can you compress the transactions required to fulfill a certain use case in order to minimize the blockspace required, and therefore the cost required. Means of exchange as a use case is a good example to start with. When Bitcoin was first launched, a single transaction, or exchange, required a single on-chain transaction in order to facilitate. Each and every economic exchange required one transaction’s worth of blockspace.
That is no longer the case, because the “density” of Bitcoin’s use as a means of exchange increased dramatically with the introduction of off-chain accounting mechanisms. This includes everything from custodial ledgers like ChangeTip (an old tipping service), Coinbase, and Wallet of Satoshi, to decentralized and self-custodial tools like the Lightning Network, Ark, and other Layer 2 designs. The efficiency of Bitcoin as a means of exchange has increased by orders of magnitude compared to Bitcoin’s early days. The amount of blockspace necessary to meet this use case is orders of magnitude less than what it used to be.
Let’s look at another use case, timestamping. Bitcoin is incredibly useful in this regard, by embedding a piece of data (or a hash of said data) into the blockchain, the existence of any digital file at the time it is confirmed can be proven thermodynamically beyond the shadow of a doubt. In the early days of the network, people used to include the hashes of every individual file being timestamped in an OP_RETURN of a single transaction. One transaction = one file timestamped.
That is clearly not very dense at all, and not very scalable. Opentimestamps changed this. Rather than make an individual transaction for each file to be timestamped, Opentimestamps introduced the concept of a “calendar server” that would accept numerous file hashes to be timestamped, and construct a merkle tree including all of them. A single transaction can now timestamp an infinite number of file hashes.
This was demonstrated by Opentimestamps creator Peter Todd in 2017, when he timestamped the entirety of the contents of the Internet Archive. That included over 750 million files, all thermodynamically attested to with a single transaction. If the density of the means of exchange use can be viewed as equivalent to a neutron star, an extremely dense stellar body, timestamping is the equivalent of the largest blackhole in the universe.
Let’s look at a final use case example, inscriptions. This use case utilizes blockspace in order to not just prove the existence of a piece of data at a certain point in time, but to make use of the Bitcoin blockchain in order to ensure that piece of data remains available to all who want it by counting on the incentives of the network to ensure the blockchain in its entirety remains available.
This use case has been made marginally denser. Ord, the ordinals and inscription client, has implemented compression algorithms for different types of data such as text and pictures. This however can only go so far, as the laws of information theory show that information can only be compressed so far without destroying information in the process. Trying to compress data beyond this limit renders such data irrecoverable.
Other NFT projects have tried to get inventive to circumvent this limitation, inscribing individual pieces of art such as body outlines, facial features, etc. and using small snippets of code to programmatically generate individual NFT images from these pieces. But that again can only go so far.
This is a use case that, given its entire purpose is to write the data itself directly to the blockchain in order to guarantee its durable availability, cannot be made denser to the same degree things like means of exchange use or timestamping can be.
Trust Models
One of the inescapable realities of increasing the density of blockspace use for individual use cases is the implications that has for any given use case’s trust model.
Looking at the means of exchange use case is the clearest example of this. Making a transaction on-chain is as trustless as a bitcoin transaction can be. A user can be in total control of their own funds, with no restrictions whatsoever on their use except the need to pay for blockspace. The denser you make transactional use, i.e., the more transactions you try to facilitate off-chain, the more you introduce new restrictions or trust requirements.
To transact on the Lightning Network means your coins must be locked into a payment channel. This subjects your funds to the liquidity requirements of the Lightning Network. Are funds available in other channels to route a payment to your intended destination? It also subjects your funds to time restrictions in the worst case scenario. If your channel counterparty is unresponsive, you must wait through a timelock in order to claim back unilateral control of your funds. It also introduces the responsibility to keep more data secure. If your channel state data is lost, access to your funds can be lost forever. Unlike mnemonic seeds, this data cannot simply be “regenerated” from a static one time backup.
Custodial systems are yet another different set of restrictions and trust trade offs. You might not be subject to liquidity requirements like on Lightning, but you must now completely trust your custodian. In order to transact, their permission is required. In order to claim back your money through a “less dense” mechanism, their permission is required. Everything you want to do with your funds requires that custodian’s permission.
Timestamping is a relatively easy thing here. The only change with more dense mechanisms like Opentimestamps is the need to store extra data, the merkle proof connecting the timestamp to the blockchain. Other than that, there are no fundamental differences, and the trust model of Opentimestamps is the same as directly timestamping a single file. It proves that file existed at that time, and nothing else.
Inscription’s trust model is essentially destroyed by attempting to maximally increase the use case density, i.e., storing files entirely off-chain. It is simply not possible to increase the density of this use case beyond the marginal improvements already made on-chain without completely destroying the trust model the entire use case is predicated on in the first place.
Demand Elasticity and Scaling
If each use case is to be looked at like an organism in a Darwinian environment, each use case’s ability to tolerate higher fees is the equivalent of an organism’s ability to adapt to a new environment.
If a use case can’t pay higher fees when the blockspace market gets more competitive, then it effectively dies. It becomes an evolutionary dead end. There are only two ways that a use case can adapt to a higher environment, either users just suck it up and pay the higher fees, or some mechanism is found for distributing fees amongst multiple users so that the individual cost is still bearable.
For transactional use cases, this necessitates facilitating more users being able to coordinate to share control of a single on-chain coin, and importantly having a cost effective mechanism for enforcing their share of ownership on-chain if necessary. The Lightning Network, and now soon Ark, have made massive progress in this direction. But it is nowhere near enough to increase blockspace density to the point where it can handle global use at scale without defaulting to most people using custodians.
That denies Bitcoin’s most important properties to most means of exchange users at scale. There is still a lot of work to be done in order to increase this use case’s density enough to bring censorship resistance to the masses.
Timestamping has already solved this problem as efficiently as it can be solved. A merkle tree is unbounded in size, and can commit to an infinite number of hashes. This means that an infinite number of users can collaborate to bear the cost of the single transaction necessary to timestamp everything.
Inscriptions cannot really adapt in the same way as the other two. While many users could collaborate in order to share the cost of inscribing data, this isn’t practical for many use cases. That might work if the goal is to inscribe some politically or socially relevant information, such as sensitive data leaks from government or corporate databases, but this is not the primary use case for Inscriptions. NFTs and other speculative assets are.
It makes no sense for a large group to share the cost of inscribing NFT data if only one person can “own” the resulting NFT. You could potentially share ownership with schemes like multisig, but this would be a complete evolution of the use case itself, not simply how the use case is facilitated. At the end of the day someone inscribing an NFT to sell must sell it for more than the cost to inscribe it. Otherwise they are losing money.
This will have an impact on the demand for such assets, and as such Inscriptions are decidedly at a disadvantage to other use cases in this respect.
Adapt or Die
You cannot stop people from using Bitcoin, even if you don’t like how they are using it. If you could, then Bitcoin would be a failed project that cannot even deliver on one its core value propositions: censorship resistance.
This is just the reality of how it works. Conversations around how to stop certain use cases, or users, is an exercise in futility, and quite frankly a comedy show. It completely ignores the reality of what Bitcoin is, how it works, and the underlying fundamental dynamics of multiple use cases existing together in a competitive system built around a scarce resource: blockspace.
It should be very clear that means of exchange as a use case has a decided advantage over a use case like Inscriptions in almost every way. It can be made denser, it can scale further while keeping more of its ideal trust model intact, and its demand is much more inelastic. If bitcoin’s desirability as a means of exchange faded, then Bitcoin as a system in its entirety would fade. Even just buying and selling the asset is a use as a means of exchange, it is being exchanged for fiat.
It is the primary use case, and for it not to be means that demand for bitcoin in general has failed to materialize to a sustainable level. That is clearly not the case.
Conversations around different use cases of Bitcoin should be focused on a single thing: how to increase the density of a use case, while maintaining the properties of its ideal trust model, to remain competitive with others in the market for blockspace.
If we want bitcoin to become a primary means of exchange, a global money, then this is necessary. Its density must increase, and its competitiveness must be maintained. Users who engage in other use cases can worry about those themselves, but all of us must be concerned with the competitiveness of the use case of means of exchange.
That is, unless you’re cheering on Bitcoin to win a Darwin Award.
The original concept of a Bitcoin sidechain was proposed by Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille, who all went on to found Blockstream, in 2014.
The idea was proposed to allow a more liberal development environment, where people could try new ideas and technologies on a sidechain without risking the security of the main Bitcoin blockchain.
Since then the design space of sidechains has grown rather large.
At the end of the day sidechains is a very broad term that encompasses a large range of very diverse and different systems. They can be as varied and arbitrary as the entire ecosystem of altcoins and other blockchains can be. That is after all what they are, other blockchain systems.
Regardless of the specific designs of any given sidechain, they have two primary components: a peg, and a consensus mechanism and rules. The peg functions as the vehicle for “locking” and “unlocking” coins on the mainchain to move them back and forth between Bitcoin’s base layer and the sidechain. The consensus mechanism and rules are how the sidechain itself functions, i.e. how new blocks are created, and the rules for what behaviors and transactions or contracts are allowed.
These are the necessary pieces for a sidechain.
The Original Proposal
The 2014 Blockstream design proposed the use of merge mining for a consensus mechanism, reusing the work from current Bitcoin miners by having sidechain blockheaders be committed indirectly in the mainchain blockheader, and Simplified Payment Verification proofs (SPV proofs) in order to operate the peg mechanism.
To facilitate merge mining, all sidechains would construct their blockheader as a “subheader” committed to in the coinbase transaction of a mainchain block. This would allow all miners to simultaneously mine the mainchain as well as whatever sidechains they choose to commit to. Any mainchain blockheader that meets a sidechain difficulty target, even if it does not meet the target for the mainchain, can be submitted to the sidechain network as a valid block.
Pegging required merkle proofs showing that certain transactions were included in a block. The proposed peg mechanism could work one of two ways, using symmetric SPV proofs, or asymmetric SPV proofs.
The symmetric scheme would require SPV proofs of both deposits and withdrawals, with a contest period. To deposit, users would need to send coins to a script on the mainchain that could only be spent by producing an SPV proof. After waiting for the contest period to elapse, the user could unlock coins on the sidechain with an SPV proof that they have deposited coins to the sidechain script on the mainchain. Any proof that a reorg with more work has occurred on the mainchain that undid the deposit transaction can be used to invalidate the claim transaction on the sidechain, and every sidechain user would have an incentive to produce that proof to prevent the peg from losing 1:1 backing.
Withdrawals would require the inverse, locking sidechain coins in a script requiring SPV proofs from the mainchain to unlock. After waiting for the contest period to elapse, the user can then unlock coins on the mainchain using an SPV proof that they locked coins on the sidechain.
The asymmetric variant does away with the need to produce SPV proofs of the mainchain for deposits by requiring sidechain nodes to also run and verify the mainchain by consensus. This would allow for faster and more secure deposits, but increase the validation costs of a sidechain.
While merge mining has been deployed for numerous sidechains, as well as completely independent altcoin networks, the SPV peg proposed in the original paper, and the needed consensus changes to Bitcoin, have never been implemented or deployed.
The Appendix – Federated Pegs & Other Designs
In the Appendix A to the original paper, the authors proposed in lieu of (or until) the softfork necessary to implement their SPV peg design the use of a federated peg. The proposal was to use a multisig of functionaries to operate the peg, custodying users coins while used on the sidechain and enforcing the validity of withdrawals. This was done with the implementation of Liquid, which also used the functionaries to sign blocks for the sidechain with cryptographic keys, and Rootstock, which made use of merged mining for sidechain consensus.
Since the launch of these sidechains, there have been numerous other design proposals for different sidechain consensus mechanisms, as well as different sidechain peg mechanisms. While many of them have been deployed, not all of them have, and none of them have truly achieved any serious level of adoption.
Below are links to a previous article series I have written looking at the different aspects of other proposed sidechain designs. While this series is not entirely complete, it includes most of the biggest proposals.
A lot of criticism has been circulating after the recent announcement that Wallet of Satoshi will be returning to the United States shortly thanks to the integration of Lightspark’s recent “Spark” system, specifically focusing around the issue of trust models and whether the new version of Wallet of Satoshi constitutes a noncustodial wallet or not.
Spark is a system based on statechains (explainer article there). Statechains don’t have the most clear cut trust model. Spark is essentially the channel factory version of statechains, with numerous statechains nested inside of a transaction tree built on a single on-chain UTXO.
Statechains are a Layer 2 system that allow entire UTXOs to be freely transferred off-chain with no liquidity constraints, but with the requirement of accepting some trust tradeoffs. You must trust that an operator, the service provider essentially, will delete private key material every time the statechain is transferred.
So let’s look at what makes something noncustodial.
A user has unilateral control over their funds, or the ability to regain it.
No other party (or parties) has the ability to prevent the user from spending their funds, or regaining their ability to, or to spend them without the involvement of the user.
The first quality definitively applies to statechains. Just like a Lightning channel a user has the ability to use a pre-signed transaction to reclaim their funds after a timelock period to ensure honest settlement. The second quality isn’t so clear cut in terms of applying or not applying.
The statechain protocol requires the operator and original user to collaboratively generate a key that neither party ever has full knowledge of. Using their shares they can collaborate to pre-sign the users withdrawal transaction. When the original user transfers it to someone else, the original user, new user, and operator all collaborate to “regenerate” the same key but with a different set of shares between the new user and operator.
After signing the new user’s withdrawal transaction, the operator is then supposed to delete the share they generated with the original users. This prevents the operator from ever signing a new transaction with the original user, and the shorter timelock on the new user’s transaction guarantees that they can spend theirs before the original user can spend his.
If the operator does not delete old key shares, then it would be possible for them to collaborate with any past user who kept their key share to steal the funds in the statechain.
The Operator
If the operator is doing what they are supposed to and deleting their old key shares every time the statechain is transferred, they are not a custodial system. They physically are incapable of signing any transactions in collaboration with anyone except the current and rightful owner of the statechain. The pre-signed transactions decrementing timelock guarantees that the current owner can always confirm their withdrawal transaction before any previous owner.
Operators can even run their software in an SGX enclave or other secure computing environment, and have the enclave enforce the correct behavior of the software. It can even provide proofs (granted you trust the environment to not be broken) of this that others can verify.
They also have a strong incentive to operate the protocol honestly, because in doing so they are not required to comply with the regulations that come along with being a custodial service holding other people’s money.
The Users
End users have a unilateral withdrawal transaction. This can be used any time after the timelock for their ownership expires and before the timelock for the previous owners time window expires. If the operator stops responding or disappears, they have this option.
But they have to trust that the operator is operating the protocol honestly, and deleting past key shares. There is no way for them to really verify that. As mentioned above, something like the SGX enclave could handle security for the operator’s software and sign proofs it is running honest software. But all that is doing is moving the point of trust away from the operator and onto Intel, the makers of the SGX enclave.
Even when dealing with a truly honest operator, who has only ever run honest software and never cheated a single user, a user can never actually know that they are an honest operator. They can only see that the operator has been honest, and hope they will continue to be.
So….?
There is no real clear cut answer. In the situation where an operator is actually being honest, it fits all the criteria I laid out above to be noncustodial. The user has an unimpeded ability to gain full access to their funds, and no one else is able to stop them from doing that or steal their funds.
The problem is that it isn’t verifiable.
There is no way to trustlessly verify as a user that you have trustless control over your funds. Even if you actually do.
So there is a problem with labeling it as noncustodial, because even if it is it is not possible for a user to ever truly verify it. But there is also a problem with calling it custodial, because the operator cannot do anything to move funds without collaborating with another user and the current user has a unilateral withdrawal transaction. This creates a dilemma in terms of categorizing tools in the space.
I don’t know what the solution is, but the first step I think is acknowledging the technical realities occurring before jumping to label things one way or another (why not a new category?) because of your own incentives. These types of questions, especially in an environment of glacially slow Bitcoin protocol changes, will become more frequent as developers struggle with the trade offs of Bitcoin’s current limitations.
Bitcoin is a programmable money, and the ways people will program it won’t always fit neatly into our predefined boxes.
The Lightning Network is a routed network of payment channels originally proposed by Thaddeus Dryja and Joseph Poon in 2015, with major implementations having been built by Blockstream (CLN), Lightning Labs (LND), ACINQ (Eclair), and Spiral (LDK).
Payment channels are an old concept in Bitcoin, where a user deposited funds into a 2-of-2 multisig address, and a payer can pre-sign transactions allocating more and more funds to a receiver. Original payment channels were one way, and had expiry times before which the receiver must close the channel before a pre-signed refund transaction would allow the payer to reclaim 100% of the funds they had allocated to the payment channel.
The two major innovations of the Lightning Network are a type of payment channel that isn’t limited to being unidirectional and having a hard expiration date, and the concept of using Hash-timelock Contracts (HTLCs) in order to atomically route payments across multiple payment channels.
The major drawback of Lightning, and payment channels in general, is the liquidity dynamics inherent to them. In order to receive money, users must already have a payment channel open to them with enough funds allocated to facilitate that payment. In order for payments to be routed across the network, every channel must have the appropriate amount of funds on the appropriate side of the channel in order to forward that payment.
Despite these drawbacks, Lightning has seen major success in use and growth since 2018 when it first went live on the Bitcoin network.
Poon-Dryja Channels
The key problem in going from a time-limited, unidirectional payment channel to one that is not time limited and bidirectional boils down to one problem: once you create a transaction and sign it there is no way to unmake it, or take it back. That transaction exists, and until the coin(s) it spends are spent by some other transaction, it remains valid and can be used at any time.
The solution to this problem lies at the heart of the Poon-Dryja channel. You might not be able to undo a pre-signed transaction, but you can create a very strong incentive to never use older ones, and even a benefit for the party that someone is attempting to cheat if they try. What facilitates this is the concept of a revocation key.
In a Poon-Dryja channel, each counterparty in a channel has their own mirrored set of pre-signed transactions, called commitment transactions. Each channel update or change of balances is simply each channel peer signing a new set of these commitment transactions. Each party’s commitment transaction gives the other party’s funds back immediately, but they must wait for a timelock to expire before they can claim their funds back. This is to allow the introduction of the revocation key.
Whenever a channel state update occurs, before it is considered finalized, both parties must exchange revocation keys for their most recent past commitment transactions. If either party were to ever try submitting an old transaction to the blockchain, claiming funds that are currently owned by the other party in the current state, then the victim can use the penalty key to confiscate 100% of the funds the cheating party has in that old channel state.
Hash-timelock Contracts (HTLCs)
Routing payments across multiple payment channels in a network, in a safe and secure way, is possible thanks to HTLCs. This is the same mechanism used to facilitate atomic swapping of different assets on a single or across multiple blockchains.
An HTLC establishes an output that can be spent in one of two ways, either by the receiving party if they can provide the preimage to a hash that creates a hashlock, or by the sending party after a timelock has expired. This allows someone trying to pay another person across the network to pass along HTLC proposals from themselves all the way to the receiver, locked to the same hashlock generated by the receiver. When the receiver’s channel party passes the HTLC to them, they can release the preimage.
Each party then, going backwards towards the sender, reveals the preimage. At each hop the channel is updated, moving the funds in the HTLC to the appropriate side of the channel. From the receiver backwards to the sender the timelock for the refund path gets longer each hop. This is to ensure if something goes wrong and someone must close their channel and settle the HTLC on-chain that the preceding parties can detect the preimage there and update their channels appropriately.
Gossip Protocol
To successfully route payments across the network, Lightning nodes need to have some general idea of what the network looks like. This is what the gossip protocol accomplishes. It broadcasts information about different Lightning nodes and the channels they have open so wallets can have an idea of what the network looks like in order to pick routes to try to pass payments through.
This is a very simple protocol that consists of three messages, a channel announcement, a node announcement, and a channel update. Each of these messages has a specific dependency with the others, and each plays a role in propagating information about the payment channel network that users can use in order to find viable routes for their payments.
The channel announcement message propagates the information needed to prove a Lightning channel actually exists. The UTXO that is funding it, signatures from both keys involved in the multisignature address holding it. Signatures from the Lightning node identity keys, which every Lightning node has, on the UTXO proofs and signatures. Everything to prove this is a real Lightning channel, backed by real bitcoin on the blockchain, and not a fake message spamming the network.
Only after making a channel announcement broadcast to the network can a node propagate a node announcement message. This announcement includes the nodes identity key, a network address they can be reached at, any nickname they choose to assign, and a few other pieces of metadata.
The channel update message facilitates information about fees and conditions for routing payments a specific channel is subject to. This includes the minimum and maximum value being transmitted a node will accept for an HTLC, the base and percentage fee rate charged (Lightning payments must pay a base absolute fee and then a second fee calculated as a percentage of the payment value), and the time difference between them and the previous hop in a payment they require for HTLCs.
This allows every Lightning node to construct a view of the overall network they can use to inform payment routes they attempt in order to route their own payments across the network.
Onion Routing
Every message passed between nodes across the Lightning Network related to routing a payment is onion routed. Every message is wrapped in a layer of encryption so that every participant in a payment route can only decrypt and read the message for it. This message is the instructions on which channel peer to forward the payment and payment information to next.
That’s it.
This provides some degree of privacy for payments across the network, as each individual party involved in routing is only capable of seeing their single hop in the overall path. They can see which partner forwarded it to them, and which partner they forwarded it to. They don’t see the ultimate destination or source.
This is why the gossip protocol exists, and why the sender of a payment is the one who constructs the payment routes they attempt to try. By having the sender construct the route, the payment is guaranteed a degree of privacy, but for the sender to construct the route they must know what the network looks like roughly speaking, so they can choose a route without leaking to anyone which route they are choosing.
Liquidity Dynamics
No one can receive a payment over the Lightning Network without someone else choosing to open a Lightning channel to them, and allocate some real bitcoin to that specific route and person. The channel peer must essentially make a bet on that person that they will have people willing to pay them for things regularly, and in enough volume, for that peer to charge fees and earn a satisfactory amount of money.
This creates a bottleneck, and a need for participants to earn each other’s trust in some way or fashion. People on the network willing to provide this “receiving liquidity” for others need some way to gauge someone’s reputation in terms of coming through and actually providing them an opportunity to earn money.
This has created the need for what people call “Lightning Service Providers” (LSPs). Service providers who specialize in running infrastructure to target end users and provide them the liquidity needed for them to receive payments. In addition to centralized solutions like this, protocol level solutions like gossip protocol extensions that broadcast offers and fees for opening channels to people with liquidity exist.
Wrapping Up
Lightning clearly has its limitations, such as barriers to entry created by the need to preallocate funds for a user to receive payments. But in spite of such barriers it has achieved a huge degree of success.
It hasn’t exactly panned out as a purely self custodial payment solution, but it has definitely been made to work self custodially, even if drudgingly. In addition to that, it has definitively demonstrated its usefulness as a general purpose settlement layer for more industrial scale or centralized uses.
Lightning is, whether it becomes a fully functioning end user payment system or not, an undeniably effective settlement solution for those who can deal with its complexities. This guarantees it some functionality in the long term Bitcoin ecosystem, regardless of whether it was its intended purpose or not.
Statechains are an original second layer protocol originally developed by Ruben Somsen in 2018, depending on the eltoo (or LN Symmetry) proposal. In 2021 a variation of the original proposal, Mercury, was built by CommerceBlock. In 2024, a further iteration of the original Mercury scheme was built, Mercury Layer.
The Statechain protocol is a bit more complicated to discuss compared to other systems such as Ark or Lightning because of the range of variations that are possible between the original proposed design, the two that have been actually implemented, and other possible designs that have been loosely proposed.
Like Ark, Statechains depend on a centralized coordinating server in order to function. Unlike Ark, they have a slightly different trust model than a vUTXO in an Ark batch. They depend on the coordinating server to delete previously generated shares of a private key in order to remain trustless, but as long as the server follows the defined protocol and does so, they provide a strong security guarantee.
The general idea of a Statechain is to be able to transfer ownership of an entire UTXO between different users off-chain, facilitated by the coordinator. There is no requirement for receiving liquidity like Lightning, or the coordinator server to provide any liquidity like Ark.
To begin, we will look at the original protocol proposed by Ruben Somsen.
The Original Statechain
Statechains are effectively a pre-signed transaction allowing the current owner of the Statechain to unilaterally withdraw on-chain whenever they want, and a history signed messages cryptographically proving that past owners and the receivers they sent the Statechain to approved those transfers.
The original design was built on eltoo using ANYPREVOUT, but the current plans on how to enable the same functionality make use of CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK (a high level explanation of this is at the end of the CHECKSIGFROMSTACK article). The basic idea is a script enabling a pre-signed transaction to spend any UTXO that has that script and locks the appropriate amount of bitcoin, rather than being tied to spending a single specific UTXO.
In the protocol, a user wishing to deposit their coins to a Statechain approaches a coordinator server and goes through a deposit protocol. The depositing user, Bob, generates a key that will be uniquely owned by him, but also a second “transitory” key that will eventually be shared (more on this soon). They then craft a deposit transaction locking their coin to a multisig requiring the coordinator’s key and the transitory key to sign.
Using this multisig, Bob and the coordinator sign a transaction that spends that coin and creates a UTXO that can either be spent by any other transaction signed by the transitory key and the coordinator’s key using LN Symmetry, or Bob’s unique key after a timelock. Bob can now fund the multisig with the appropriate amount, and the Statechain has been created.
To transfer a Statechain to Charlie, Bob must go through a multistep process. First, Bob signs a message with his unique private key that attests to the fact he is going to transfer the Statechain to Charlie. Charlie must also sign a message attesting to the fact that he has received the Statechain from Bob. Finally, the coordinator server must sign a new transaction allowing Charlie to unilaterally claim the Statechain on-chain before Bob sends Charlie a copy of the transitory key.
All of this is made atomic using adapter signatures. These are signatures that are modified in such a way using a random piece of data that renders them invalid, but can be made valid again once the holder of the signature receives that piece of information. All of the messages, and the new pre-signed transaction are signed with adapter signatures, and atomically made valid at the same time through the release of the adapter data.
Holders of a Statechain must trust that the coordinator server never conspires with a previous owner to sign an immediate closure of the Statechain and steal funds from the current owner, but the chain of pre-signed messages can prove that a coordinator has participated in theft if they were to do so. If a past owner attempts to use their pre-signed transaction to steal the funds, the timelock on the spend path using only their key allows the current owner to submit their pre-signed transaction and correctly claim the funds on chain.
Mercury and Mercury Layer
The original Statechain architecture requires a softfork in order to function. CommerceBlock designed their variant of Statechains to function without a softfork, but in order to do so tradeoffs were made in terms of functionality.
The basic idea is the same as the original design, all users hold a pre-signed transaction that allows them to claim their funds unilaterally, and the coordinator server still plays a role in facilitating off-chain transfers that requires them to be trusted to behave honestly. The two major differences are how those transactions are signed, and the structure of the pre-signed transaction users are given.
Where the signing is concerned, there is no longer a transitory private key that is passed from user to user. Instead of this, a multiparty-computation protocol (MPC) is used so that the original owner and the coordinator server are able to collaboratively generate partial pieces of a private key without either of them ever possessing the full key. This key is used to sign the pre-signed transactions. The MPC protocol allows the current owner and coordinator to engage in a second protocol with a third party, the receiver of a transfer, to regenerate different pieces that add up to the same private key. In both the Mercury and Mercury Layer protocol, after completing a transfer an honest coordinator server deletes the key material corresponding to the previous owner. As long as this is done, it is no longer possible for the coordinator to sign a transaction with a previous owner, as the new piece of key material they have is not compatible with the piece any previous owner might still have. This is actually a stronger guarantee, as long as the coordinator is honest, than the original proposal.
The pre-signed transaction structure for Mercury and Mercury Layer can’t use LN Symmetry, as this is not possible without a softfork. In lieu of this, CommerceBlock opted to use decrementing timelocks. The original owner’s pre-signed transaction is timelocked using nLocktime to a time far out in the future from the point of the Statechain’s creation. As each subsequent user receives the Statechain during a transfer, the nLocktime value of their transaction is some pre-determined length of time shorter than the previous owner. This guarantees that a previous owner is incapable of even trying to submit their transaction on-chain before the current owner can, but it also means that eventually at some point the current owner must close their Statechain on-chain before previous owners’ transactions start becoming valid.
The major difference between Mercury and Mercury Layer is how these transactions are signed. In the case of Mercury, the coordinator server simply sees the transaction proposed, verifies it, and then signs it. Mercury Layer uses a blind-signing protocol, meaning that they do not actually see any details of the transaction they are signing. This necessitates the server tracking Statechains using anonymized records on the server, and a special authorization key of the current owner so that they can be sure they are only signing valid transfers.
Synergy With Other Layers
Statechains can synergize with other Layer 2s that are based on pre-signed transactions. For instance, part of the original proposal suggested a combination of Statechains and Lightning Channels. Because both are simply pre-signed transactions, it is possible to actually nest a Lightning channel on top of a Statechain. This simply requires the current owner’s unilateral exit key to be a multisig, and the creation of the pre-signed transactions spending that output into a Lightning channel. This allows Lightning channels to be opened and closed entirely off-chain.
In a similar fashion, it is possible to nest a Statechain on top of a vUTXO in an Ark batch. This simply requires the pre-signed transactions necessary for a Statechain to be constructed, spending the vUTXO output.
Wrapping Up
Statechains are not entirely trustless, but they are a very trust minimized scheme that is very liquidity efficient and allows freely transferring UTXOs off-chain between any users willing to accept the trust model of Statechains.
While the original proposal has yet to be built, the two implementations designed by CommerceBlock have been completely implemented. Both failed to achieve anything more than marginal use in the real world. Whether this is due to users being unwilling to accept the trust model involved, or simply a failure in marketing or awareness is something that cannot be fully ascertained.
Regardless, given that there are two full implementations and designs for a more flexible variation should LN Symmetry ever become possible on Bitcoin, this an option that will always be here. The nice thing about open source software is that it will always be there regardless of whether people use it now, should they choose to in the future.
What is an economic node? To understand that, you need to first conceptually understand how a user interacts with the Bitcoin network in the first place.
Bitcoin is a database, and a network to facilitate the updating and synchronization of updates to that database, used for the primary purpose of people transacting bitcoin (entries in the database).
The primary concern of a user making use of Bitcoin for this purpose is the validity of the transactions sent to them, i.e. is the money they have received valid in the sense that when they go forward in the future to spend it somewhere else that other people will also widely accept it as valid. If that is not the case, then it is useless as money.
This is the purpose of a node, to verify these transactions. In order to do so, your node must have a complete set of all the existing coins (Unspent Transaction Outputs, or UTXOs) in order to check every proposed transaction against. When a transaction is broadcast, your node verifies that the coins it is spending are in this “UTXO set”, meaning that they have not been spent yet. When that transaction is confirmed in a block, those individual UTXOs are then removed from the UTXO set, and the new ones created by that transaction are added.
In order to compute that UTXO set in the first place, a node must parse through the entire historical record of all past transactions contained in the blockchain, going through the process of adding each newly mined UTXO to the set, and removing/adding all the consumed and newly created UTXOs processed in each individual block.
Without doing this, there is no way to be certain that the current UTXO set stored in your node is actually accurate and valid (in the future Zero Knowledge Proofs could obviate the need for this by replacing the historical blockchain with a succinct cryptographic proof that any given UTXO set is valid for a specific blockheight).
Your node is simply an agent for you as an economic actor, in the sense of automated AI agents that many LLM advocates speak about. It is an autonomous program acting on your behalf in a certain context, in this case guaranteeing the validity of bitcoin transactions to ensure that when you are the recipient of one, the chain of transactions that created the coin spent to you is valid.
An economic node is simply a node that is actually being used by someone engaging in economic activity to ensure the validity of the coins they are receiving.
Why is that so important? Why do only these nodes matter?
Think about what makes Bitcoin function in the first place: people running the same consensus rules. The only reason there is a coherent singular Bitcoin network is because everyone is running the same consensus rules, when miners produce blocks, every individual node arrives at the same conclusion as to whether or not it is valid. Every individual node will follow whatever is the blockchain composed of valid blocks that has the most proof-of-work attached to it.
There is only a singular coherent Bitcoin network because each individual actor chooses to enforce the same set of consensus rules against blocks that miners produce. It is purely voluntary association, voluntary subjugation of oneself to a certain set of consensus rules.
So to illustrate the point, let’s imagine three different scenarios of nodes deviating from the existing set of rules.
In the first scenario, imagine a few major exchanges like Kraken, Coinbase, etc. all alter their consensus rules from the rest of the network (softfork vs. hardfork are a distraction from the point, so we are going to ignore the distinction here). These nodes represent the economic platforms where bitcoin is traded, and its price established in fiat terms. Nodes running conflicting rules from them, or making transactions that will not be recognized as valid by their nodes to be more specific, now cannot engage in that market.
Those exchanges’ nodes will not recognize user deposits as valid, and as such they will not be able to deposit coins and participate in those marketplaces. Other nodes can band together, but they cannot capture the economic power of those exchanges. Ultimately, short of the value of the coin created by the ruleset they are enforcing crashing to nothing, other nodes on the network will have no choice but to adopt their ruleset in order to interact with them. Otherwise the exchanges will simply ignore and honor honor deposits their nodes consider invalid.
In the second scenario, let’s imagine a group of much smaller businesses and users that regularly receive transactions. Maybe all of them together amount to the economic activity of a single exchange like Coinbase. These users choosing to alter their consensus rules is not as inescapable as a number of large exchanges in concert, but it is still significant.
Here, other users can still access marketplaces like exchanges to ensure that bitcoin is being priced by the market. The majority of the network will still accept everyone else’s coins in receipt for goods, or as deposits to trade on marketplaces. But they still represent a sizable portion of economic activity withdrawing from the rest of the network. This is leverage they can use.
Even as a minority of the network, the likelihood is extremely high that there are significant levels of economic activity crossing between this minority of nodes and the rest of the network. This is not a clear case of leaving the rest of the network no option but to adopt the new rules, but it definitely creates pressure for large portions of the network who interact across that “gap.”
From there the more users that choose to cross the gap because of who they economically interact with, that pressure grows larger for the rest of the remaining network.
In the last scenario, let’s imagine a group of nodes representing a small set of users generating very little or no economic activity at all. These users choose to alter their ruleset. They receive almost no payments, they represent a rounding error in terms of economic value on the network.
They’re irrelevant to the rest of the network. Large businesses, exchanges, other economic actors, they will not care if a handful of people stop patronizing them or sending them bitcoin for different reasons. This set of nodes altering their consensus rules doesn’t matter. They create no pressure or opportunity cost that matters for the rest of the network.
An economic node’s influence on the overall consensus of the Bitcoin network is proportional to the amount of economic activity involving that node/its owner.
A node that is not being used for this purpose is completely irrelevant to the consensus rules of the Bitcoin network at large. It creates no economic pressure, imposes no opportunity cost, on the rest of the network when it alters its consensus rules. It is indistinguishable from a participant in a sybil attack.
There might be other reasons to run a node besides verifying your own transactions, such as direct access to blockchain data for research or analysis purposes, but ultimately that node is irrelevant to consensus.
This dynamic is why Bitcoin cannot be sybil attacked. It’s why some malicious actor can spin up a million nodes on Amazon Web Services running different consensus rules, and it will have zero effect on the actual Bitcoin network.
Your node doesn’t matter, unless you use it. So use it.
Ark is a novel off-chain transaction batching mechanism originally proposed by Burak, a young Turkish developer. There are currently two implementations being built, one by Ark Labs, and the other by Second, neither of which Burak is involved with.
The original proposal for Ark was much more complicated, and involved some design goals more focused around privacy than the implementations currently being built. It was also originally envisioned to require CHECKTEMPLATEVERIFY (CTV) in order to be built.
The protocol depends on a central coordinating server in order to function properly, but despite that is able to provide the same functionality and security guarantees that the Lightning Network does. As long as a user stays online during the required time period, at all times (unless they choose to trust the operator for short periods of time) every user is capable at any time of unilaterally exiting the Ark system at any time and taking back full unilateral control of their funds onchain.
Unlike Lightning, Ark does not require users to have pre-allocated liquidity assigned to them in order to receive funds. An Ark user can simply onboard to a wallet and receive funds immediately with no liquidity pre-allocation at all.
Let’s walk through the different constituent pieces of Ark.
The Ark Tree
Coins held on Ark are called Virtual UTXOs (vUTXOs). These are simply pre-signed transactions that guarantee the creation of a real UTXO under the unilateral control of a user once submitted onchain, but are otherwise held offchain.
Every user’s vUTXOs are nested inside a tree of pre-signed transactions, or a “batch.” Ark works by having the coordinator server, or Ark Service Provider (ASP), facilitate the coordination between users necessary to create a batch. Whenever users are receiving funds, onboarding to Ark, or offboarding, it is necessary to construct a transaction and the associated transaction tree to create a new batch.
The tree is constructed to take the single root UTXO confirmed onchain, locked with an n-of-n multisig including all users holding vUTXOs in the tree as well as the ASP, and slowly split into more and more UTXOs until eventually reaching the leaves, which are each users vUTXO. Each vUTXO is guaranteed using a script that has to be signed by a 2-of-2 multisig, one key held by the user, and the other by the ASP, or just the user after a timelock.
Each time the tree splits, vUTXOs are created onchain, but so are more internal UTXOs that have yet to actually split into vUTXOs. Each of these internal UTXOs is locked with an n-of-n multisig composed of the ASP, and all users who have a vUTXO further down the tree. During the batch creation process, users start at their respective vUTXOs, and go through a signing process all the way back down the root of the tree. This guarantees that the root will never be signed before each user’s claim to a vUTXO is, ensuring they always have unilateral access in a worst case scenario to their funds.
Each batch also has an expiry time (which will make sense in the next section). This expiry spend path, which exists as an alternate spending condition for the root UTXO onchain as well as every internal UTXO, allows the ASP to unilaterally spend all funds by itself.
Transactions, Preconfirmation, and Connector Inputs
When it comes to transacting on Ark, there are two possible mechanisms that are possible, both with their own costs and implications in terms of security model. There are out-of-round transfers, or preconfirmed transactions, and there are in-round transfers, or actually confirmed transactions.
To conduct an out-of-round transfer is a very simple process. If one user (Alice) wants to pay another (Bob), they simply contact the ASP and have them co-sign a transaction spending the vUTXO to Bob. Bob is then given that pre-signed transaction, as well as all the other ones preceding it back to the batch root onchain. Bob is now capable of unilaterally exiting the Ark with this transaction, but, he must trust the ASP not to collude with Alice to doublespend it. These out-of-round transactions can even be chained multiple times before finally confirming them.
To finalize an Ark transaction, users have to engage in a “batch swap.” Users cannot actually trustlessly confirm a transfer within a single batch, they have to atomically swap a vUTXO in an existing batch with a fresh vUTXO created in a new batch. This is done using the ASP as a facilitator of the swap, and with the aid of what is called a “connector input.”
When a user goes to finalize an Ark transaction with a batch swap, they relinquish control of the vUTXO to the ASP. This could be problematic, what is to stop the ASP from simply keeping it and not giving them a confirmed vUTXO in a new batch? The connector input.
When a new batch is created, a second output is created in the transaction that is confirmed on chain instantiating a new tree composed of connector UTXOs. When Bob goes to sign over a forfeit transaction to the ASP to conduct the batch swap, the transaction includes as an input one of the connector UTXOs from the new batch.
This creates an atomic guarantee. Bob’s confirmed vUTXO is included in a batch in the same transaction the connector input is created in that is necessary for his forfeit transaction to be valid. If that batch is never created onchain, i.e. Bob never actually receives the new confirmed vUTXO, then the forfeit transaction he signed for the ASP will never be valid and confirmable onchain.
Liquidity Dynamics and Blockspace
All of the liquidity necessary to create new batches in order to facilitate transfers between users is provided by the ASP. They are required to have enough liquidity to create new batches for users until old ones have expired and the ASP can unilaterally sweep them to reclaim old liquidity previously locked up to create vUTXOs for users.
This is the core of the liquidity dynamic at the center of the Ark protocol. While in one sense this is a massive efficiency win, not requiring liquidity providers to assess users and essentially guess which ones will actually receive large volumes of payments before they can receive any funds, in another it is an efficiency loss as the ASP must have enough liquidity to continue creating new batches for users for however long they configure the expiry time to be and they can start reclaiming allocated liquidity.
This can be mitigated to a decent degree by how often an ASP offers to create new batches to finalize pending transactions. In the event of an ASP attempting to create new batches in real time as transactions are coming in, the liquidity requirements would be exorbitantly high. However, an ASP can lower the frequency at which they create new batches and drastically lower their liquidity requirements.
This dynamic also has implications for blockspace use. Unlike Lightning, which can provide strong confirmation guarantees entirely offchain, in order for an Ark transaction to have an equivalent trustless degree of finality a new batch has to be created onchain. This means that unlike Lightning, where transaction volume does not reflect itself onchain, the velocity of Ark transactions inherently requires a proportional amount of blockspace use, albeit in a very compressed and efficient manner. This creates a theoretical upper limit of how many Ark batches can be created during any given time interval (although Ark trees can be smaller or larger depending on this dynamic).
Wrapping Up
Ark presents in many ways an almost opposite set of tradeoffs to the Lightning Network. It is a massive blockspace efficiency improvement for offchain transactions, and does away with the problem of liquidity allocation on the Lightning Network, but it does have a much closer tied throughput limit that is correlated with the blockchains throughput limit.
This dynamic of almost opposite tradeoffs makes it a very complementary system to the Lightning Network. It can also interoperate with it, i.e. vUTXOs can be swapped atomically in transactions entering or exiting the Lightning Network.
Ultimately how it fits into the broader Bitcoin ecosystem is yet to be seen, but it is an undoubtedly valuable protocol stack that will find some functional niche, even if it is different than originally intended.
Bitcoin, and for that matter all blockchains, do not scale. It is a fundamental limitation of blockchain based systems that they are incapable of facilitating transactional use at a truly global scale without completely sacrificing the decentralization and verifiability that make them valuable in the first place.
This has been an existential issue that Bitcoiners have grappled with from the very beginning of Bitcoin. This is a comment from James A. Donald, a Canadian cypherpunk who was the first person to reply to Satoshi’s original post on the cryptography mailing list:
Satoshi Nakamoto wrote:
“The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.”
The trouble is, you are comparing with the Bankcard network.
But a new currency cannot compete directly with an old, because network effects favor the old.
You have to go where Bankcard does not go.
At present, file sharing works by barter for bits. This, however requires the double coincidence of wants. People only upload files they are downloading, and once the download is complete, stop seeding. So only active files, files that quite a lot of people want at the same time, are available.
File sharing requires extremely cheap transactions, several transactions per second per client, day in and day out, with monthly transaction costs being very small per client, so to support file sharing on bitcoins, we will need a layer of account money on top of the bitcoins, supporting transactions of a hundred thousandth the size of the smallest coin, and to support anonymity, chaumian money on top of the account money.
Let us call a bitcoin bank a bink. The bitcoins stand in the same relation to account money as gold stood in the days of the gold standard. The binks, not trusting each other to be liquid when liquidity is most needed, settle out any net discrepancies with each other by moving bit coins around once every hundred thousand seconds or so, so bitcoins do not change owners that often, Most transactions cancel out at the account level. The binks demand bitcoins of each other only because they don’t want to hold account money for too long. So a relatively small amount of bitcoins infrequently transacted can support a somewhat larger amount of account money frequently transacted.
Despite the era of the Blocksize Wars, the big blockers, and the naive assumptions by many early Bitcoiners that simply raising the blocksize was a viable solution to scale the system, it has been understood by competent observers and engineers from the very beginning that this would undermine the core value proposition of that made it useful in the first place. Hal Finney also spoke of the need for such a settlement layer on top.
Scaling in layers has always been the only rational plan to make Bitcoin work in the long term, but for a long period of Bitcoin’s early history how to do so without relying on trusted third parties was an elusive problem.
One of the first ideas on how to do this was sidechains, independent blockchains with a peg to facilitate locking bitcoin on the mainchain to utilize on the sidechain, and at any point unlocking funds on the mainchain to move them back by proving legitimate control of bitcoin on the sidechain. These systems however have yet to achieve a way to operate a peg without either 1) introducing some form of trusted third party, no matter how well mitigated, or 2) creating centralization pressure for the primary Bitcoin network.
Since those early days there have been many more ideas developed that have found better ways to peg into second layer systems, specifically schemes like the Lightning Network and Ark which allow end users to unilaterally exit back to the mainchain without needing the permission or approval of some operator.
Scaling Bitcoin in a way that facilitates higher transactional volumes without degrading the security properties of Bitcoin to the point of being indistinguishable from third party operated custodians is one of the most critical problems to solve in order for Bitcoin to truly succeed in the long term.
This article series will explore the architectures of different Layer 2 systems for Bitcoin, both those deployed live on the network right now and those that are simply design proposals at this point.
Listed below are the systems I will be covering. The design space of Layer 2s is much more expansive than many people are familiar with, so this list should not be taken as comprehensive and complete, and will be updated over time to reflect additional Layer 2s that are covered.
Contribute(s/ed) To: Ocean Sidechain, Mainstay, Mercury Wallet, Mercury Layer
Work(s/ed) At: CommerceBlock (formerly)
Prior to Bitcoin, Nicholas was a software developer working in the financial system for banking firms developing trading and derivatives platforms. After the 2008 financial crisis he began to consider alternatives to the legacy financial system in the fallout.
Like many from that time, he completely ignored the original Slashdot article featuring the Bitcoin whitepaper due to the apparent focus on Windows as an application platform (Nicholas was a UNIX/Linux developer). Thankfully someone he knew introduced him to Bitcoin later on.
The thing that captured his interest about Bitcoin rather than other alternatives at the time was its specific architecture as a distributed computer network.
“The fact that it was like an alternative way. It was all based around [a] kind of […] network. And what I mean by that, building financial systems, people always wanted a system that was 24-7.
And how do you deal with someone interacting [with] it in different geographical parts of the world without it being centralized?
And I’d seen various ways of people solving that problem, but it never had been done, you know, in a kind of […] scalable solution. And using […] cryptography and proof of work to solve that issue was just weird, to be honest. It was totally weird for me.”
All of the other systems he had designed, and some that he built, were systems distributed across multiple parts of the world. Unlike Bitcoin however, these systems were permissioned and restricted who could update the relevant database(s) despite that fact that copies of them were redundantly distributed globally.
“The fact that in Bitcoin you had everyone kind of doing this proof of work game, which is what it is. And whoever wins does the [database] write. That mess[ed] with my head. That was […] very unique.”
Beginning To Build
Nicholas’s path to building in the space was an organic one. At the time he was living in New York City, and being a developer he of course found the original Bitdevs founded in NYC. Back then meetups were incredibly small, sometimes even less than a dozen people, so the environment was much more conducive to in-depth conversations than some larger meetups these days.
He first began building a “hobbyist” Over The Counter (OTC) trading software stack for some people (back then a very significant volume of bitcoin was traded OTC for cash or other fiat mediums). From here Nicholas and Omar Shibli, whom he met at Bitdevs, worked together on Pay To Contract (BIP 175).
BIP 175 specifies a scheme where a customer purchasing a good participates in generating the address the merchant provides. This is done by the two first agreeing on a contract describing what is being paid for, afterwards the merchant sends a master public key to the consumer, who uses the hash of that description of the item or service to generate an individual address using the hash and master public key.
This allows the customer to prove what the merchant agreed to sell them, and that the payment for the good or service has been made. Simply publishing the master public key and contract allows any third party to generate the address that was paid, and verify that the appropriate amount of funds were sent there.
Ocean and Mainstay
Nicholas and Omar went on to found CommerceBlock, a Bitcoin infrastructure company. Commerceblock took a similar approach to business as Blockstream, building technological platforms to facilitate the use of Bitcoin and blockchains in general in commerce and finance. Shortly afterwards Nicholas met Tom Trevethan who came on board.
“I met Tom via, yeah, a mutual friend, happy to say who it is. There’s a guy called, who, new people probably don’t know who he is, but OGs do, John Matonis. John Matonis was a good friend of mine, [I’d] known him for a while. He introduced me to Tom, who was, you know, kind of more on the cryptography side. And it kind of went from there.”
The first major project they worked on was Ocean, a fork of the Elements sidechain platform developed by Blockstream that the Liquid sidechain was based on. The companies CoinShares and Blockchain in partnership with others launched an Ocean based sidechain in 2019 to issue DGLD, a gold backed digital token.
“So we, you know, we were working on forks of Elements, doing bespoke sidechains. […] Tom had some ideas around cryptography. And I think one of our first ideas was about how to bolt on these forks of Elements onto […] the Bitcoin main chain. […] We thought the cleanest way to do that was […] using some sort of, I can’t remember, but it was something [based on] single-use sealed sets, which was an invention by Peter Todd. And I think we implemented that fairly well with Mainstay.”
The main distinction between Ocean and Liquid as a sidechain platform is Ocean’s use of a protocol designed at Commerceblock called Mainstay. Mainstay is a timestamping protocol that, unlike Opentimestamps, strictly orders the merkle tree it builds instead of randomly adding items in whatever order they are submitted in. This allows each sidechain to timestamp its current blockheight into the Bitcoin blockchain everytime mainchain miners find a block.
While this is useless for any bitcoin pegged into the sidechain, for regulated real world assets (RWA), this provides a singular history of ownership that even the federation operating the sidechain cannot change. This removes ambiguity of ownership during legal disputes.
When asked about the eventually shuttering of the project, Nicholas had this to say:
“I don’t know if we were early, but we had a few clients. But it was, yeah, there wasn’t much adoption. I mean, Liquid wasn’t doing amazing. And, you know, being based in London/Europe, whenever we met clients to do POCs, we were competing against other well-funded projects.
It shows how many years ago they’d either received money from people like IBM or some of the big consultancies and were promoting Hyperledger. Or it was the days when we would be competing against EOS and Tezos. So because we were like a company that needed money to build prototypes or build sidechains, it kind of made it very hard. And back then there wasn’t much adoption.”
Mercury Wallet and Mercury Layer
After shutting down Ocean, Nicholas and Tom eventually began working on a statechain implementation, though the path to this was not straightforward.
“[T]here were a few things happening at the same time that led to it. So the two things were we were involved in a [proof of concept], a very small […]POC for like a potential client. But this rolled around Discreet Log Contracts. And one of the challenges of Discreet Log Contracts, they’re very capital inefficient. So we wanted a way to novate those contracts. And it just so happened that Ruben Sampson, you know, wrote this kind of white paper/Medium post about statechains. And […] those two ideas, that kind of solved potentially that issue around DLCs.”
In the end they did not wind up deploying a statechain solution for managing DLCs, but went in a different direction.
Well, there was another thing happening at the same time, coinswaps. And, yeah, bear in mind, in those days, everyone worried that by […] 2024/2025 […] network fees could be pretty high. And to do […] coin swaps, you kind of want to do multiple rounds. So […] state chains felt perfect because […] you basically take a UTXO, you put it off the chain, and then you can swap it as much as you want.”
Mercury Wallet was fully built out and functional, but sadly never gained any user adoption. Samourai Wallet and Wasabi Wallet at the time dominated the privacy tool ecosystem, and Mercury Wallet was never able to successfully take a bite out of the market.
Rather than completely give up, they went back to the drawing board to build a statechain variant using Schnorr with the coordinator server blind signing, meaning it could not see what it was signing. When asked why those changes were made, he had this to say: “That would give us a lot more flexibility to do other things in Bitcoin with L2s. You know, the moment you have a blinded solution, we thought, well, this could start having interoperability with Lightning.”
Rather than building a user facing wallet this time, they built out a Software Development Kit (SDK) that could be integrated with other wallets.
“{…] I guess with Mercury Layer, it was very much building a kind of […] full-fledged Layer 2 that anyone could use. So we [built] it as an SDK. We did have a default wallet that people could run. But we were hoping that other people would integrate it.”
The End of CommerceBlock
In the end, CommerceBlock shuttered its doors after many years of brilliant engineering work. Nicholas and the rest of the team built numerous systems and protocols that were very well engineered, but at the end of the day they seemed to always be one step ahead of the curve. That’s not necessarily a good thing when it comes to building systems for end users.
If your work is too far ahead of the demand from users, then in the end that isn’t a sustainable strategy.
“…being in the UK, which is not doing that well from a regulatory point of view, played into it. If I was living in Dubai, maybe that would have been a different conversation. You know, back when we made that decision…things weren’t great in the US. I think things have improved there. But also, I think…Bitcoin is in a good place financially. I think it’s clearly being used as a product. But I think the L2s in the space just don’t have much user adoption.”
When asked why he thought people were not using Layer 2s at scale, he had this to say: “…in my adventures of working on CivKit (a decentralized marketplace), one of the questions that was always posed to me is, when Tether, when stablecoins? So when you’re working on a project that’s trying to promote Bitcoin in the global south, but everyone you meet in the global south wants stablecoins, you start to wonder, well, am I building the right tool? Do people even want to use this?”
At the end of the day, the most useful and sound engineering work still needs to be adopted and used, otherwise what is the value of it in the first place?
“…there has been a shift in the last four years for it to be a store of wealth. And I do think that’s a risk because I think if people were using Bitcoin right now and the mempool was expensive, was jammed up and fees were high, there’s enough bright people to build good L2s. But they’re not being built because there’s no demand. And, you know, no one wants to build software, whether that’s open source or commercially, when it’s just a bunch of hobbyists using it. And I think that’s one of the challenges of Bitcoin right now. We have a lack of users and maybe down the line that’s a problem.”
“I think there’s a lot of smart people in Bitcoin that can build interesting stuff, but I think the focus now has to be users.”
In the last Mempool article, I went through the dynamics of transaction propagation when different nodes on the network are running different mempool relay policies. In this piece I’ll be looking at the dynamics of private mempools, and the implications that has for the utility of the public mempool, mining incentives, and the health of the Bitcoin network overall.
At the heart of the purpose of the mempool is facilitating the aligned incentives of two different parties, miners and transacting users. Users want to transact, and are willing to pay miners’ transaction fees in order to do so. Miners want to make money, and transaction fees are an additional source of revenue in addition to the new coin subsidy in each block, as well as a necessary primary revenue source to cultivate in the long term as the subsidy dwindles.
Bitcoin is a system secured by incentives. This core dynamic is what drives the security of the system, you have a customer(s) and a provider, and the two of them attempting to fulfill their wants and needs is what ensures the blockchain continues ticking forward with a sufficient amount of thermodynamic security.
Attempts to introduce friction into this facilitation mechanism does not ultimately do anything at all to change the incentives of these two parties. A user who wants to make a certain kind of transaction is still going to want to make that transaction, and pay for it. A miner who is willing to accept those kinds of transactions is still going to want to accept them, and collect the fee by including them in a block.
If the transaction is valid, then these two parties are still going to have their unmet wants and needs, and are still going to be strongly motivated to meet them in some form or fashion.
Miner API
Individual end users are not necessarily capitalized enough or competent enough in order to route around friction artificially introduced between both ends of a coincidence of wants, but miners most definitely are. As the old adage goes, “if you build it, they will come.”
The preferential situation for miners is obviously to acquire fee paying transactions in-band through the public mempool. It requires the lowest overhead possible for them, simply running a standard Bitcoin client out of the box, it is a very resilient propagation mechanism that ensures a very high degree of reliability in getting miners the highest fee paying transactions, and they don’t have to do anything. Just download the client and run it.
However, in a very hostile environment such as a network wide effort to filter consensus valid transactions during their propagation across the network, that traditional assumption can be drawn into question.
In such a scenario miners have every incentive to set up out-of-band mechanisms for accepting transactions that are not properly being relayed across the network. Marathon’s Slipstream API for non-standard transactions is not the only example of this. There is in fact a long standing precedent from almost ten years ago that was widely implemented by many mining pools, and still exists to this day. Transaction accelerators.
We now live in a world of Full-RBF, where any transaction, regardless of using the historical “opt-in” flag, can be fee-bumped. Any node who has upgraded to Full-RBF will relay any transaction that is spending an unconfirmed output already pending in the mempool as long as it is paying a higher fee. This has not always been the case. Historically only transactions that were originally made with a flag to opt-in to RBF use could be replaced and expected to propagate across the network.
Transaction accelerators were created by miners in order to facilitate this behavior for transactions that did not opt-in to RBF use.
Third Party APIs
While the overhead is not exorbitantly high for a miner or pool to create their own transaction submission API, it isn’t free. It still does require at least one developer and time to go through the design and release cycle of any piece of software. The curve isn’t particularly exaggerated, but it still does favor larger miners over smaller ones in terms of how much resources they will have to devote to such an endeavor.
Mempool.space has proven that it is a viable endeavour for a third party unrelated to miners to create such an API, allowing miners to simply connect to their service rather than expend the effort to create one themselves from scratch. This does have its issues though, such a third party is not going to build and operate such a service for free. They will want their cut.
There are two ways that this dynamic can go, either these services wind up requiring a higher cost in order to allow both the miners and service providers to earn revenue, or miners will have to share a smaller cut of the revenue in order for such services to remain competitive with directly miner operated ones. This means miners using a third party submission API rather than their own will earn less revenue than the miners operating their own API.
Private Order Flow
Either of the above possibilities introduces serious problems when it comes to the overall system incentives, reliability of end-user software, and potentially even the security model of second layer systems that rely on the use of pre-signed transactions and a reactive security model in order to keep user funds safe.
When transactions are submitted to a private API, they are not visible to network participants until they are actually confirmed in a block. The entire queue of unconfirmed transactions making use of these systems is opaque. This could be made public by the operators of these APIs, but not in a trustless fashion. There is no way to prove or guarantee that operators are not withholding information.
Withholding transactions from public view could distort fee estimates that users make, and even open the door to the possibility of manipulating those feerates by stuffing blocks with their own transactions. Transactions used in the operation of second layer systems could be withheld from public view until confirmation, which can delay users ability to react to transactions they must respond to in order to guarantee the security of their funds.
Lastly, just the existence of such APIs if the demand or need for them is high enough is a massive centralization pressure. Having to handle connecting to each individual API to submit a transaction is a hassle, poor UX, and potential back end complexity. This tends to reinforce the use of the largest API(s) and ignoring the tailend, which creates a feedback loop.
The API operators with the largest hashrate will have the quickest and most reliable confirmations, guaranteeing only those largest miners reliably earn this extra revenue, giving them more capital to grow larger, etc.
Parallel Mempools
On the other end of the spectrum is the possibility of creating totally independent public relay networks. While this does replicate the current openness of the existing public mempool, and avoids the worst of the centralizing pressures of central APIs, it still is not ideal.
Having multiple mempools introducing complexity for miners, for end users, and for end user applications. Users now need to keep track of all the independent mempools, especially ones used for systems they interact with that are not propagated over the primary relay network, in order to have a view of unconfirmed transactions.
If Lightning (or some other Layer 2) were to start making use of a parallel mempool, tracking it would be critical for any user of Lightning (or that other Layer 2). It would also be necessary to track all of the parallel relay networks in order to have an accurate view of the other unconfirmed transactions you are bidding against for inclusion in the next block. Tracking only a subset of them would lead to potentially large margins of error in any users fee estimation.
You Just Make Things Worse
Trying to prevent transactions with willing fee paying users without addressing them at the consensus level is just not possible. Bitcoin is an engine driven by incentives, and when the incentives of multiple parties align they will be facilitated in one form or another.
Trying to pretend that is not the case, and that things can be stopped, disincentivized, or otherwise delayed is a fool’s errand. Not only that, but trying at any serious scale comes with very serious negative consequences, in addition to being doomed to fail.
Bitcoin’s consensus rules are the framework in which incentives are played out. The only thing that can trump incentives is changing that framework. It is literally what informs and shapes the incentives in the first place.
Trying to interfere with those incentives at any other layer is a fool’s errand, and can do nothing but exacerbate the negative outcomes driven by incentives, i.e. centralization.
In the last Mempool article, I went over the different kinds of relay policy filters, why they exist, and the incentives that ultimately decide how effective each class of filter is at preventing the confirmation of different classes of transactions. In this piece I’ll be looking at the dynamics of the relay network when some nodes on the network are running different relay policies compared to other nodes.
All else being equal, when nodes on the network are running homogenous relay policies in their mempools, all transactions should propagate across the entire network given that they pay the minimum feerate necessary not to be evicted from a node’s mempool during times of large transaction backlogs. This changes when different nodes on the network are running heterogenous policies.
The Bitcoin relay network operates on a best effort basis, using what is called a flood-fill architecture. This means that when a transaction is received by one node, it is forwarded to every other node it is connected to except the one that it received the transaction from. This is a highly inefficient network architecture, but in the context of a decentralized system it provides a high degree of guarantee that the transaction will eventually reach its intended destination, the miners.
Introducing filters in a node’s relay policy to restrict the relaying of otherwise valid transactions in theory introduces friction to the propagation of that transaction, and degrades the reliability of the network’s ability to perform this function. In practice, things aren’t that simple.
How Much Friction Prevents Propagation
Let’s look at a simplified example of different network node compositions. In the following graphics blue nodes represent ones that will propagate some arbitrary class of consensus valid transactions, and red nodes represent ones that will not propagate those transactions. The collective set of miners is denoted in the center as a simple representation of where transacting users ultimately want their transactions to wind up so as to eventually be confirmed in the blockchain.
This is a model of the network in which the nodes refusing to propagate these transactions are a clear minority. As you can clearly see, any node on the network that accepts them has a clear path to relay them to the miners. The two nodes attempting to restrict the transactions propagation across the network have no effect on their eventual receipt by miners’ nodes.
In this diagram, you can see that almost half of the example network is instituting filtering policies for this class of transactions. Despite this, only part of the network that propagates these transactions is cut off from a path to miners. The rest of the nodes not filtering still have a clear path to miners. This has introduced some degree of friction for a subset of users, but the others can still freely engage in propagating these transactions.
Even for the users that are affected by filtering nodes, only a single connection to the rest of the network nodes that are not cut off from miners (or a direct connection to a miner) is necessary in order for that friction to be removed. If the real relay network were to have a similar composition to this example, all it would take is a single new connection to alleviate the problem.
In this scenario, only a tiny minority of the network is actually propagating these transactions. The rest of the network is engaging in filtering policies to prevent their propagation. Even in this case however, those nodes that are not filtering still have a clear path to propagate them to miners.
Only this tiny minority of non-filtering nodes is necessary in order to ensure their eventual propagation to miners. Preferential peering logic, i.e. functionality to ensure that your node prefers peers who implement the same software version or relay policies. These types of solutions can guarantee that peers who will propagate something to others won’t find each other and maintain connections amongst themselves across the network.
The Tolerant Minority
As you can see looking at these different examples, even in the face of an overwhelming majority of the public network engaging in filtering of a specific class of transactions, all that is necessary for them to successfully propagate across the network to miners is a small minority of the network to propagate and relay them.
These nodes will essentially, through whatever technical mechanism, create a “sub-network” within the larger public relay network in order to guarantee that there are viable paths from users engaging in these types of transactions to the miners willing to include them in their blocks.
There is essentially nothing that can be done to counter this dynamic except to engage in a sybil attack against all of these nodes, and sybil attacks only need a single honest connection in order to be completely defeated. As well, an honest node creating a very large number of connections with other nodes on the network can raise the cost of such a sybil attack exorbitantly. The more connections it creates, the more sybil nodes must be spun up in order to consume all of its connection slots.
What If There Is No Minority?
So what if there is no Tolerant Minority? What will happen to this class of transactions in that case?
If users still want to make them and pay fees to miners for them, they will be confirmed. Miners will simply set up an API. The role of miners is to confirm transactions, and the reason they do so is to maximize profit. Miners are not selfless entities, or morally or ideologically motivated, they are a business. They exist to make money.
If users exist that are willing to pay them money for a certain type of transaction, and the entirety of the public relay network is refusing to propagate those transactions to miners in order to include them in blocks, miners will create another way for users to submit those transactions to them.
It is simply the rational move to make as a profit motivated actor when customers exist that wish to pay you money.
Relay Policy Is Not A Replacement For Consensus
At the end of the day, relay policy cannot successfully censor transactions if they are consensus valid, users are willing to pay for them, and miners do not have some extenuating circumstances to turn down the fees users are willing to pay (such as causing material damage or harm to nodes on the network, i.e. crashing nodes, propagating blocks that take hours to verify on a consumer PC, etc.).
If some class of transactions is truly seen as undesirable by Bitcoin users and node operators, there is no solution to stopping them from being confirmed in the blockchain short of enacting a consensus change to make them invalid.
If it were possible to simply prevent transactions from being confirmed by filtering policies implemented on the relay network, then Bitcoin would not be censorship resistant.
The current “debate”, and even calling it that is me being wildly over-charitable, over OP_RETURN is one of the most absurd situations I have ever seen in this space. I say that as someone who has been in Bitcoin for over a decade. Even the blocksize wars don’t hold a candle to this, at least in terms of utter absurdity. At least back then it was focused around an actual engineering disagreement.
I want to comment on one thing today though. Stop directing your irrational rage and nonsense at the wrong targets. You aren’t mad at Bitcoin Core, you are mad at me.
NO ONE can alter your node except you. NO ONE can make you download a version of Bitcoin Core that changes something except you. End of story. Full stop. YOU are responsible for your node, what it enforces, and what it does. You and you alone.
The entire issue of removing the OP_RETURN limit has nothing to do with Bitcoin Core “forcing” anything on anyone. They literally cannot do that, it is impossible to. All they are doing with this pull request is acknowledging the reality of people like me. They are making a logical engineering decision in the face of a minority of users who will not run clients enforcing current OP_RETURN limits.
I will never run a node that is configured to enforce these limits. Ever. It’s that simple. I do not think it is my job, or my place, or my right to arbitrate or decide what types of consensus valid transactions other users make. Period. If it’s consensus valid and pays a fee, it’s not my business. If you have a problem with transactions that are consensus valid, address that problem where it should be, at the consensus level. As someone is so well known for quipping constantly in this nonsense: use the right tool for the job.
Bitcoin is supposed to be a permissionless system, and that actually means something to me.
As long as people like me will not enforce the relay filter on OP_RETURN that many people are upset with, your use of that filter is pointless. It accomplishes nothing. It does not stop these transactions from being relayed across the network. It does not stop them from getting mined in blocks. It accomplishes nothing. It is a pointless feature from an engineering perspective.
All Core developers proposed doing is to acknowledge this reality that is entirelyoutside of their control.
Core developers are not the ones configuring datacarriersize to the maximum limit, or running LibreRelay, or building the private miner APIs/mempools that allow direct access to blockspace bypassing public mempools. They have nothing to do with any of this.
All they are doing is reacting to the actions of othersto mitigate harm to the network.
If you want to get angry about this, that’s your prerogative. If you want to “take action” against the people who created this situation, that is also your prerogative. But direct it in the appropriate direction: the other users of Bitcoin who have created this situation that developers must react to.
Don’t be a chickenshit directing your rage at a party not responsible for this situation just because you think they’re an easier target. Be a man and direct your anger where it belongs
This article is a Take. Opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
In my prior article on the mempool, I laid out a simple conceptual framework to reason about the basic functionality of the mempool, and how it was used by different kinds of users of the Bitcoin network. In this piece I will be looking at the differences between relay policy and consensus rules, and why by default Bitcoin nodes do not relay some types of bitcoin transactions despite being consensus valid.
First and foremost, regardless of the peer-to-peer network refusing to relay certain kinds of consensus valid transactions, if those transactions were to wind up in a miner’s mempool and be selected for inclusion in a block, they will be received and downloaded by nodes when they receive that block. Nothing can prevent this short of consensus changes to make those classes of transactions invalid under consensus rules.
There are different types of filters for different reasons. The three general types of filters are those protecting nodes (and therefore the network) from Denial of Service (DoS), those protecting upgrade hooks for future softforks, and those gently discouraging things that Bitcoiners might not like but otherwise present no serious harm to individual nodes or the network.
Denial of Service Vectors
Bitcoin nodes are computer programs running on computers. This means they have all the technical constraints of any programming running on any computer, limitations for storage, memory, processing power, etc. This is the root of why the blocksize limit was introduced and maintained, so as to create a global constraint keeping the verification costs reasonable for normal devices.
This class of filters is designed specifically to ensure that even with the blockspace limit individual transactions that can be created that can consume too much of a node’s resources do not do so.
The simplest example of such a filter is the minimum feerate needed for a transaction to propagate, and the Replace-By-Fee (RBF) rules dictating when a different version of the same transaction can replace the previous one, i.e. only when it pays a higher fee than the last version. Once you sign a transaction with a fee, you are on the hook. Unless you doublespend it, any miner who gets that transaction can mine it and collect that fee. There is no way to escape paying that cost other than spending your UTXO in a different transaction first (which also requires a fee).
The reason for this is DoS protection. Without having to put themselves on the hook for a fee that they can’t escape paying, a user could simply create infinite variations of a single transaction and spam the mempools of every node on the network, eating bandwidth and memory in the process. Nothing would be stopping them from doing this forever. Nodes on the network would outright crash, or bandwidth costs become so exorbitantly high that users couldn’t afford them.
Another example of transactions filtered by relay policy are expensive to validate transactions. It is possible to create transactions that are incredibly expensive to verify. Some blocks can be created that will take a Bitcoin node running on normal consumer hardware over an hour to verify. This is done by creating large custom scripts that are designed to create the maximum amount of signature checks that can be and stuffing a block full of nothing but these transactions.
Such script structures have been constructed before and verification times tested on different types of machines, but the exact structure of those scripts has not been publicly revealed by the developers who did so for obvious reasons. These are transactions that could literally stall the entire network.
A last example of DoS protection would be the dust limit. Transactions creating UTXOs with a satoshi value below the dust limit are not relayed because the fee to spend that UTXO would be higher than the satoshi value of the output. This makes it uneconomical and unlikely that it would ever be spent, meaning that the UTXO set would have to store these outputs forever. This could create a bloating UTXO set that makes block validation more computationally intensive.
Future Softforks
All major upgrades to the Bitcoin protocol have been done with softforks, an upgrade mechanism that allows new script functionality to be added to the protocol in a way that un-upgraded nodes will still accept as valid.
This is possible because Bitcoin script includes “undefined” opcodes, meaning that any use of them automatically is considered valid because no verification rules are currently defined for them. When people upgrade their nodes to enforce the new rules, upgraded nodes will apply the new rules against that opcode, and older ones will simply accept any use of them. As long as miners do not mine transactions violating the new rules before the network of nodes all upgrade, everyone stays on the same blockchain and everything is backwards compatible.
Transactions using these undefined opcodes are filtered by relay policy. This is done in order to preserve the upgradeability of the Bitcoin protocol in the future.
If users were to make UTXOs using such undefined opcodes, say in combination with a defined ones so that they weren’t spendable by anyone, if that undefined opcode were given verification rules in a softfork that UTXO would become unspendable. The structure of the script would not be able to meet the new verification rules applied during the softfork.
Allowing these to propagate and be confirmed could allow UTXOs using undefined opcodes to turn any potential softfork upgrade in the future into a philosophical dilemma of not upgrading or rendering some user’s coins unspendable.
Discouragement
There are some types of transactions that while causing no actual harm to nodes on the network, i.e. crashing nodes, using excessive memory or resources, a large segment of network users find undesirable or contrary to the primary purpose of Bitcoin.
Examples of such transactions would be those making use of large OP_RETURN outputs, or Inscriptions making use of the Witness field, to write arbitrary information to the blockchain. These are discouraged because they are not seen as a primary use case of the Bitcoin network.
Not Everything Is The Same
These different classes of filters in relay policy are very clearly distinctly different things. Not all relay filters exist for the same reason, not all of them involve the same incentives for miners to mine (or not mine) them. Each of them exists for a specific purpose to protect your node, or the blockchain, from different types of things that are either legitimately damaging or just undesirable.
All filters are not the same, and the difference between the things they are filtering is massive. Everything from problematic transactions that could crash the network (which should be fixed at the consensus level), to just discouraging harmless transactions that people find undesirable.
It’s important to realize the difference between these things. For instance, a miner might mine a simply undesirable transaction if a user pays for it, but no rational miner would construct and mine a block full of transactions that would crash the entire network. That would undermine their investment.
Everyone who has used bitcoin has made use of the mempool, or a mempool. So what is the mempool?
Well technically, there is no such thing as “the” mempool. Every individual full Bitcoin node operates its own mempool, a cache of valid bitcoin transactions that have been broadcast to the network but have yet to be confirmed in a block. Nodes exchange messages with each other to see what transactions they have or not, and exchange ones they don’t have.
Each mempool is its own independent island essentially, with its own set of unconfirmed transactions, and sometimes its own configuration variables and settings. There is a size value to configure, set to 300 MB by default. In addition to this there is a minimum feerate that dynamically adjusts itself, and can have a configured value. This is used to decide which transactions to kick out of your mempool when it gets full and more transactions keep coming. There are a few other configurable options, such as the datacarrier and datacarriersize options affecting transactions containing OP_RETURN outputs.
Different nodes have different reasons for running a mempool, and therefore different needs, but it is ultimately through everyone in synchrony running their own mempools interacting with each other that those individual needs are met.
Think of each mempool as a literal pool, all connected to each other by channels in the ground. The larger a mempool is the deeper the pool in the ground is. Miners, exchanges, block explorers, these are all going to be the deepest pools. They all have different reasons motivating them to want to know of every unconfirmed transaction that is waiting to get into a block. Miners, to be sure they have the most profitable transactions for their next block. Exchanges, to be sure they are aware of all pending transactions. Block explorers, because their entire service is displaying as complete a dataset about the blockchain and mempool as possible. Your average nodes only really need to be deep enough to contain the top feerate slice of the “mempool.”
Now think of each transaction as a drop of liquid, the higher the feerate, the denser the drop of liquid. These drops flow in the channels between the pools, and upon arriving at each pool, a drop received is duplicated and then sent on through the channels to any other pool that hasn’t gotten that drop already. As pools fill up, upon overflowing the less dense liquids (lower feerates) will spill over the edge and out of the pool first.
Eventually some lucky miner gets to scoop a size-restricted amount of liquid out of the bottom of its pool, and dump that into the newest glass tank in a long, snaking line of glass tanks being filled with liquid to sit there forever (the blockchain). This is just a way to think about the system intuitively and encompass most of its dynamics.
This arrangement of pools interlinking serves different purposes for different users.
Transactors
Users making transactions have two uses for the mempool. First and foremost, is to get their transactions to the miners. If they don’t get to a miner’s mempool, then there is no possible way for them to wind up in a block. Mempools interlinking and sharing transactions with each other guarantees that eventually, once a transaction is put into one mempool, it will wind up in the mempools of all of the miners. Having a robust and decentralized network to guarantee that transactions will eventually get from a user to all the miners regardless of changing and fragmented connections on the network is a valuable thing.
The second use is fee estimation, which is especially important for Layer 2 users who could at any time have to ensure a response transaction to an invalid state is confirmed in a timely manner. It is possible to get some degree of fee estimation by just looking at the feerate of transactions in those blocks, but that does not tell you anything about the current state of the mempool after the most recent block. It doesn’t account for sudden spikes, opportunistic actors flooding the mempool, or the next wave of a growing transaction spike that hasn’t finished yet. Without a view of the mempool, fee estimation cannot be sure it is taking into account the current state of pending transactions.
Receivers
When you receive bitcoin, your node verifies that transaction as well as the entire block containing it. The transaction paying you is broadcast, winds up in a miner’s mempool, they find a block, that block is broadcast to the network, and then your node downloads and verifies it.
Except that’s not how that actually works (unless you disable your node’s mempool and run in blocksonly mode). Your node validates each transaction when it is first received in its mempool and caches that as a valid bitcoin transaction. When a miner finds a block, they actually only relay the blockheader and a small piece of compressed information, for lack of a better simple explanation, that can be used to figure out which transactions are in a block. Your node then grabs the pre-validated transactions, verifies the header, and if it all passes, forwards the “compact block” onward.
This optimization is actually why miners no longer depend on centralized and permissioned relay networks like FIBRE, formerly maintained by Matt Corrallo, and the short-lived Falcon Network, which used to be necessary for miners to connect to in order to guarantee low block relay latency to other miners due to the poor relay speed across the peer-to-peer network.
Miners
Miners obviously want to see everything. They are profit-driven entities that want to be able to select from the largest set of pending transactions possible the ones that include the highest paying fee. This is how they maximize profit and earn revenue to continue expanding their operation and remain competitive.
They literally get money out of the mempool. Their incentive to acquire any valid fee-paying transaction is so strong that they have, historically, presently, and almost certainly in the future, built numerous systems, and even informal arrangements available socially, designed to allow users to directly submit transactions to the miners rather than through the open peer-to-peer network.
Block Explorers, Chain Analytics, Etc.
They, like miners, want to see every pending transaction that has been created and broadcast to the world. The major difference between the groups is miners directly monetize these transactions collecting fees, blockchain explorers and analytics companies indirectly monetize those transactions by displaying, analyzing, and providing that analysis of the information in a product that is monetized.
I can’t point to any concrete examples involving cached mempool data, but chain analytics companies have been known to regularly buy privately acquired metadata regarding transaction activity on-chain. They have also been known to operate sybil Bitcoin nodes that peer as widely as possible with nodes across the entire network to be able to narrow down which set of nodes originally broadcast a transaction.
Block explorers as well monetize visual displays of blockchain and mempool data, their entire business model is focused around that. Access to more data to display to their users is more information to potentially monetize if useful or novel ways to display that information or information derived from it.
Information Wants To Flow
All of these different classes of users benefit from there being “a” public mempool because of one simple dynamic: information flows freely across them. As long as there is a sufficient fee to get past minimum relay filters, it is consensus valid, and does not present a legitimate denial of service or resource exhaustion risk to individual nodes, it provides value for every class of user in propagating across each individual mempool in the network.
Without a functional public mempool, the only viable alternatives to all of these different uses for individual users is centralized solutions or an unmanageable chaos of slapdash and disorganized attempts at fragmented public mempools that each user will need to individually track.
That not only introduces the potential for manipulation of feerate data, deceiving users, and Miner Extractable Value concerns caused by private relaying of transactions. Without a healthy and open public mempool, these are the types of issues that Bitcoin will have to confront.
In a follow-up article I’ll be looking at these issues, as well as different types of mempool filters and why they exist.
While at the MIT Bitcoin Expo last month I was able to sit down with Bitcoin Core developer Sjors Provoost.
Sjors is a physicist turned Bitcoin developer, which believe it or not is actually a pretty common phenomenon. He began contributing to Bitcoin Core in 2017, a very turbulent time during which the activation of Segregated Witness was playing out in the culmination of the block size wars with the User Activated Softfork and the New York Agreement.
He is also the co-host of Bitcoin, Explained, a podcast done with Aaron van Wirdum, the current Editor in Chief of Bitcoin Magazine. Most recently he has also written the book Bitcoin: A Work In Progress, explaining technical aspects of Bitcoin. Each chapter pairs with an episode of the podcast.
We talked about the Bitcoin Core project itself. How it’s organized, what it’s like to work on, and some of the challenges that can pop up for those who take the leap into contributing directly to the Bitcoin Core itself.
FreshRSS 
