
What are the chances?! (source)
Introduction
Having dedicated the last decade of this blog to exploring Bitcoin’s store of value properties and journaling its monetisation phase from under $200 to $100,000, we are now reaching the scale where its medium of exchange and unit of account properties are being designed and built out to facilitate the peer to peer economy, and a closed loop ecosystem where fiat money and national currencies will be surplus to requirements.
This post will discuss the historical and definite constraints of Bitcoin’s throughput, driving the fractious Fork Wars of 2015-2017 leading to SegWit and the first major base layer blockweight and scripting upgrade, to the un-controversial and major Taproot upgrade of 2021, to developments since and the increasing noise and debate over the next major upgrade in Bitcoin’s scripting capabilities, from new covenant op-codes to the Great Script Restoration.
Base layer upgrades and UTXO introspection/sharing will then inform and dictate the development and capabilities in scaling Bitcoin’s burgeoning medium of exchange and unit of account second layer, exploring lightning, sidechains, statechains, joinpools, e-cash and NOSTR, and the security tradeoffs between custody and self custody for off chain anonymity.
We are scaling!
Bitcoin Feudalism
“In a recent post I think I condensed it rather well in saying that a contentious Bitcoin hard fork would be nigh on impossible because of its governance structure (most recently demonstrated with the collapse of SegWit2X), while Ethereum hard forked (The DAO) at the first sign of trouble because of its governance structure, so blockchain development not only lies in code and the underlying protocol but also in governance structures. What Satoshi purposefully did in my opinion was to remove himself from the Bitcoin project and so add another layer of security and immutability to its governance, for the one lesson of history is this, centralised top down rule and absolutism ends in corruption, delusions of grandeur and megelomania. By removing himself as ultimate decision maker and creative vision and disappearing virtually without trace he removed a key security flaw, from the CIA, the CFTC, SEC, and from lobbyists and manipulators that advise Kings on expanding Empires. As a leaderless community with rival and competing factions or fiefdoms reminiscent of European medieval feudalism, any decision that requires either a soft or hard fork within Bitcoin is rigorously debated as we have seen most recently with the fight for SegWit that took nearly two years, in maintaining Bitcoin’s conservative roots and building for the future.” – Ethereum – The DAO, ICO’s And Redefining Law, Annrhefn, January 6th 2018
An old quote that highlights the unique nature of Bitcoin development compared to every altcoin that has followed since, and Anarcho-Feudalism as compared to Absolutist Monarchism. The trade-offs of social governance systems!
The Fork Wars of 2015-2017
The first major scaling war in Bitcoin history was a rolling battle between big blockers who argued that Bitcoin needed to increase its blocksize to include more transactions and throughput linearly on chain, and small blockers who argued for optimising the base chain to scale off chain layers in order to maintain decentralisation and costs of running individual full nodes.
The first fork war shots were fired by developer Mike Hearn with Bitcoin XT (BIP64) in late 2014 gaining attention in mid 2015 amid contentious debate among developers, and would eventually lead Hearn to (rage) quit the project in January 2016.
In June 2015 original Satoshi disciple Gavin Andresen published BIP 101 calling for an increase in the maximum blocksize, and in August was merged into XT, before reverting to a 2-MB block size bump in Bitcoin Classic.
The third rebranding prior to the SegWit upgrade was Bitcoin Unlimited from November 2016, that would eventually become the Bitcoin Cash hard-fork from August 1st 2017.
In contrast, the so-called small blockers and the majority of Bitcoin’s early developers favoured base layer optimisations, coalescing around a soft-fork upgrade known as Segregated Witness.
Bitcoin Scaling Debate – Game Theory And The Scaling Of Solutions

“According to this website, Bitcoin Unlimited is leading the miners support with 34.6% with SegWit garnering 29.9%, so things are pretty close overall, with 60-70% of mining power needed to activate BU (apparently) and 95% required to activate Segwit, it would seem that Bitcoin’s mining community holds the future and fate of Bitcoin in its hands.” – 9th April 2017
The most contentious Bitcoin soft-fork in history played out during 2017, and this post was about setting out the history and the counter-proposals during that consequential year, with a definitive bias toward Segregated Witness as the preferred scaling solution that would also become consensus among network nodes, despite perceived miner power over the network. So what did SegWit offer us that Bitcoin Unlimited did not?
“SegWit is the Bitcoin Core development team’s proposed scaling solution by systemic on chain tweak and for paving the road for further off chain scaling solutions, and this would be activated by a soft fork and therefore backwards compatible and would basically be a standard Core upgrade, and although not completely without risk has some very interesting effects and certainly increases the flexibility of what can be done with the solidifying and ossifying Bitcoin protocol in general. For a brief and very potted version of Segwit, it involves the identifying and segregating of the Block signatures (that sign the transaction) that can take up to about seventy five percent of a block’s capacity, and therefore in of itself this is a big upgrade for the block size in effect while not actually increasing the block size to do it, which is pretty neat… Segregating the witness (signature) was initially developed by core developer Pieter Wuille as a fix for transaction malleability which has been somewhat of an achilles’ heel for Bitcoin in the past that allowed spamming and jamming the network, denial of service attacks, and had been blamed (or scapegoated depending on your view) for hacking and loss of funds at Bitcoin exchanges (Mt Gox being the most famous example), in short transaction malleability is a pain in the arse and weakens the security of Bitcoin in general, so it will be a substantial upgrade to core operability… In the past it has been assumed that SegWit would have to be implemented by hard fork however by upgrading version scripts (another tweak developed by core contributor Luke Dash Jr) it can be activated by soft fork and would allow the far easier and more flexible soft forking of the protocol going forward, so this upgrade allows a lot more to be done within the intrinsic limitations of Bitcoin… This more flexible protocol allows numerous further improvements such as security, privacy and anonymizing features that we will increasingly require going forward as Bitcoin and its users will be subject to surveillance, censorship attempts and crackdowns by the dying and dangerous insolvent state and banking apparatus worldwide… But perhaps the most important aspect of SegWit is that it significanly enables off chain scaling layers that can scale near zero cost transactions through projects such as the Lightning Network and sure to be many others, that will allow Bitcoin to leave Act I (currency speculation) and transition into Act II (barter ledger) and scale small, micro, and every day transactions – 9th April 2017
BIP 148 UASF Game Theory: Why SegWit Activates Before August 1st By Miner Activated Soft Fork (MASF)

My BIP 148 Game Theory post published in June 2017
“SegWit will activate before August 1st and we will at last have a substantial scaling solution and a much needed fix for transaction malleability also removing the transaction signatures from the block that will give roughly a fourfold increase in block capacity for the network’s surging transactions while reducing fees, and will also significantly enhance off scale micropayment layers that can scale Bitcoin as a low cost medium of exchange which increases Bitcoin’s market cap and value, and mining revenues. All of the hard fork embrace of Bitcoin Unlimited and the stalling of SegWit by the miners is pure bluster and exertion of leverage and milking of transaction fees of what until recently had been a lean few years for the Bitcoin mining community. As game theory predicts a Miner Activated Soft Fork the history and tradition of Bitcoin’s governance is maintained, the Miners denying the User Activated Soft Fork that would set a precedent of ignoring Bitcoin mining on future protocol upgrades, and I just cannot see the miners letting this happen. To use a poker analogy BIP148 is going all in on the hand therefore forcing the miners to either reveal their hand or fold, and folding on this hand is far more prudent for Bitcoin’s intrinsically conservative mining community than the risk of losing all your chips and the game in the event of a contentious hard fork.” – 11th June 2017
The BIP148 post was written two months following the scaling post, with updates on miner and developer sentiment and bluster as the fork war reached its climax. Really takes me back down memory lane!
SegWit Activates By MASF – How UASF Libertarians Won Bitcoin’s Scaling War

Remember when Game of Thrones was in vogue?!
“In my BIP 148 UASF Game Theory post (published June 11th) I predicted that SegWit would activate before August 1st by Miner Activated Soft Fork at a time when things were maybe looking in doubt, with a rising minority of users going UASF full retard but also the mining community maintaining the poker face with threats of all sorts regarding the stalling in activating Segwit, however it has turned out in posterity to be the miners that were really bluffing and exactly as I predicted using simple logical deduction. The only thing I couldn’t foresee at that time was how the mining community would attempt to save face and not make it so blatant who had really capitulated in the Mexican Standoff or how fast they would capitulate, but on June 20th we got both answers when miners agreed overwhelmingly to support the Bitcoin Roundtable or the so-called New York Agreement (May 24th) as a way for miners to signal for a SegWit soft fork, contingent on the further doubling of the blocksize in time to 2 mega bytes, or in short SegWit2x. By a roundabout and convoluted way the miners first signalled for BIP 91 for SegWit on 17th July and by the following week (24th July) we had 100% consensus for the activation of SegWit by BIP141 and thus critically importantly cancelling the BIP 148 UASF being enforced by user nodes. SegWit locked in activation on the 8th August, and we are currently in the two week “grace period” and SegWit should finally be enshrined around August 22nd 2017.” – August 17, 2017
The August post recapped all the madness of the previous year, and took some words to gloat and celebrate over the biggest scaling upgrade in Bitcoin’s eight year history, with a blockweight capacity increase alongside the transaction malleability fix that allowed the effective birth of the Lightning Network and Layer Two. It also fundamentally changed the balance of power away from the miners and toward the user and developer factions, diminishing miner leverage in future soft forks.
Lastly SegWit addresses were introduced allowing the generation of bech32 native (either P2WPKH or P2WSH) segwit receiving and sending addresses.
The Taproot (BIP341) Soft Fork Upgrade

The second major scaling upgrade to Bitcoin was so uncontroversial and uneventful that I didn’t even bother writing a blog post about it, and is trapped within the totalitarian fog of the Covid Scamdemic when the global public sector lost their minds over the flu, subjecting its citizens to lockdowns, vaccines, mental illness and death. Having been through the arduous fork war of 2017 inflicting PTSD upon many in the developer and user community, and with the big blockers having forked off Bitcoin Cash into obscurity, there seemed to be little controversy or fight against a Taproot soft fork.
Taproot was developed to expand upon SegWit capability and first submitted by Greg Maxwell in 2018, codified in three BIPs with the objective of making Bitcoin faster, more efficient and private, allowing multiple signatures and transactions to be batched together, verifying transactions on Bitcoin’s network faster and more straightforward:
BIP 340 – Replacing ECDSA with Schnorr and a superior digital signature scheme that is faster, more secure and less data-intensive.
Bip 341 – Taproot offers a new way to perform Bitcoin transactions by enhancing privacy and flexibility for users. It also activates Merklized Alternative Script Trees (MAST), which condense complex Bitcoin transactions into a single hash, reducing transaction fees, minimizing memory usage and improving Bitcoin’s scalability.
BIP 342 – Tapscript is the scripting language used for taproot script-path spends
On June 12, 2021, Bitcoin miners signaled their support for the upgrade with a 90% consensus, and the Taproot upgrade date was finalised in November 2021 and fully activated as a soft fork of the protocol at block 709,632 on Nov. 14, 2021. The six months between the lock-in and the activation were programmed to allow node operators and miners to fully upgrade to the latest Bitcoin Core version.
Taproot addresses also introduced P2TR (pay-to-taproot).
The Next Scaling Upgrade – Script

The next expected soft-fork upgrade that has been bubbling since soon after Taproot activation is enhancing bitcoin’s scripting language capabilies, and on the face of things is a far more limited upgrade than either SegWit or Taproot. It should in theory be a far less contentious discussion than either of the previous upgrades, and yet the last three year consultation process among developers has seen little consensus, with the devs and influencoors advocating for a script upgrade becoming increasingly frustrated by devs and influencoors not caring or not wanting the scripting upgrade. So what are the main points of contention?
The first and main contention is that this is a soft-fork and thus a potential risk to disrupt or even destroy an accounting network that is now truly global, with hundreds of millions of owners and thousands of developers and businesses dependent upon Bitcoin as their hedging ledger against the destruction of fiat currencies and national governments over the next two decades. When looking at things through this lens, and with Bitcoin likely to at least double again in the last mania bull market year of Bitcoin’s four year cycle 🟢🟢🟢🔴, we are moving toward a $5 TRILLION network that just increases the stakes of any new upgrade, and winding on to future cycles when Bitcoin moves into the tens of trillions, the stakes will be even higher! Based upon this, Bitcoin is likely to ossify as a protocol and this scripting soft-fork may be the last we get before Bitcoin becomes too big to change.
The second contention is the evolution of Bitcoin development. Since the disappearance of Satoshi, development had been down to a small band of enthusiasts and hobbyists, with a handful of devs tinkering and maintaining as well as possible. While the growth of the big blocker and small blocker factions was well established by 2015 we were still only talking in the tens of developers, and a few of them had quit and/or forked off by the end of 2017. Expunged of the big blockers, SegWit was the brainchild of Pieter Wuille, and Taproot was proposed in 2017 by Greg Maxwell with the BIPs authored by A.J.Towns, Tim Ruffing and Pieter Wuille. These two major soft-fork upgrades were proposed and activated when Bitcoin developers were still largely hobbyists and amateurs, but inevitably with the growth of Bitcoin would come the growth of new developers and professionalism, i.e a full time career with monetary remuneration. With developer support hubs such as MIT DCI, Chaincode Labs (established 2014) and Brink (established 2020), funding hubs such as H.R.F (Human Rights Foundation Bitcoin Fund, 2020) and Open Sats (2021), direct developer funding by exchanges such as BitMEX (from 2019) and OKCoin (from 2019), and Bitcoin corporations in Blockstream (founded by Bitcoin devs in 2014) and Square (from 2020), the money has flowed into Bitcoin development and developers especially since Taproot activation, as should be expected as the monetary value of the network grows and privatises/organises. This in turn fueled the conspiracy theories amongst newer developers over OG developer money pushing Bitcoin in certain directions, that is in my opinion inevitable as any organism evolves from amateur to professional (see my post on the History of Money and Sport). Furthermore, the recently resolved clusterfuck of Craig Satoshi Wright’s Tulip Trading Lawsuits (financed by early Bitcoin ₿illionaire Calvin Ayre’s ridonculously deep pockets and enabled by Gavin Andresen’s gullibility or final revenge in his blog on 2nd of May 2016), filed with the UK’s High Court from April 2021 against 16 Bitcoin developers, leading to the official “withdrawal” of OG Core devs and maintainers including John Newbery, Samuel Dobson, Jonas Schnelli, Peter Wuille and Wladimir J. van der Laan. CSW’s hounding of Core devs would continue until Jack Dorsey funded the COPA (Crypto Open Patent Alliance) Lawsuit to definitively prove that Wright was not Satoshi thus neutering his lawfare bullshit, which in March 2024 Justice James Mellor ruled in favour of at the UK’s highest court. CSW has since continued to sue Bitcoin devs bringing him in contempt of court, and saddling him with a one year suspended sentence should he attempt this again. It therefore seems like the three year crusade againt core Bitcoin devs is now at an end and they can breathe a sigh of relief, however the damage it has created is under appreciated, and has contributed heavily to the perceived lack of leadership within Core on further protocol upgrades, and to the growing frustration from newer devs seeking the blessing of older devs in order to move the project on further.
The third contention is the tangled history of the attempted activation of CTV in the past. Jeremy Rubin, a longtime but “non-core” developer had been exploring the idea of covenants for years, and first introduced BIP119 for CTV (OP_CHECKTEMPLATEVERIFY) in January 2020. In the wake of Taproot Activation in November 2021 and having garnered what he believed was some level of developer consensus at a few Bitcoin dev conventions, Rubin proposed activating CTV via the same Speedy Trial (BIP8 and 9) activation method used for Taproot by giving the miners a timeframe to signal their support, in April 2022. Controversy inevitably exploded among developers on this method with the predictable “insufficient consensus” and “trying to attack” Bitcoin angles, shooting down CTV and Rubin in flames with the activation attempt called off in May 2022. Despite continuing consensus building attempts around CTV and other “covenant-like” op-codes, the residual stigma has been harmful to progress and hardened some so-called “ossifier” factions against covenants and other op-codes (particularly OP_CAT), more on that later.
The above gives some background and context to the last three years in Bitcoin development since Taproot activation, to provide an appreciation of the politics, funding model, and legal attacks on an increasing professionalised and politicised developer community as this project grows.
The Rationale For Op-Codes – Back to Bitcoin’s Block Size “Problem”
Having dispensed with Politics for the time being, we can get to the economics of Bitcoin, and of scarcity. All the genius and flaws of Bitcoin originate from its design, that a digital accounting standard and value network can be verified by anyone independently of a counter-party (outside of Bitcoin Core *wink*), by downloading the Bitcoin protocol software and running it on one’s own node aka computer. The trade off for self custody is having to download and sync the blockchain from genesis, which is now sixteen years ago, and the resource and bandwidth demands for running Bitcoin nodes will be forever increasing, despite being offset by lower resource and bandwidth costs of advancing technology.

There are just over 20,000 individuals running Bitcoin nodes according to coin.dance stats (source)
To regulate the amount of data Bitcoin generates and to ensure that data storage costs do not destroy Bitcoin’s self custody model, also creating a de-facto anti-spam mechanism and a competitive fee market for transactions, Satoshi introduced the 1 megabyte (MB) block size limit in Bitcoin with a commit on July 15, 2010. A two year war then ensued between 2015 and 2017 as already discussed over Satoshi’s arbitrary 1 MB block size, which was upgraded to 4 MB by blockweight for SegWit transactions, but is still a cap upon Bitcoin’s transaction throughput. At the heart of all Bitcoin scaling debates is therefore the trade-offs between increasing transaction throughput (flow) at the expense of increasing node resources (stock), at the intersection of both is the self custody model.

Bitcoin node count from 2015 to 2024 (source)
The only solutions left to increase the capacity of Bitcoin’s self custody model (and maintain decentralisation) therefore is either a blocksize increase or find another way of scaling without a blocksize increase, and considering the past pushback against blocksize increases I imagine it would be even more difficult to find consensus today. Indeed there are devs who argue for a blocksize reduction to slow down the growth of the blockchain at the expense of reducing throughput and increasing fees, pricing out some self custodial use cases to the benefit of custodial services and counter-party storage. In the unlikely event of a blocksize increase where for argument sake the block size increased to 2 MB, throughput would linearly double but so would the chainstate growth rate.

It takes over 600 gigabytes and counting of data to run a full node at present, but it is obviously a computing cost that is willingly being paid by an increasing number of users (source)
There are possible long term solutions to Bitcoin node running being worked on currently such as MIT DCI backed utreexo, and Libbitcoin projects, to make running a node easier, faster and smaller by redistributing storage and memory costs from past transactions (stock) to current state (flow) reducing Initial Block Download (IBD) by adding current bandwidth demands. However this does not alter the current blocksize throughput limitation of 1 MB or its increase in the near future, which also brings us to the critical discussion of what constitutes Bitcoin’s blockchain model, that of the UTXO set.
Bitcoin’s UTXO Model

Bitcoin’s UTXO Model: What Is It and How To Manage UTXOs (source)
As scaling pressures show up in fee markets, it has behooved exchanges such as River to publish research pieces on Bitcoin’s accounting model, that of the UTXO (Unspent Transaction Output). Indeed the Ordinals craze that gummed up the mempool in late 2023 taught self custodial users and sat stackers a valuable lesson on Bitcoin resource economics. An UTXO represents an amount of bitcoin that has been sent to an address but has not yet been spent. When you receive bitcoin, it comes as one or more UTXO’s. Each transaction in Bitcoin involves inputs (UTXO’s that are being spent) and outputs (new UTXO’s that are created from the transaction). The sum of all UTXO’s associated with an addresses constitutes the wallet balance.
The intrinsic scarcity of UTXO’s are yet another example of Bitcoin’s trade-off structure, in that the more UTXO’s one keeps the higher resource costs to the individual and the network and the higher the transaction fees when spending or consolidating more UTXO’s into less, at the expense of hurting privacy as UTXO consolidation melds transaction history of hitherto unconnected and disparate UTXO’s. Therefore, the more UTXO’s an user keeps the greater his privacy and fees to transact, and the less the UTXO’s the lower his cost to transact and the lower his privacy. Scaling up every self custodial member of Bitcoin adds up to the UTXO Set.
The UTXO Set – Self Custodial Scaling Limits

Bitcoin UTXO Set data courtesy of Glassnode. The total number of UTXO’s in the network (blue), and the disconnection from UTXO’s created (green) and spent (red), ramp up from April 2023 with the launch of Ordinals (source)
“The payment network Visa achieved 47,000 peak transactions per second (tps) on its network during the 2013 holidays[2], and currently averages hundreds of millions per day. Currently, Bitcoin supports less than 7 transactions per second with a 1 megabyte block limit. If we use an average of 300bytes per bitcoin transaction and assumed unlimited block sizes, an equivalent capacity to peak Visa transaction volume of 47,000/tps would be nearly 8 gigabytes per Bitcoin block, every ten minutes on average. Continuously, that would be over 400 terabytes of data per year.” – The Bitcoin Lightning Network Whitepaper, 2016
The above quote is included to highlight Bitcoin’s throughput limitations that were abundantly clear to Layer Two developers back in 2016, despite the fact that it is possible to transform an on-chain UTXO into a theoretically unlimited number of off-chain transactions by leveraging the most primitive form of “covenants” developed as part of the SegWit script upgrade in Timelocks, namely OP_CheckLockTimeVerify (BIP 65) and OP_CheckSequenceVerify (BIP 112), allowing temporal promissory or smart contracts (based in time) on the underlying network, enabling HashLockTimeContracts (HTLC’s – BIP 199) and the birth of the Lightning Network and the bridge between L1 and L2.
What hash lock time contracts has enabled is for self custodial users to transform a single UTXO into a medium of exchange and unit of account off chain, in effect weaponising the throughput of that UTXO. For example, imagine converting a 1,000,000 sat UTXO into lightning for an LTXO costing one base chain transaction, that could then be used to carry out one hundred off chain transactions buying and selling with other lightning merchants. Once satisfied in your business dealings, you decide to exit the lightning network back on to the base chain at the cost of another UTXO updating the balance account of your off chain dealings. While Bitcoin’s base layer has only cost you two transactions (and fee), you have carried out 102 transactions overall and a hundred of them more privately with near instant settlement and virtually zero transaction fees. Lightning network has revolutionised the throughput capability of a single UTXO and user, and a huge scaling improvement potential for self custodial Bitcoin peer to peer value transactions in the future, and the gift that SegWit gave us in 2017.
The limitations of Lightning is therefore base layer UTXO’s and its throughput further constricted by Bitcoin’s blocksize, which makes Lightning a hostage to the base layer. Bringing us to Bitcoin script upgrades, op-codes, covenants, and the concept of UTXO sharing.

UTXO Sharing – Concept
The concept of UTXO sharing is that multiple users could self custodially own a share of an UTXO. To take the example above, instead of a lightning node allowing the scaling of an UTXO to a 102 transactions, imagine if that lightning node scaling one hundred owners within a single UTXO, and then continue creating off chain transactions. As lightning increases the throughput of a single UTXO a hundred times, then UTXO sharing can scale to a hundred users, each carrying out 100 off chain transactions could scale a single UTXO to 10,000 transactions. This would be a further 100 x scaling of a single UTXO, and therefore allows more self custodial users to use Bitcoin without any increases in on chain throughput.
The requirements for this scaling method would include multi-signature transactions requiring consensus among users to move funds, covenants whereby certain conditions can be programmed to spend transactions allowing shared control of an UTXO, and could also be utilised by off chain layers such as sidechains, statechains, joinpools and e-cash as will be discussed later on.
UTXO sharing can also have real world use case in DeFi for pooled investments or shared wallets, can be used for privacy and security via off chain obfuscation.
Op-Codes
“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.” – Satoshi, June 17 2010.
The only real option left on the table to optimise Bitcoin further is via its scripting language which Satoshi created as part of Bitcoin, and is a language that allows Bitcoin to use a set of operation codes to define the conditions under which a transaction can be spent. These op-codes are part of the Bitcoin Script language, which is stack-based and allows for the creation of complex transaction conditions.
The Great Script Restoration
I will begin the candidates for op-code proposals with the least developed but has come to prominence in the last year, with Blockstream and predominantly Lightning developer Rusty Russell. In the C++ developer meet up in Austin Texas at the beginning of May 2024, Russell gave a 42 minute presentation on a proposal titled, The Great Script Restoration.
The proposal is interesting just because it harks back to the early history of Bitcoin, and Satoshi’n inclusion of a number of op-codes (operation codes) enhancing the scripting language and the programmability of bitcoin transactions. However, in 2010 bowing to security concerns such as potential denial-of-service attacks and exponential memory growth, many op-codes were disabled by Satoshi significantly limiting Bitcoin’s scripting capabilities, reducing its potential for smart contracts and other advanced uses.
The op-codes removed were:
OP_CAT: Allowing the concatenation of two elements on the stack, potentially leading to exponential growth of stack elements if combined with other opcodes like OP_DUP.
OP_SUBSTR: Used for extracting a substring from a byte sequence, which could cause similar issues with memory usage.
OP_LEFT: This opcode would remove all but the left n bytes from a string.
OP_RIGHT: This would remove all but the right n bytes from a string.
OP_INVERT: Inverted all the bits of the input, which could lead to performance issues if used in loops.
OP_AND, OP_OR, and OP_XOR: These bitwise operations could also be problematic in terms of memory and computational resource consumption.
OP_MUL (multiply) and OP_DIV (divide): Arithmetic operations that could lead to issues like overflow or excessive computation.
OP_MOD: Modulo operation, which could also lead to excessive computational demands in certain scripts.
While it is understandable why Satoshi disabled programability to protect Bitcoin in its early days, fifteen years later there is the case to be made for re-enabling some or all these op-codes with a restoration of script capabilities, aka the Great Script Restoration. The proposal also includes possible stack limits on computation byte costs to solve the problems of memory, while mimicking the sigops (signature operations) budget introduced by the Taproot upgrade in 2021, with the introduction of a hashing budget optimised to a varops (variable operations) cost model to control or limit CPU usage. This is a complicated explanation of what is a basically simple concept, that of restoring most if not all of Bitcoin’s scripting capabilities, and the refining of computational cost with budgets, to minimise potential denial of service attacks (spam) that was the main reason Satoshi disabled them in the first place.
The current status of the Great Script Restoration is formulative, but has been disseminated widely in Bitcoin development circles via presentations at developer conferences (as above), articles, podcasts and discussion forums. However, no significant changes have been implemented yet due to the careful evaluation needed for any protocol upgrade, and the BIP is still in draft stage and not been formally submitted to the Bitcoin community for consensus. It is therefore likely that GSR will not be a strong contender for near future soft-fork upgrades, but in my opinion is a strong contender for a long term soft fork upgrade possibly in conjunction with the Great Consensus Cleanup that will sooner or later be required in Bitcoin.

Rusty’s own thoughts on op-code roadmap (source)
New Op-Codes and Covenants/Introspection
Having dealt with the restoration of existing op-codes, we come to the proposals and jockeying for position in the next soft-fork upgrade by new op-codes. There are numerous op-codes under consideration, that individually or in combination can unlock different use cases for optimisations to Bitcoin, and by extension Layer Two.
Here I will defer to veteran developer Jamesob, and while he has his own biases like every other developer and this repost does not mean I agree with everything or anything in the post, it is presented as a great write up on the comparative advantages and disadvantages of the competing op-codes:
“COVENANTS BEAUTY-CONTEST RATIONALE –
Prelude
Soft forks tighten the rule set of what transactions are valid. Additional opcodes allow existing owners of coins to put additional constraints on how those coins are spent. Many covenant-enabling opcodes are nothing more than “new”, more specific sighashes[^0]. Other opcodes allow access to information about a spending transaction. None of this is conceptually objectionable. People should be able to put constraints on their property. But first we must do no harm. The concrete issues when gauging additional script functionality are: – “externality” risk – is enforcing this new rule going to make bitcoin somehow exploitable? – “code carry” risk – once a rule is added to bitcoin, it must be enforced forever, or else a hardfork takes place. Is the code going to pose some kind of awful maintenance burden? These two risks are, for all outstanding covenant proposals, essentially implementation risks (aside from maybe OP_CAT, which I’ll talk about). Because of script size limits and block constraints, many other, more fundamental externality risks of script execution just aren’t an issue in the way that they would be on a less constrained blockchain. All that said…
OP_CHECKTEMPLATEVERIFY (CTV) – In a nutshell, CTV allows you to say “these coins are only spendable by the following set of possible transactions.” It turns out this is really, really useful in a number of different contexts: – Precomputed vaults: to emulate vaults with presigned transactions, custodians must presign vault graphs with ephemeral keys, and then delete the keys. Since you can’t really prove key deletion, auditors hate vaults. CTV removes this need. – Usable-by-individual-people vaults: For “better” vaults that are actually usable by real people, CTV is crucial. From BIP-345: “During the withdrawal process, the proposed final destination for value being withdrawn must be committed to. OP_CTV is the simplest, safest way to commit the spend of some coins to a particular set of outputs. An earlier version of this proposal attempted to use a simpler, but similar method, of locking the spend of coins to a set of outputs, but this method introduced txid malleability.” – Massive DLC optimization (https://x.com/matthewjablack/status/1685005681902977024…) – Applications for timeout trees and second-layer systems like Ark – Non-interactive lightning channel setup – Used with CSFS to allow eltoo (not that I’m sure anyone actually cares) – Congestion control: a speculative but potentially crucial tool for facilitating highly compressed use of chain space to get people “out” of systems if there is correlated failure in a third party custodian, whether that’s a conventional exchange or some kind of programmatic construct like a Lightning channel (remember the 0-days in LND?). – A slightly deeper spectulation is that CC could eventually be used to smooth out the fee market, which may give miners less of an incentive to try reorg battles during times of low fees. But that one is certainly speculative. I could go on, but it should already be apparent that so many uses across such a diverse set of applications attests to the fact that we just keep discovering that this thing is really useful. And it’s simple. And it’s upgradeable. And people have been trying to break it for years, and can’t. This should have been activated a year ago probably.
OP_CHECKSIGFROMSTACK (CSFS) – Bitcoin’s CHECKSIG is basically the core of how most coins are moved. All CSFS does is takes that same signature checking operation, and allows it over an arbitrary message using an arbitrary pubkey. As long as it’s costed properly, it’s basically safe by definition. Elements has had CHECKSIGFROMSTACK deployed since 2017. It’s the kind of op that probably just should have been in bitcoin all along. Uses: – Key delegation: “allow someone to spend this coin if their key is signed by mine” probably has some cool statechain use – Eltoo: along with CTV, CSFS lets you do eltoo – Other uses spelled out at Optech.
OP_PAIRCOMMIT – This is a special form of OP_CAT that is constructed (I think?) solely to enable eltoo. This is emblematic of a certain class of proposals for me: I don’t consider them any kind of technical risk to bitcoin, safe to deploy, low code burden, etc. etc. But they’re just kind of goofy. This feels like a very special-cased opcode that is just trying to skirt ghosts of OP_CAT that I don’t think are actually worth worrying about. I’d be fine if this was in bitcoin, but let’s just get real and do OP_CAT instead.
OP_INTERNALKEY – Another completely inoffensive, three-line opcode that probably should have just come with Taproot. All this thing does is push the Taproot internal key to the stack. It saves many script bytes when we want to make some kind of assertion about the Taproot structure. No downsides. There is an application for this when implementing eltoo (again, if anyone cares) with CTV+CSFS, but I can see how, like CTV, this is a very general, simple tool that will have uses in many disparate applications.
OP_CAT – I hated CAT when its discussion (re)started, and I still hate it in a very real sense, but its time has come. If the window for soft forks is closing, which I think may be the case, OP_CAT is seemingly the ultimate, if not bone-crunchingly stupifying, escape hatch to functionality that we might want to implement down the road but don’t have the specific tools for. OP_CAT enables covenants in the same way that having an arbitrary number of black and white pebbles allows you to build an x86 computer. But some people are okay paying for that, and probably much better to have the option than not. I used to have vague worries about MEV, but some combination of script size limits, the slow 10 minute block time, and the UTXO (vs. account) model really limits the byzantine mischief that ETH people and other assorted cartoon characters can bring to the chain. CAT is a necessary admission that the consensus process is calcifying, and we are in need of a permissionless escape hatch (however stupid) to continue to innovate. It’s also harmless due to script size limits.
OP_CCV – I am very supportive of OP_CHECKCOVENANTVERIFY, especially if it’s a more general mechanism that can absorb OP_VAULT uses but also be useful for other things. The problem is that (i) I don’t fully grok it yet, (ii) many people don’t grok it yet, and (iii) there is work to be done on both the implementation and spec. There is no BIP, nor Core PR patch, although the two are probably within spitting distance. It may well be that OP_VAULT gets folded somehow into OP_CCV as an application, and I’d welcome that. But it remains to be seen.
OP_VAULT – I’ve written at length, and will continue to write, about how important vaults are. My industry experience is intimately linked with this stuff, and I honestly can’t see a user of bitcoin whose experience wouldn’t improve given the presence of something like OP_VAULT. You can get part of the way there with CTV and CAT, but there are crucial usability and efficiency differences that those two simply won’t get you relative to the OP_VAULT construction. These are: – Easy address reuse: CTV, for example, will burn funds if you reuse vault addresses, – Arbitrary partial withdrawals (“revaults”): CTV can’t do this, CAT can _maybe_ do it as long as the math doesn’t require 64 bit, – Batched triggering: an important efficiency gain where many number of vault outputs are spent by the same unvaulting process (CTV can’t do this; CAT can do it within certain amounts and up to say 8 inputs), – No horribly confusing scripts (only mildly confusing scripts) and metadata retention processes To date, the OP_VAULT vault construction is the only vault that I would personally use, although I do think CTV vaults could be useful in an industrial context. I would never recommend CAT vaults for use because the scripts are so inscrutable, but maybe after years and years of cooling period and better tooling, there could emerge a (relatively inefficient) construction that people do feel okay about using. The problem with OP_VAULT right now is that it is a relatively heavyweight change compared to, say, CAT and CTV. I think it’s well specified and well tested, and probably has more review than many of these other proposals. But it still doesn’t feel like it yet has the momentum for immediate activation. Sometimes I feel frustrated that I can see, tangibly, how much better a custody experience this could provide for bitcoin, but not enough people at this point do and that’s life. You can’t push a string.
OP_TXHASH – This is an interesting one. Another category of opcodes is: “in conceptual terms I support having something like this in bitcoin, but the implementation is just too complex and the proposed usecases too unspecified.” Conceptually, you should be able to dictate as granular a sighash as you want in bitcoin. This is basically what TXHASH does. The snag is twofold: 1. this results in a complicated piece of code that has numerous open questions about how necessary it is to cache things to avoid issues like quadratic sighash (https://fjahr.com/posts/how-segwit-solved-the-quadratic-sighash-problem/…), and 2. I haven’t heard a clear articulation of the uses over and above CTV, which TXHASH is basically just a more general version of. If great uses get pitched and people get excited and it really _does_ seem worth the effort to have super flexible sighashing in bitcoin, I’m all for it. But it will take a good amount of work to make sure that code isn’t going to cause problems.
SIGHASH_APO – Basically obviated by better alternatives (CTV+CSFS), but if the question is “nothing vs. APO,” I’ll take APO every time.
Footnotes [^0]: For those who forget, the sighash is just a digest of a spending transaction that is signed by the owner of coins which are proposing to be spent.”
These are the runners and riders currently beind debated by the development community in a continuous and consensus process of obtaining one or more of these op-codes into the next soft fork upgrade. Please note the LNhance proposal will be discussed further in the Lightning Network section.
Coming to “Consensus” – Developer Cat Herding
Returning to politics and the communal struggle session for consensus among developers and influencoors, and factions from outright ossifiers that do not desire any further upgrades to factions that desire every upgrade, to those who would desire any upgrades, and everyone in between. Much of the politics coalesces around the older devs that tend to be more conservative and who have questioned whether Bitcoin script needs the old or new op-codes, to newer devs who tend to be more progressive and push for debate to drive consensus. These factions will necessarily rub up against each other and often rub each other up the wrong way, and there has been a palpable frustration within both camps at the forwardness and backwardness of the other “side”.
In order to try and push the discussion forward and provide a visual guide to consensus on different op-codes, see below the Covenant Support matrix listing developers and their preference or not for each proposal. This matrix is constantly changing with developer sentiment and is therefore subject to revision. The matrix below was last updated on the 25th May 2025.



The matrix developed to gauge consensus among Bitcoin developers (source)
Catalysts For Consensus – Scaling Pains

No Scaling Pains, no Scaling Gains! (source)
The many paradoxes of Bitcoin are driven by the incentive structures around it. All the talk thus far around Bitcoin’s throughput chokepoints, in blockspace, the UTXO set, mempool capacity, and the security budget conundrum, is relatively mute amongst the vast majority of the network and community when transaction fees are low and the chokepoints are untested. Indeed the whole concept of Layer Two solutions is predicated upon the base chain becoming full with a healthy fee market that rewards the miners against the dwindling block subsidy, so when fees are only a few sats per v/Byte then the incentive to consume and create on chain UTXO’s remains attractive, and the utility of Layer Two and increased complexity for decreased security is unattractive. Furthermore, the blockchain conservatives otherwise known as “ossifiers” can point to low competition for transaction fees even in otherwise overflowing mempools, as the reason that Bitcoin does not need covenants, op-codes, introspection or even a Layer Two. Like in human nature and life, we tend to stick to what we know and if it ain’t broke don’t fix it, complacency and recency bias is hardwired into our nature. It can therefore be said that it is only under pressure and when shocks come to disrupt our normative worldview, is when humans and by reflection the Bitcoin network suffers supply and demand shocks, is when minds can be concentrated and the need to seek out and co-ordinate consensus in order to grow.
With this thinking in mind, the Ordinals demand shock of late 2023 is an important case study of the psychological carnage created within Bitcoin, which drove the discussion on covenants and layer two solutions of the last eighteen months.
The Ordinals Debacle – A Spam Attack on Bitcoin?
Bitcoin and “spam attacks” have a colourful history and hark back to at least early 2017, when during the Fork Wars the Bitcoin mempool was flooded from March, fueling conspiracy theories about big blockers (Roger Ver and Jihan Wu cohort) jamming the network, for reasons which would include bouncing small blockers under siege into a blocksize increase, or by the miners to increase fees from competing users in the mempool. Whatever the reason it caused Bitcoin Twitter and users to sperg out as transaction costs and fees shot up to eyebleed levels, and a sense of frustration as the network seemed impotent against its expensive DDOS attackers. Ultimately for the small blockers however all’s well that end’s well, in that SegWit and a block weight increase was achieved, incentivising exchanges and other heavy blockspace users to slowly streamline and manage transactions and blockspace better, and was a learning curve for the whole Bitcoin community, aided by the onset of the bear market in price from late December 2017.
On December 14th 2022, a former Chaincode trained Bitcoin core contributor Casey Rodarmor, created the first-ever Ordinal inscription on the Bitcoin blockchain, leading to his releasing of the Ordinals protocol in January 2023 with the inaugural launch of the Bitcoin Shrooms collection, consisting of 210 pixelated mushrooms. In February, TaprootWizards created the first 4 mega byte inscription utilising the SegWit Discount, and March would see the launch of the BRC20 protocol and the first Bitcoin NFT marketplace,

By June over 11 million Ordinals had been inscribed. The rest of 2023 would see the continued growth and escalation of blockspace demand and transaction fees into year end.



Exasperation with high transaction fees forced me into adopting Liquid and L2 for small purchases. Lesson in there!
The New Year of 2024 brought some respite from the insane fees, if not for the mempool clogged up with dust UTXO’s, and co-inciding with the flatlining of covenants consensus talk and imminent second layer adoption hype.


Despite sporadic and infuriating bursts of fees in early 2024 the worst was over, and with Casey Rodarmor’s release of the Runes protocol co-inciding with the Bitcoin Block Subsidy Halving in late April, a more streamlined protocol for inscriptions has seen muted fees for the second half of 2024.
The inscriptions phenomenon did have some useful lessons in again highlighting Bitcoin’s scaling limits, it drove self custodial users absolutely nuts, highlighted many of Lightning’s limitations in forced channel closes, drove the use of the Liquid sidechain and popularised the cross atomic swap between Lightning and Liquid, and it gave miners a much needed second revenue source outside of the block subsidy, and brought the Security Budget discussion back into vogue. However all these valuable lessons came at the cost of definitive and burdonsome resource costs.
The costs of inscribing monkey jpegs and rare sats into Bitcoin is a huge increase in the UTXO set, and with half at a measly 1,000 sats or less in value are effectively dust transactions and uneconomical to ever consolidate into less UTXO’s. The costs of using Bitcoin as a data storage chain is a permanent bloating of the UTXO set, that is borne in storage, resource and bandwidth costs by all self custodial users. Muh Tragedy of the Commons.
Bitcoin Consensus and Bull Market Adoption Year

As I wrote in my most recent post on the Bitcoin Halving, certain patterns keep repeating around a four year cycle, and between block subsidy halving years. The late 2012 halving led the December 2013 cycle high by thirteen months, the mid 2016 halving led the December 2017 cycle high by 17 months, and the May 2020 halving led the November 2021 cycle high by 18 months. In all three cases following the euphoric blow off top, came the 80% epic collapses of the bear market years of 2014, 2018 and 2022, bottoming out the bust cycle roughly 18 months before the next halving. We had already a doubling of the Bitcoin price year to halving in 2024 and a further ramping up to $100k by the beginning of 2025, and while correlation does not mean causation I don’t really think I’m sticking my neck out by saying that this will be Bitcoin’s repeat bull mania year of the 🟢🟢🟢🔴 pattern, that will likely take Bitcoin somewhere between $200k and $300k between Q2 and Q4 2025.

2024 was the year of institutions, 2025 will see the retail mania worldwide
If we take the Bitcoin price as proxy for institutional and retail adoption, then this will also create demand for new UTXO’s, blockspace demand and fees, 2025 will likely repeat the patterns of bitcoin transaction fee spikes and all that entails for the nework, in revenue for miners, frustrations for self custodial users and exchanges, increasing adoption of Lightning and Layer Two, and the rekindling of debate and consensus forming on the next soft fork upgrade.

Fee spikes in bull market years (source)
Soft Fork Scenarios and Timelines
Even though this tweet was ten days before the bull market year of 2021, it encapsulates pretty well the emotions of the bull market year in Bitcoin (source)
While there is a real possibility of 2025 passing without any consensus on a scripting upgrade, it is the year most likely to happen, as we are likely to see a bear market in 2026 when most if not all of Bitcoin’s scaling pressures and fees are subsiding, along with adoption and Layer Two solutions. On the flipside it is the year of respite for Bitcoin devs who can work once again without the distractions that is the curse of bull market years, when the world is hypnotised by the price and interest place new demands on scarce time. As I wrote in my Halving Post the bear market year is the yang to the bull market year’s ying, and a feature of Bitcoin rather than a bug, to stop it from breaking and allowing a catch up year for developers to work on the bottlenecks and bugs that came to light during the last bull market, alongside the soft fork upgrades (in 2017 and 2021), to build out the network further for the next bull market a couple of years in the future.
In terms of soft fork scenarios, just by my own intuition consensus will not be reached for all the op-codes listed above. The Great Script Restoration is likely not developed far enough at this point at least to be included in any soft fork in 2025, with no official BIP that I can find, and so will likely push us into the next four year cycle. The same is probably true of OP_TXHASH and OP_CHECKTXHASHVERIFY (BIP 346). I can’t see OP_CAT finding consensus either due to its association with the Taproot Wizards that would inevitably lead to pushback from the more hostile end of Bitcoin influencoors who lean toward conservatism and ossification, so OP_CAT in my opinion is more likely to come with the Great Script Restoration possibly in four year time?
This leaves us with OP_CTV (BIP 119) with the longest pedigree, most work done on it and with more Proof of Concept [POC] and considered a conservative and primitive building block for covenants via output introspection, which offers concrete improvements for Lightning and other Layer Two protocols, in conjunction with OP_CHECKSIGFROMSTACK (BIP 348) and either OP_INTERNALKEY (BIP 349) or OP_PAIRCOMMIT (BIP 442) that comprise the LNHANCE proposal, for upgrading the capabilities of the Lightning Network and Layer Two promising LNSymmetry, Non-Interactive Channels, Channel Factories/Joinpools and Vault/ARK.
In terms of timescales, a repeat of 2021’s Taproot with miner signalling upgrade support by year end 2025 and a five or six month lock-in with full activation in November to December 2025 is impossible, however the last six months of 2025 could see continued consensus building, fueled by a raging fee bull market as the byproduct of Bitcoin price gains in 2025.
A year of two halves?

Bull Market Years – A Year of Two Tops? (source)
There is an old adage within British financial markets that goes “Sell in May and go away, don’t come back until St Ledger’s Day“, that basically splits the financial year into two halves, with a strong first half to the year, a weak third quarter in the depth of summer holiday doldrums, and a fourth quarter flourish to finish the year. Obviously this is not a hard and fast rule that will ever be 100% accurate, yet sayings derive from somewhere and so does this. It was what we witnessed in 2024 for Bitcoin from ETF launch to the few weeks post Halving and a gang busters first half, Bitcoin then zig-zagged between $70k and $50k through the third quarter, before a stellar last quarter to smash the huge psychological threshold of $100k in December. If this repeats in 2025 then we are likely to see two tops in 2025, in June and December.
If the fee market follows the price as has played out in the last two bull markets, then we should see chain congestion in the second half of the year in order to build consensus, we also most likely will have the second coming in the last quarter of 2025 for the upgrade, leaving the first six months of 2026 to lock-in in a new bear market. This would allow the network and developers (if not the miners) to breathe and recover from the Bitcoin mania. Just in terms of fiat money, as most of everyone still conforms to “fiat brain” as unit of account, if Bitcoin more than doubles from here then a 1 sat v/Byte transaction fee will more than double, never mind if transactions surge to 100 or 500 sat v/Byte
Further Soft-Fork Upgrades and Longer Term Scaling
If the bull market in transaction fees fails to materialise in 2025 we will lose our best chance until at least 2027 and the ressurection year following 2026, and if not we will push any upgrades from Halving cycle 2024-2028 to 2028-2032, again looking particularly at 2029 and the busiest fee market year.
Slated further upgrades would include the Great Script Restoration as already discussed, and the only other upgrade I have seen come up more than once on my Bitcoin radar is the Great Consensus Cleanup. Originally proposed by Core dev Matt Corallo from 2019, it has been a long term slow burn project aimed to fix several long term vulnerabilities and bugs and some of Satoshi’s Original Sin. The major fixes are the Timewarp Vulnerability potentially allowing miners to mess with mining difficulty and inflation, reduce Large Block Validation times that could lead to increased compute costs and inadvertent forks, and a fix for Merkle Tree Vulnerabilities.
From Layer 1 to Layer 1.5: The Lightning Network – the Gateway to Layer 2

The original off chain payment layer and gateway into layer two (source)
Following the catharsis and PTFD (Post Traumatic Fork Disorder) of 2017 and the forking off of the big blockers, 2018 brought with it a renewed optimism for the future, and scaling Bitcoin through its second layer. My first (and only prior to this) post on the Lightning Network was released in October 2018 inside its first year, as a basic primer and introduction.
The Basics of Lightning Network
The Lightning Network Whitepaper was published in January 2016 by Bitcoin devs Joseph Poon and Thaddeus Dryja, distributed by different implementations based upon a common BOLT (Basis of Lightning Technology) protocol, developed (and still developing up to the latest BOLT 12) by collaborating and competing LN companies from 2017, notably lnd (Lightning Network Daemon) by Lightning Labs, c-lightning (now Core Lightning) by Blockstream, and eclair by ACINQ, being different but inter-operable, creating the foundation for transmuting bitcoin UTXO’s into a lightning quick network of connections and liquidity. The LN makes it possible for any self custodial node runner to connect to a network weaponising an UTXO into an instant, near zero cost infinite method for sending and receiving payments. With nodes and liquidity now on four continents, over 16,000 nodes and 4,400 bitcoins in capacity, the last seven years has witnessed the persistent growth of the Lightning Network and the original L2.


Lightning Network global visualisation and statistics courtesy of the marvellous mempool.space (source)
The Realities of Lightning
Part of the fork wars of 2017 was the pitching of off chain scaling layers and so the hype for the Lightning Network and the silver bullet to Bitcoin’s scaling challenges due to the blocksize, there was a vested interest and bias among triumphant small blockers to overestimate the scale and speed of lightning, myself included. Expecting a completely new network to be seamless and flawless was never realistic in 2018, and so the realities of the self custodial user running a lightning node in 2018 were practically non existent. The first lightning node setup I recall was Pierre Rochard’s node launcher, and while it ran on the same laptop as my Bitcoin Core node, with on chain fees and very little places accepting LN payments, I felt little rush to begin experimenting.
My second brush with running a lightning node was during the early months of Covid, I fell down the wonderful rabbit hole of self hosted servers aka plug and play nodes, that have revolutionised the scope and user experience of running a Bitcoin node. Starting with MyNode running off a raspberry pi and 1 terrabyte hard drive, but soon extending to Start9 and Umbrel, I got my first taste of installing and running a lightning node downloading the lnd daemon, and using Ride the Lightning front end, and straight away was slapped around the head by the technical complexity of opening channels, inbound and outbound liquidity and capacities, and looping in and out to rebalance. Compared to the simplicity and ease of Bitcoin’s base chain, despite the increasing fees during the first half of 2021, there was little reason to invest the time and effort to grokk Lightning.
As the realities of self custodial LN hit hard, it necessitated the growth of custodial solutions, at the trade off of sacrificing security for convenience. The slickest and most intuitive UI experience was the fully custodial Wallet of Satoshi launched from May 2019 and I would imagine the average user’s first taste of the magic of the lightning network (with over 500,000 downloads), with other mobile wallets on a scale to more self custodial in Zap Breez (April 2019), Eclair (April 2019), Muun (May 2019), Zap (August 2019), Blue Wallet (December 2019), Phoenix (October 2019), and Zeus Wallet.
The Limitations of Lightning – Failing To Scale Since 2018!

A look at an early LN testnet topology – December 2017 (source)
Despite the early promise and increasing number of Bitcoin devs that have chosen to spend most if not all their time developing Lightning, bootstrapping a new protocol and network was always going to take blood sweat and years as the alternative scaling solution to increasing the blocksize. Indeed there has been a persistent sberg out of big blockers and Lightning skeptics since inception, and the belief within a minority of the Bitcoin ecosystem that LN was mis-portrayed as THE scaling solution, with the future hitched to a fragile and inefficient solution consuming vast amounts of network capital and human capital, concentrated in the hands of centralised hubs and early Bitcoin companies. The complexities of self-custodial lightning did certainly lead to the rise of liquidity middle-men and custodians, also known as Lightning Service Providers (LSP’s), and the distribution of liquidity or semi-centralisation of the network to the hub and spoke model, pioneered by Breez SDK and LaaS, Blocktank, Boltz, Dunder, Block’s C=, Voltage, River Financial and Lightspark.
Other limitations that have fueled the schadenfreude of critics is Lightning’s embarassing underperformance during times of heavy chain congestion, which it was originally developed to mitigate and/or solve! The vulnerabilities of Lightning’s ties to bitcoin’s base chain were another painful but illuminating lesson on the limitations raised by the Inscription mania and fee spikes, that crippled to some extent both custodial and self-custodial lightning nodes. As Lightning requires on chain transactions and locking up pledged bitcoin to finance it, huge spikes in fees peaking in mid 2023 and exceeding 100-200 sats per vByte for periods, made it cost prohibitive to cooperatively close channels, and increasing forced closure of channels with low balances made uneconomical to maintain and become inactive. While these issues subsided with the burning out of inscriptions and ordinals, if and when fee rates do return so will Lightning’s vulnerabilities fuelling further criticism and mockery from the anti-lightning peanut gallery.
Lastly, Lightning has suffered from high profile developer criticism during its maturation, beginning perhaps with Tad Dryja and Joseph Poon not actively developing the network they wrote the whitepaper for, but notably the October 9, 2022 incident when Burak Keceli created a 998-of-999 multisignature Taproot transaction, exploiting a bug in LND nodes (and 70-80% of LN nodes), falling out of sync with the network and halting their ability to open new channels or process transactions. Burak framed this bug as a stress test to expose weaknesses, tweeting about the low cost and embedding a message in a follow-up exploit suggesting users switch to CLN. On November 1, 2022 Burak struck again with a Pay-to-Taproot (P2TR) transaction compromising LND nodes, including a transaction message “You’ll run CLN and you’ll be happy.” Burak then left Lightning contributions to work on Joinpools with Ark Labs. A higher profile and outright departure from Lightning dropped on October 20, 2023, when prominent Lightning developer Antoine Riard announced his exit, citing discovery of a critical (but obscure) security vulnerability involving replacement cycling attacks that could exploit mempool inconsistencies to potentially siphon funds from channels. Riard stated, “Effective now, I’m halting my involvement with the development of the Lightning Network and its implementations,” emphasizing that a sustainable fix would require base-layer (Bitcoin protocol) changes, not just Lightning tweaks. He shifted focus to Bitcoin Core development, signaling frustration with Lightning’s architectural limits rather than abandoning Bitcoin entirely.
The Continuing Success of Lightning – Scaling Since 2018!
Despite all the above limitations and criticisms, the sheer amount of developer capital invested into Lightning over the last seven years has led to a continuous timeline of improvements and upgrades, from Wumbo Channels (from August 2020) to multi path payments (ftom July 2020), dual funded channels and splicing (from March 2023), Keysend and Partially Signed Bitcoin Transactions (PBST) (from October 2020), Taproot Activation (November 2021), and the Taro Protocol (from April 2022), alongside major integrations with exchanges such as Kraken, Bitfinex, Strike and Coinbase, has vastly expanded liquidity and the reliability of the network, and with the marvellous UX of Wallet of Satoshi and Aqua Wallet in particular, catering for a pretty reliable Lightning Network experience for the custodial user.
On the non-custodial side, recent developments such as AlbyHub have empowered plug and play node users a far smoother and straightforward user experience for opening channels and balancing liquidity. While still dependent on an external party to manage a lightning node, the funds are self custodially held on the individual’s node. Thanks to the magic of AlbyHub I finally became a self custodial lightning network node runner in 2024!

AlbyHub dashboard on a plug and play node
Further Lightning Network Upgrades
The journey to upgrade the capabilites of Lightning is a continuous one, which also ties into one of the competing soft fork upgrades already discussed earlier, and the addition of op-codes in Bitcoin’s base layer for the benefit of scaling Lightning further.

The LNHance proposal has pitched itself as a method to scale Lightning and why in my opinion it has the best chance of developer consensus on the next upgrade to Bitcoin’s code, by combining the Op-codes CheckTemplateVerify, CheckSigFromStack, PairCommit and InternalKey. These op-codes would translate into Lightning benefits such as providing LN-Symmetry (Eltoo), Non-Interactive Channels (Asyncronous Payments), Payment Pools (Channel Factories) and Better Vaults/Bigger Arks.


The case for a Bitcoin soft-fork op-code upgrade, cleverly packaged as principally beneficial to the scalability, reliability and usability of the gateway into the Second Layer.
Evaluating Lightning
Lightning was born out of the fork wars and SegWit activation of 2017, and has inherited a lot of the baggage of the narratives of that war. For the small blockers, Lightning was propagandised as the silver bullet for Bitcoin’s scaling woes by the magic of off chain scaling layers, while for the big blockers Lightning was a vapourware layer undermining Bitcoin’s future as peer to peer cash. The truth is as ever somewhere in between, Lightning was never a silver bullet that would solve all of Bitcoin’s on chain limitations, while it was always going to complement rather than undermine the base layer contrary to big blocker catastrophising. My own view has evolved over time from my wildly optimistic expectations of Lightning from my 2018 blog as THE solution to scaling Bitcoin as medium of exchange and unit of account off chain, to the slow realisation that Lightning is a connective layer or the glue to stitch access and the gateway to layer two. Rather than Lightning being THE solution, Lightning is turning out to be ONE solution of many, but also the solution to the developers working on Layer Two projects and connecting to Bitcoin’s base layer through Lightning, for both the custodian and the self-custodian.
We can proceed to Layer Two proper…
Layer Two – Sidechains

Diagram of Liquid Blockchain and Network (source)
The first obvious question is, what is a sidechain? In short it is a chain independent of Bitcoin, while also being intrinsically linked or pegged to it. Similar to Lightning it is a two way peg out of and back into Bitcoin, but unlike Lightning is regulated by a blockchain instead of a network. The theoretical discussions of sidechains have a history almost as long as Bitcoin, as the strict of limits of its blocksize had made it obvious to long term low preference thinkers, that for Bitcoin to maintain underlying decentralisation would have to scale to a layered system of protocols on top, and to centralised, custodial or semi-custodial trade-offs.
Sidechains introduce us to to cryptographic custody and a centralised party, and different to the Lightning Network which has an “unilateral exit” that mediates between counterparties without a middleman (in self custodial mode), sidechains have different flavours but essentially boil down to a federation of centralised entities that monitor and enforce network rules. As the mantra of the self-custodial Bitcoiner is “not your keys, not your coins”, then becoming subject to centralised (if federated) corporations renders self custody inferior to Bitcoin, Lightning, and possibly Statechains and Joinpools, and is a fundamental insight of this essay to be discussed further on.
Flavours of sidechain include miner validation known as drivechains as per Paul Sztorc of Layer Two Labs BIP 300 (hashrate escrows) and BIP 301 (blind merge mining) proposals that have gained little traction in the wider Bitcoin community and unlikely to garner the consensus required for a soft fork upgrade, or federated corporate validation in the examples of RSK (formerly Rootstock) and Liquid.
Liquid
Concentrating on Liquid, the Blockstream sidechain whitepaper goes back to June 2014, published by Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille, introducing the idea of trustless sidechains, though Liquid later adopts a federated model as a workaround for the soft fork upgrade problems and delays that have plagued drivechains for instance.
In 2015 Blockstream forked Bitcoin’s codebase to create Elements and the foundation of Liquid, that can like Bitcoin, be downloaded and run as a self custodial node, including plug and play nodes such as Umbrel. On October 12, 2015 Liquid is launched targeting exchanges, payment processors, and traders, as a quicker settlement chain than Bitcoin, with initial partners including Bitfinex, BTCC, Kraken, Unocoin, and Xapo.
On October 11th 2018, Liquid went live after three years of development with 23 members.
Liquid Features
Despite being a fork of Bitcoin, Liquid has one megabyte blocks with one minute block times (vs Bitcoin 10 minute block time) with two block finality for quicker settlement. It has also integrated Confidential Transactions (aka bulletproofs) and a proposal for a Bitcoin soft fork at one time, which hides transaction amounts and a privacy upgrade to Bitcoin proper. Throughput estimates vary but a one megabyte block every minute is a ten x notional scaling of Bitcoin’s base-chain via sidechain, at the trade-off of a semi-custodial trust model.
The Liquid Federation

A federation, although centralised, is also distributed. Collusion requires 11 of the 15 members of the Liquid Federation to rugpull bitcoin (source)
As Liquid was largely developed for exchanges, then it makes sense that exchanges would also form the federation that governs it. The internal layer is the 15 functionary operators which are not fixed and changeable, but presumably include Blockstream, Bitfinex, Bitso, Xapo and OKCoin. The semi-anonymity and distributed geographical location of servers in disparate global jurisdictions protects Liquid to a large extent from single state crackdowns, and would require global government co-ordination to shut down in a world that is largely relaxing its views on legally defined commodities such as Bitcoin, and on legally defined securities or derivatives such as Liquid. Despite Liquid’s centralisation, its distribution makes it relatively censorship resistant, boosting its future prospects as a securities and exchange layer.
External federation members range between 70 and 80, from Huobi, Ledger and Coinos, and spreading more recently to decentralised peer to peer exchanges such as Bisq, HodlHodl, and PeachBitcoin during the ordinals fee spike.
Liquid Credit Creation

Liquid has just under 4,000 btc pegged in, as compared to Lightning with 4,400 btc (source)
As with Lightning, Liquid is a two peg with Bitcoin, so bitcoin UTXO’s must be pledged and pegged into the Liquid network via an exchange such as SideSwap. Like Lightning therefore it is a fully reserved layer two, with an 11of15 multisignature for peg ins and peg outs. Also mirroring Lightning, Liquid tends to increase peg ins during bull markets in Bitcoin on chain transaction and fee bull markets, while peg outs tend to increase when there is a bear market in on chain transactions and fees.
Liquid and Lightning Interoperability

The value of Lightning in facilitating cross atomic swaps between blockchains (source)
The full title of my October 2018 Lightning blog was Bitcoin, Litecoin, Lightning Network and Cross Atomic Swaps – Two Become One in which I speculated on the Lightning Network making other blockchains interoperable (and in the case of Litecoin another 4x scaling upgrade to Bitcoin), six and a half years later with Litecoin fading in relevance and Bitcoin’s base chain running on empty, is probably the worst call I’ve ever made on my blog. Either my call will remain wrong and get wronger, or we are still early and Bitcoin’s scaling pains will bring Litecoin back into relevance at some point in the future, and on the cusp of Litecoin ETF‘s and direct Wall Street monetisation it is likely that Litecoin will stick around a while further. If I would have substituted the word Litecoin for Liquid however, I would have described exactly what has happened with the increasing fungibility of Liquid via Lightning network cross atomic swap prodigy Boltz.Exchange.


Boltz.Exchange brings together the Bitcoin family at the speed of Lightning. Wen Litecoin?!
Boltz is a non custodial (user has sole access to private keys) server website allowing near instantaneous swaps between Bitcoin and its sidechains, supporting their fusion and fungibility. This in my opinion benefits Bitcoin by obfuscating and anonymising transactions and trade in off chain layers, likely to the chagrin of chain analysis and Bitcoin on chain surveillance. The cross atomic swap as I posited in my Lightning post will have ramifications for tax authorities and law enforcement as it increases their surveillance vector demands and costs to other chains far harder to track than Bitcoin! The cross atomic swap also benefits Liquid and Rootstock by a far quicker peg in and peg out mechanism than traditional pegs, and complementing direct peg in apps such as SideSwap and Aqua wallets.
Liquid infrastructure
Liquid’s long history gives it a decent amount of first mover status and network effects over competing and developing chains, it was integrated into Blockstream’s Green wallet and one of the longest developed Bitcoin wallets (with over 100k downloads), SideSwap.ai as securities marketplace (over 10k downloads), and with the new up and coming Aqua wallet (over 10k downloads), the Bicoin, Liquid, Lightning, Tether super app. Liquid also has Lightning network integration via c-lightning allowing instant L-BTC micropayments and foreshadowing support for assets like USDt (Tether).
Liquid Use Cases

The first use case is as a settlement network for Bitcoin exchanges in currencies and securities, and DeFi has been building on Liquid since 2022, with tokens such Blockstream Mining Note (BMN) and integrations with Tether (USDt).
Liquid is becoming central to Bitfinex burgeoning securities business as one of Bitcoin’s oldest and most successful exchanges, and the platform for issuing tokenised bonds for venture capital in El Salvador and Kazakhstan.

The second obvious use case is the payment rail. Even though I had been aware of Liquid for a long time, I had little reason to use it while Bitcoin on chain fees were low and Lightning Network reliability remained high. This was brought to a close with the Inscriptions mania and fee spikes at the end of 2023, and basically forced me into adopting Liquid for my periodic payments, firstly via SideSwap and then utilising boltz.exchange to convert into Lightning for gift card purchases, thereby by-passing batshit insane fees for next block confirmation and Bitcoin’s 10 minute next block period.

The Liquid to Lightning interface got a further upgrade on January 3rd 2024 when the marvellous Aqua Wallet launched, and in the year since has integrated Boltz and Liquid/Lightning swaps, which allows me to conveniently pay for gift card purchases via Lightning, with the transaction swapped and settled on Liquid within 60 seconds. Not pure Lightning but a major upgrade on Bitcoin basechain confirmation times, with self custodial ownership of private keys.

Aqua has been a godsend not only during the fee spike, but since too. Leaving a few months of purchases in Liquid with ownership of private keys, is barely a risk trade off for consuming
The Future of Liquid
Liquid has come in for a load of stick and snark from developers of competing second layer chains and Bitcoin Maxis for its security and “custodial” tradeoffs, and this was the price Liquid paid in lieu of waiting for soft fork upgrades to reach trustless self custodial nirvana. Ten years later Liquid is Bitcoin’s most successful sidechain so far, while Drivechains flounder in BIP form and statechains are only emerging and also dependent on soft fork upgrades for scaling to compete. In the meantime, Liquid is likely to continue to thrive as an alternative pipeline for the Bitcoin exchange network that are largely intergrated to it already, and as a platform for exchanges to create securities markets and venture capital into Bitcoin’s most innovative companies and economy. Its wallet integrations and lightning swaps has also made it the most reliable Layer Two payment rail and adoption will wax and wane based upon the transaction and fee backlogs gumming up Bitcoin base chain. If the future you see is mainstream worldwide adoption of Bitcoin and a basechain full of high paying transactions for inclusion in history’s greatest accounting invention, then it stands to reason that Liquid will scale its adoption to its finite blockspace limits, and pressuring the next wave of adoption for statechains and coinpools and ecash. Liquid is not a siver bullet for Bitcoin’s scaling woes, but will play its part in complementing and reducing Bitcoin congestion by an off chain scaling increase, and the whole raison d’etre of Layer Two in the first place.

Liquid seems to trigger purists, but is a practical solution for pragmatists
Layer Two – Statechains

Statechains: Sending Keys, Not Coins, to Scale Bitcoin Off-Chain – 2019 primer (source)
Statechain sounds similar to a sidechain however the “chain” is rather a chain of custody, and “state” refers to the state of ownership of an UTXO that is tracked off chain, so it is private keys that are being transferred rather than the coins, and was the brainchild of Ruben Somsen, a Bitcoin developer via the Bitcoin mailing list. The exchange of private keys off chain is delegated to a central entity or “state” actor known as a “statechain entity”, differing from Liquid’s federated and distributed peg in an out exchange network with a centralised counter-party, but subject to distribution of security and risk by the use of multisignature technology, exactly like Liquid. In my opinion the most important factor is that Bitcoin’s base chain is and remains decentralised, while second layer solutions can tolerate centralisation by distribution of custody keys, especially as these are not cold storage and store of value bitcoin, but medium of exchange bitcoin to consume or produce.
The benefits of statechains should be obvious: off chain transactions transcend Bitcoin’s ten minute block confirmation time and scarcity driven fee market, while also allowing fast low cost transaction between peers, and a degree of privacy unobtainable on the base chain.
The limitations of statechains basically boils down to the statechain entity and the degree of decentralisation possible that is largely dependent on lightning network upgrades, that is dependent on future Bitcoin soft fork upgrades. The interoperability of statechains with the Lightning Network also makes possible in statechains, spookchains and coinpools, the continuation of the “unilateral exit” principle that cannot be applied to Liquid’s federated sidechain.
Statechains – Mercury Layer by Commerce Block

Mercury Layer is the most primising current iteration of statechains (source)
Mercury Layer has moved the idea of statechains on, bringing in the moniker of state channels, a description aligning it more with the idea of lightning than of a chain. The major innovation of Mercury Layer is the blinding of the statechain entity or server, improving on the original statechain thanks to the Schnoor signatures and Taproot addresses, upgrade as part of the 2021 Taproot soft-fork, and allowance of the blinded MuSig2 protocol to generate signatures without revealing sensitive information to the Statechain Entity.
For a practical example, User A can deposit bitcoin in a wallet on the Mercury Layer, designate a statechain entity to facilitate trade, and then connect to another Mercury wallet to trade. The entity is blind to all transactions between the two clients, and added with other crypotographic timelocks allows a backout transaction, unilateral exit to the basechain if the statechain entity is compromised, similar to Lightning.
Mercury Layer is being pitched as a blinded signer service whereby users can pay for sessions (one year for example) to facilitate off chain transactions, and is an effective backend for Mercury wallet developers to integrate. In this way CommerceBlock have transitioned away from Mercury Wallet and GUI to the Mercury Layer library and CLI tool other wallets can integrate, fostering innovation for competing wallets to be built on top.
Nicholas Gregory of CommerceBlock talk on Statechains and Mercury Layer (source)
Benefits of Mercury
The benefits of Mercury are transforming UTXO’s into VTXO’s (Virtual Transaction Outputs) that settle in under one second, that are cost free (the user rather pays in time (sessions)), and the blinded signer providing a level of privacy and anonymity far superior to the base chain.
Limitations of Mercury
Like Lightning, Statechains are tied to basechain UTXO’s and subject to its limitations. High fees increase the costs of entering and existing statechains, and once inside the statechain only the fixed UTXO denomination can be swapped, unable to be broken down into smaller transactions with no fungibility upgrades. Once a trade is completed the next trade is limited by an eight hour decrementing timelock to allow for the backout transaction and unilateral exit. Statechain entities are also not fungible.
Statechain and Layer Two Interopability
Mercury Layer is developing on the Lightning Network for atomic swaps of private keys, and there has been interest from e-cash and NOSTR developer communities on intergrating Statechains in the future. Watch this space!
Statechains and Soft-Forks
Statechains like other L2’s (outside of possibly sidechains) are subject to Bitcoin’s limitations, and CommerceBlock are supportive of Covenants in general, and LNhance in particular, for enhancing the possibilities of what Statechains can do in the future.
Current Status of Mercury Layer
The Mercury Layer blind signer service is live, with a test wallet and a Command Line Interface (CLI). CommerceBlock is seeking feedback from projects about its API requirements, working as a backend for these projects to integrate their own wallets and GUI’s.
The Future of Statechains
Statechains are an innovation and promise a major scaling of Bitcoin UTXO’s off chain, developing use cases for ordinals/inscriptions swaps and Bitcoin transactions in general. The future adoption of Statechains like all other Second Layers will be driven by on chain transaction and fee congestion, and so if you are bullish on Bitcoin adoption and growth in general, then the future adoption and growth of Statechains will also be bullish.
Variations on Sidechains
2024 has seen the introduction of Lightspark’s Spark as a custodial statechain implementation, and other flavours of Statechains include Spookchains.
Layer Two – Joinpools

Simplified concept of a Joinpool (source)
Joinpools will be described broadly here, also inclusive of Coinpools and Payment pools, as constructions that allow multiple users to trustlessly share ownership of one or more UTXOs. When funds are spent, it’s not possible to tell from the blockchain which pool member spent the funds. Joinpools can use presigned transactions or proposed protocol features to ensure each member can unilaterally withdraw their funds from the pool at any time.
Joinpools – Ark

A pool where users can join by depositing coin for payments (source)
Ark has been creating hype and stir in the Layer Two space for a while, first proposed by Burak in 2023 on the bitcoin-dev mailing list, Ark has evolved with contributions from Ark Labs and the Bitcoin community. Similar to Statechains it transforms onchain UTXO’s into off chain VTXO’s, but unlike statechains (at least in current form) pools these UTXO’s making them fungible and not limited by denominations or to only two parties, and like Statechains transactions are near instant, low cost and private. Ark resembles Lightning in that it enables an off chain pool of liquidity, while it differentiates in being a self contained multi-lateral trading room rather than a bi-lateral abacus.
Ark’s trust model operates with a central entity called an ASP (Ark Service Provider), but similarly to Lightning and Statechains funds are held self custodially with an unilateral exit mechanism from off to onchain in case of Ark (server) failure. The server co-ordinates all transactions within the ark, from periodic rounds that acts as a transaction batcher that allows off chain, on chain, and lightning transactions. While each ark is a self contained bubble, it will be possible to connect arks via Lightning.
Ark is a complicated beast, and this an excellent in depth discussion of the ARK implementation nearing mainnet by second.tech CEO and veteran Bitcoin developer Steven Roose (source)
Benefits of Joinpools
The benefits of Joinpools is similar to Statechains in transforming UTXO’s into VTXO’s that settle in under one second, that are cost free (the monetisation model of Ark is similat to Mercury in charging for the server and/or wallets paying in time), and a level of privacy and anonymity far superior to the base chain. It is also superior to Statechains as far I can gather in that there are no fixed denominations, acting more like Lightning in allowing payments of any size and a fungibility upgrade.
Limitations of Joinpools
Like Lightning and Statechains, Joinpools are tied to basechain UTXO’s and subject to its limitations. High fees increase the costs of entering and exiting joinpools, but once inside the Ark UTXO’s are fungible to be broken down into smaller transactions. Joinpools are less developed at this stage than Lightning or Statechains, and therefore further limitations may bubble to the surface as development work proceeds.
Joinpools and Layer Two Interopability
Joinpools are also developing on the Lightning Network for atomic swaps of private keys, with possible future integrations with e-cash and NOSTR, it is also likely that Lightning will be used to swap private keys between Arks in the future.
Joinpools and Soft-Forks
While Ark can and is being developed with Bitcoin’s basechain as it is, a soft fork upgrade and covenants in any form will create efficiencies and scalibility as stated by Steven Roose of Second Tech in the above interview, CTV and LNhance will be beneficial for joinpools as for Statechains and Lightning.
Current Status of Ark
There are currently two independent implementations of Ark, in Ark Labs and Second Tech, and similar to Commerce Block in the Statechain space developing the server backend (Ark Service Provider) via Software Development Kits (SDK’s) to allow multiple and competing wallet integrations by app developers, with the monetisation model being based on the ASP and/or wallet fees. Ark Labs Wallet SDK CLI is available for testing on the MutinyNet testnet, and Second Tech’s Barc server is currently in Signet with mainnet launch likely by the end of this year.
The Future of Joinpools
Joinpools and especially Ark are garnering interest and hype within Bitcoin’s self custodial circles as a medium of exchange solution, and a hub of interoperability for Bitcoin’s other L2’s. Ark does not require the complexity of locking up liquidity to participate and so it allows new Bitcoiners to join and accept bitcoin without existing UTXO’s.
ARK – a complementary element of a burgeoning Layer Two ecosystem (source)
Layer Two – E-cash

The first e-cash of the internet – David Chaum’s DigiCash. Satoshi Nakamoto cites DigiCash in the 2008 Bitcoin Whitepaper (source)
E-cash has a long and storied history prior to Bitcoin, developed by David Chaum from the Eighties onwards recognising a future of digital currencies and their threat to privacy and freedom. The largest technological communications leap in the history of humanity and money/currency begins with internet privatisation in 1994, and the Age of Experimentation with computer money and digital currency. Indeed, within the internet’s first year and years ahead of the banks, David Chaum released DigiCash, a digital cash that communicated with correspondent banks to settle trade peer to peer, anonymously through blind cryptographic signatures, with the first payment completed in 1994. Unfotunately for Chaum, a lack of interest by the banks in his digital and anonymous e-cash, meant that DigiCash would go bankrupt in 1998.
E-cash – concept
The concept of e-cash is basically a reinvention of banking, whereby a custodial and centralised counterparty (from here on in called a mint) co-ordinates tokenisation of bitcoin for peer to peer trade. E-cash issuance is tied to on chain UTXO’s and interoperable with the Lightning network, whereby bitcoin can be deposited in a mint and transformed into e-cash tokens. Users can then use these tokens to trade amongst themselves and is perfectly off chain and anonymous via the mint’s blinded signature scheme, tokens can then be redeemed via Lightning back into Bitcoin for other uses, or withdrawn to self custodial cold storage.
E-cash – Cashu

The rabbit hole into nut jokes: cashu.space (source)
Cashu is the brainchild of Bitcoin developer Calle and geared around facilitating bearer cash style payments between peers.

The core functionalities of Cashu are as follows:

While token creation and redemption is co-ordinated via single mints, e-cash can also be swapped between mints via the Lightning Network.

Benefits of e-cash
E-cash facilitates the same sort of benefits as other Layer Two’s, in near instant, low cost and anonymous off chain swaps, and is in a method re-creating the Origin of Banking via the double-entry book-keeping ledger that flourished at the end of the Middle Ages, and the facilitator of the Protestant Reformation that has ruled the financial landscape this las last five centuries. It is ironic therefore that the birth of Bitcoin and triple-entry book-keeping and what I have termed in the past the Counter-Reformation that will destroy fractional reserve banking, will itself be using banks and banking to facilitate exchange.

A blast from the past to trigger Bitcoin Maxi purists – Hal Finney muses on Bitcoin backed banks (basically Layer Two’s) back in December 2010, when Bitcoin was barely two years old! (source)
Limitations of E-cash
The limitations of e-cash are the same as any other L2, in the setup of the backend co-ordinating server, and unlike Lightning, Statechains or Joinpools, e-cash does not allow for unilateral exit, and at this time must be considered a fully custodial Layer Two. Indeed, e-cash has caused some contoversy within Bitcoin for the purists who see no value and only fraud, destructions and rugpulls in the future for e-cash. However, I will continue on with risk mitigations and trust mechanisms that can scale e-cash as one of many Layer Two Solutions.
Mints – Risk Mitigation

There is continuous work on developing and refining Prrof of Reserves and Proof of Liabilities schemes within Cashu to mitigate the risk of a single mint rugpull.
Mints – Risk Distribution

A Federation of Mints – Fedimint
Fedimint is an e-cash project that is seeking to upgrade mints from centralised and single signature to a federated and multi signature mint model, distributing risk between more members and emulating Liquid’s security trade off.
E-cash and Layer Two Interopability
E-cash is fully interoperable with Lightning, and thus subject to future integration with Statechains, Arks and NOSTR, as one more arrow in the L2 quiver.
Current Status of E-Cash
E-Cash is continuously developing via both Cashu and Fedi, with the first wallets already in beta, I have been able to fiddle around with e-cash through the cashu.me web wallet, and downloaded enuts via Android APK, and the minibits wallet through the App Store. Some e-cash sats can then be created by funding with a Lightnjng payment, and sent and received between the wallets to test them out, and also allows e-cash swaps between mints for a small fee, very cool!


Minibits (left) and enuts (right) – two mobile e-cash wallets for experimentation
The Future of E-Cash – Community Banking
The main use case for e-cash at present is as a payments method for small purchases, and for sending and receiving zaps from NOSTR integrations, but e-cash has fascinated me more as the custodial solution for the ressurection of local or community banking. Indeed, in the now over eight year old post Decentralising Credit and Currency – Economies of Scale and over seven year old 8,000+ word primer on the Economics of Local Banking, I explored the future of community banking working on top of the Bitcoin blockchain with a physical layer of local currencies, from community banks and automatic teller machines (ATM’s) issuing local paper currencies redeemable for bitcoin.
The main drawback of local banking is the price premium over basechain Bitcoin, in ownership or rental of a local building, bank employees and the production costs of paper currencies, however the costs of e-cash will in a future of high basechain transaction fees trade at a discount to Bitcoin, by offchain (and anonymous) administration of peer to peer local trade. For an illustration, imagine a local bank running a full node and connected to Bitcoin’s global network, and operating on top an e-cash mint co-ordinating a community of a hundred local bitcoin users, the banker (aka self custodial bitcoiner) can transform a single UTXO into a local barter system for custodial customers and possibly their first interaction with Bitcoin. As adoption grows and users familiarise themselves, they are able to redeem their e-cash into custodial Lightning, and eventually into a self custodial UTXO of their own in cold storage. Furthermore, a local bank can issue paper currencies pegged to e-cash (bitcoin) with issuance and retirement being matched by the bank on a 1:1 (full reserve) basis.
Outside of purely based local trade, community banking allows the limited practice of interest based deposits and the issuance of loans to invest in local businesses and infrastructure, and may be a way for wealthy local bitcoiners to invest in their local communities to fuel local economic growth, although the deflationary nature of bitcoin as I have discussed in past posts will make long term debt issuance unprofitable for both borrower and lender, short term debt issuance and repayment terms could fund local businesses with start up capital.
The main two trust models for custodial mints will be an online social credit score whereby mints operate on a ratings based systems that may well be facilitated by social media platforms such as NOSTR (discussed further next), or a local based trust system with face to face familiarity. The limitations of local mint fraud and rugpulls should be obvious, in that the mint owner is publicly recognisable and subject to retaliation and retribution by his local community for theft and betrayal, will keep any local bank strictly in check, and can be further distributed by federated mints that would require a co-ordinated rugpull, while also scaling e-cash banking from local to regional or county scale networks. In either case, a single or federated mint rugpull will cause local chaos and turbulence but will not impact in any way upon of the operation of Bitcoin’s worldwide blockchain and settlement network, and the polar opposite of the traditional banking system which has increasingly been bailed out and centralised by National Governments during financial crises.
In my economics of local banking post I predicted the ressurection of local banking to start developing between 2025 and 2030, well we are now in 2025 and we have what I believe is the transitionary layer (2) between Bitcoin and community banking in Chaumian e-cash, Cashu and Fedimint. I am fascinated and insanely bullish on e-cash because I have long believed and foreeen the need for the return of local banking, in a world where traditional and nationalised banks are closing all of their local banking branches, obsoleting the use of physical cash (banknotes), and fully plugging into the online matrix of the doomed global fiat currency headed for a catastrophic collapse. As Bitcoin continues to grow as a store of value will increase demand for use as a medium of exchange and unit of account, as e-cash continues to develop and refine a definite need and use case for community banking in a rapidly decentralising and distributing world, then I predict the ressurection of local banking is on track for flourishing from 2030 parallel to a slowly collapsing fiat currency system and government enforcement of laws. The 2030’s will see the decentralisation of credit and currency worldwide on a local scale, starting the return to the banking system that existed in Great Britain until the early 1840’s and the abolition of local banknotes by London’s Parliament and the nationalisation of Bank of England banknotes. If you understand the history of credit and money, local ledgers for trade and taxation are built into the fabric of man for mental barter, and as a workaround for the shortages or shortcomings of money and coinage. If you are insanely bullish on Bitcoin as a future global medium of exchange, then Bitcoin will suffer from the same shortages and shortcomings in its UTXO throughput and value, then it follows that humanity will once again invent local bi-lateral and communal exchange using non-money (off chain) swaps via e-cash mints and/or local paper currencies. If you are insanely bullish enough on Bitcoin, you can envision a time maybe a few decades out, where the whole value of an off chain local banking infrastructure trades at a discount to the value of moving an UTXO!

A diagram I created in 2016. As Bitcoin expands its layer two, medium of exchange and unit of account properties will drive toward a more local method of settlement in electronic and physical cash
Layer Two – NOSTR

Notes and Other Stuff Transmitted by Relay – NOSTR
“This second layer also allows entry into and adoption of Bitcoin at medium of exchange and unit of account layer, and thus by nature Lightning is magnitudes more efficient as a method of adopting Bitcoin than through the store of value layer and fiat to bitcoin exchanges, and this medium of exchange layer can literally stream money, send payments by fractions of pennies or cents and therefore for the first time in history makes micro-payments feasible, which will in the coming decade unleash a whole new revenue model for the internet, eliminating the corporate revenue model of advertising and ad revenues that have been hoarded by tech corporations impoverishing the mass of actual content creators that fuel the internet and online advertising, and replacing it with the tipping economy, whereby content creators get rewarded through micro-transactions for providing valuable content, not with click bait and spamming, in my opinion this will become a major use case for Bitcoin adoption as millions if not billions of internet content creators can now monetize their efforts, and perhaps even make a living out of the internet.” – Bitcoin Kills Banking Redux, February 2019
Concept of NOSTR
NOSTR is Bitcoin’s up and coming social media and future social credit and trust layer, leveraging Layer Two technology as an everyday wallet for streaming money and sending or receiving micropayments, and may well develop as the masses first interaction with the Bitcoin ecosystem.
Background of NOSTR
While governmental and corporate censorship of the internet had surged in the wake of Brexit and Trump as the two major rebukes of Globalism in 2016 and fueled by online “misinformation” according to the political and cultural elites, the censorship was weaponised from 2020 by the Covid Scamdemic to censor dissent against the locking down of the world for a flu, and to enable mail in voting to steal the 2020 American election. For every action there is a reaction, and in November 2020 veteran Bitcoin dev fiatjaf launched NOSTR, a social media protocol based upon clients and relay servers, to distribute power and control away from centralised platforms and data storage. NOSTR was given legitimacy and funding by Jack Dorsey in December 2022, himself disillusioned with the centralised social media model as the creator of both Twitter and BlueSky, which provided a lot of the boot-strapping for the rise of NOSTR over alternative ideas and proposals in the decentralised social media space. A further endosement by Edward Snowden also gave NOSTR interest and popularity in 2023.
Basics of NOSTR
From smart servers and dumb clients, to smart clients and dumb servers – Ben Arc, veteran Lightning Developer on NOSTR (source)
What distinguishes NOSTR from other mainstream big tech platforms is that the server (and information storage) is not centralised but distributed between many relays (servers), but not decentralised and peer to peer, although NOSTR can become peer to peer if both parties run their own relays, which the wonderful world of self hosted plug and play nodes cater for.

Self custodying NOSTR data is trivial thanks to Umbrel, Start9 and MyNode
With the protocol and server side dealt with, the beauty of NOSTR is that it unleashes radical experimentation and competition on the client side. Having dabbled for the last few years, I started with Coracle in the early days, then drifting toward Snort, and then discovered by far the best and smoothest in Primal. The competition in this space is insane with 25 different NOSTR clients to list fully, encompassing mobile clients, web clients, desktop clients and specialised clients. All are interactive with the protocol via a public and private key pair, and all are interactive with the lightning network to send or receive zaps (micro transactions) via custodial means or self custodially via a lightning node with Nostr Wallet Connect (NWC).
Benefits of NOSTR
The obvious benefit of NOSTR is the introduction into Bitcoin via social media, and through a possible killer app of mass adoption, in monetising Bitcoin through the tipping economy. I have held for the last decade that the early optimism of the internet that got hijacked and centralised through the tech giants (especially Google) utilising the ad revenue model as the monetisation and wealth hoarding strategy to immiserate the mass of content creators that fuel the internet and ad revenue model, would increasingly give way to the forces of decentralisation and peer to peer micropayments as the superior internet revenue model. As we hit 2025, with anti-trust forces in the US and Europe breaking up Google and Apple’s monopolies over app stores, internet search engines and ad revenue models, the next five years is ripe for the upgrade to the tipping economy, for which legacy banking payment networks are ill-equipped but Bitcoin is perfectly suited for, via the medium of exchange and unit of account layer two.
Limitations of NOSTR
NOSTR comes in for some criticism from corners of the Bitcoin maxi purist space in that it is not strictly peer to peer and largely censorable through targetting central companies i.e NOSTR projects, but these are the same criticisms of all other Layer Two’s that are subject to the same limitations, the development of self hosted plug and play nodes are catering and will cater further to self custodial ownership for an increasing cohort of newly adopting Bitcoiners as mass adoption continues to play out. Let not perfect be the enemy of the good.
NOSTR Use Cases
Paying for yoga classes in Bitcoin – powerful visualisations of micro economies in Costa Rica featured regularly on the wonderful Primal NOSTR app (source)
The first use case is a straightforward medium of exchange, whether sending or receiving zaps (sats) for social media content that is rife throughout NOSTR’s various clients, and the most compelling candidate in my opinion for the flourishing of the tipping economy as the direct competitor and eventual nemesis of the ad revenue model of internet monetisation. NOSTR is also emerging as the payment layer of the real life bitcoin economy, as can be seen regularly on Primal in pockets of the world. As the value and adoption of Bitcoin grows, so the utility as a medium of exchange and peer to peer network grows, as demonstrated.
An example of the bitcoin circular economy from New York, USA, facilitated via the Lightning Network and NOSTR (source)
The second use case is the emerging potential as a social credit layer and the basis of a trust based exchange network between peers. The basic premise is that a social media account and a public/private key combination works as an anti spam/fraud measure, enabling a public payment directory and identity network and web of trust. A trust rating (similar to Amazon reviews) can be generated and attached to individual or business accounts verifying identity, followers and various other checks that distinguish genuine users from copycats and scammers. NOSTR can therefore act as the web of trust for a growing circular economy of peer to peer trade, micropayments and tipping, it can even be applied to e-cash mints and other centralised custodians in the distributed future built on top of Bitcoin’s decentralised future. The scope of possibilities and opportunities is virtually unlimited.
The future of NOSTR
If my writing doesn’t make it clear enough, I am insanely bullish on the future of NOSTR as a bridge between the lightning network and the masses via a social media layer, and that it can develop the trust networks to scale e-cash mint networks and other custodians in a distributed future of Layer Two applications already discussed.
Before concluding another epically long post exploring the medium of exchange and unit of account layer, I must include a section on Bitcoin’s main use case today and of the last sixteen years, as store of value.
Bitcoin’s First Function – Store of Value
For all the discussion and the disagreement among Bitcoin’s self custodial community on the necessity and speed of evolution to medium of exchange and unit of account, both are downstream of mass adoption as a store of value. Indeed throughout the history of credit and money to which I have devoted the last decade of my writing and my blog, there are two countervailing laws, namely Thiers’ Law and Gresham’s Law. Thier’s Law predicts that superior money will be hoarded as a store of value (mirroring Bitcoin’s ascent) while on the flipside Gresham’s Law predicts the bad money will be circulated (mirroring fiat money’s descent). At the highest level view, Bitcoin has a long journey yet in front of it to displace fiat money as medium of exchange and unit of account, until it has sucked the global fiat currency regime dry of store of value status, via hyperinflation which in my opinion is baked in long term.
To the history of Bitcoin specifically, the killer app of Satoshi’s protocol was to cap the supply of bitcoins, issued pre-determinedly, and thus a store of value function independently of the value of fiat currencies. As Bitcoin had to start from scratch it had zero users and therefore zero value in the early days, and in a world where incumbent fiat currencies ruled. Additionally as Satoshi had designed bitcoins to be issued and further distributed by miners, and as Bitcoin’s proof of work required electrical and computing costs to create bitcoins, it was clear that the mining community and by extension the network would have to grow by connecting to the fiat currency apparatus to monetise.
This necessitated the creation of Bitcoin exchanges, for miners to exchange their bitcoins for fiat and for early adopters to exchange their fiat for bitcoins. The first exchange of any note in those early years was Mt Gox (launched July 2010) and therefore it became the premier price discovery point of Bitcoin’s early value in fiat currencies. Other notable early exchanges were Bitstamp launched August 2011, Local Bitcoins (an over the counter peer to peer exchange) launched June 2012, Coinbase launched October 2012 and Bitfinex launched December 2012. Despite a major wobble in faith with the collapse of Mt Gox in February 2014, the exchange network worldwide continued to build out in the first decade of Bitcoin.
Bitcoin Kills Banking Redux: Exchanges
Bitcoin Kills Banking was a three part exploration of the words, with part three concentrated on the gatways between banking and bitcoin, exchanges. I elaborated on six prototypes, in decentralised (non kyc) exchanges, mobile phone apps, centralised exchanges (institutional gateways), derivatives exchanges (futures and ETF’s), banking protocols (Ripple and Stellar Lumens), and stablecoins (Tether). Over six years later the post is more relevant than ever, with growth in all protypes and meteoric growth in centralised exchanges, derivatives exchanges and stablecoins, and all serve one ultimate purpose that is the draining of fiat currency regimes worldwide of value into a superior digital, decentralised and global store of value. It follows that exchanges and store of value properties will continue to dominate over medium of exchange and unit of account properties, until a dominant percentage of the global population has adopted bitcoin as their primary store of value (and net worth), which opens up medium of exchange and unit of account properties.
The Exchange Blockspace Demand Paradox
As gateways connecting banking and bitcoin in bootstrapping monetisation, it is also obvious that the predominant demand for Bitcoin blockspace would come from exchanges, and their efficiencies or inefficiencies would affect hugely on blockspace demand and the fee market.

Remember when Bitmex used to batch dump transactions onto the chain as the same time every day?! (source)
The history of Bitcoin exchanges in the fork wars has largely been forgotten, but along with the big miners it was big business that pushed for SegWit 2X that threatened Bitcoin with a contentious hardfork, and had Coinbase and others followed through with implementing the new variation for its huge user base, Bitcoin could have easily been hijacked in 2017 towards a captured centralised inter-exchange settlement network. Thankfully New York Agreement participants realised the coming shitstorm and the likely dilution of their settlement network into competing forks threatening their existence, and the revenues and capital investments backing their continuance as Bitcoin’s dominant players. Exchanges, as essentially the mediators between the legacy fiat money infrastructure and a blossoming new crypto economy with Bitcoin as its monetary base, decided to relent and buckle to core developers and a relatively small band of self custodial users that ran the nodes and the code outside of central custodians, and really the only reason that Bitcoin avoided capture in the fork wars of 2017.
Another by-product of the rise of exchanges, was the relegation of core software upgrades for large amounts of users in the hands of institutions, often downstream in technical development and expertise of core development, and thus slow in many cases to upgrade their own software to benefit from core software upgrades. Indeed, despite exchanges inventing blockspace usage efficiencies such as transaction batching primarily to reduce transsction fees for them, major upgrades to Bitcoin core such as SegWit and Taproot have not been utilised for years by exchanges lacking the expertise or drive to upgrade their software to take all possible advantages of new capabilities, while reducing their blockspace footprint.

Despite being activated in late 2017, SegWit adoption took many years. The surge in adoption in summer 2021 was merely down to Blockchain.com the most popular (web) wallet of Bitcoin’s first decade, finally implementing SegWit transactions (source)
Bitcoin fees mysteriously fell in the second half of 2021 co-inciding with with a mini crash in the price but within the end of cycle blow off top bull market, also co-incided with Blockchain.com’s SegWit imllementation (source)
What goes for SegWit, has also largely been the case for Taproot. Despite being activated in late 2021, nearly four years later P2TR spending addresses are barely a third of transactions.

Exchanges are far downstream of core developers and self custodial node runners who upgrade to the latest core versions of competing implementations, exchanges lag behind sometimes by years in adoption due to a confluence of factors, not only due to inferior developers and coders, but largely due to their conservative nature as custodians of deposits of thousands or even millions of users. It is perfectly understandable that exchanges (and wallet providers) will take their time and extensively test software upgrades prior to any rollout for customers to mitigate against hacks and loss of user funds.
Despite all these flaws, exchanges have been upgrading over the years, taking advantage of core upgrades and techniques such as transaction batching, that has reduced their blockspace footprint, and to today, where despite Bitcoin having a market capitalisation of over TWO TRILLION dollars and an exchange network of hundreds to thousands operating on five continents and in all of the world’s 195 nation states, the chain is largely empty and many within the Bitcoin community are catastrophising the extinction of the self custodial on chain user, and the coming miner death spiral from lack of transaction fees as the block subsidy dwindles, and Bitcoin’s security budget conundrum resurfaces.
Herein lies the exchange blockspace paradox, it is thanks to exchanges and the centralised scale to batch transactions that have increased throughput efficiencies in a way impossible by peer to peer transactions. This has on the one hand allowed Bitcoin to scale to a $2 Trillion asset without permanent chain congestion, while also diminishing or dampening the urgency for soft fork upgrades to increase throughput and capabilities, driving complacency and inertia among factions of the development community, and increasing frustration and exasperation among other factions of the development community who believe that Bitcoin is losing its function and utility as a medium of exchange and stifling the development of Layer Two, as the base chain lies empty and users delegate self custody and their own sovereignty to custodians and centralised exchanges that are more subject to government sanctions and limitations threatening or even extinguishing the independence of Bitcoin as we go forward.
My Take On The Role of Exchanges
As already described, Bitcoin monetisation as an independent store of value and exchange of fiat currencies, was always going to necessitate the development of exchanges as we saw from 2010 onwards. There is no chance that Bitcoin could have attracted the minners, early adopters, developers and competing exchanges to fuel the rise of an alternative decentralised worldwide accounting network absent of this organic evolution. However, it was also clear that the rise of exchanges would also concentrate power to a large extent within these exchanges, as was demonstrated with the fork wars of 2015-2017 wherein exchanges along with miners were the main pushers of big blocks to increase their own profits and power, at the expense of network decentralisation and the power and influence of self custdial users. Thankfully the more egregious extremes of the attempted power grab of exchanges were reined in by the fork wars of 2017, and they were subordinated to the needs and demands of self custodial users and core developers since.
The eight years since has seen the explosion of Bitcoin exchanges all over the world, and has allowed the legacy fiat currency apparatus in the world’s 200 countries to access Bitcoin’s store of value properties, and will as I argued in my Bitcoin Kills Banking Bolt On post allow the whole insolvent government based fiat currency and national bond (debt) markets to underpin their balance sheets with superior and sovereign collateral, as the value of Bitcoin grows it allows the world’s financial systems to slowly swap out of government bonds as collateral and into gold and bitcoin as independent stores of value, that will increasingly diminish and disable governmental ability to borrow and issue debts and destroy countries, while protecting corporations, companies and individuals from the devaluation and impoverishment of collapsing governments worldwide.
I have also argued that ultimately Bitcoin exchanges were only a temporary solution to scaling the Bitcoin network. As Bitcoin started from scratch in a pure fiat cuurency world then exchanges were indispesible in the first two decades of Bitcoins existence, however as Bitcoin grows then so will its functions from purely a store of value into a medium of exchange and unit of account, then so the power of influence of exchanges over Bitcoin will wane and give way to peer to peer exchange as the primary way for newbies to adopt Bitcoin, as extensively discussed in this post via the burgeoning Layer Two gateway. With the development of sidechains, statechains, coinpools, e-cash and NOSTR, the mass adoption of Bitcoin will increasing play out via small transactions, tipping, and peer to peer trade, then so will the utility of exchanges diminish due to their limitations, kyc regulations and limitations of banks they are connected. It will simply be more convenient over time to access Bitcoin via Layer Two than Layer One, and Layer Two is the self custodial replacement for transaction batching and UTXO weaponisation that was facilitated by custodians for its first two decades. This will obviously take time!
Conclusion
At the end of another epically long post that has taken over six months to write, I will confess that my inclination and urgency to write this post has waxed and waned with Bitcoin base chain congestion. A full mempool and high transaction fee costs had inflamed the developer and influencoor communities during the ordinals/inscriptions craze but served the purpose of the consensus gathering required for a soft-fork upgrade herein discussed and drove my desire to write this post and try to lay everything out, while in the first three months of 2025 when the mempool emptied and transaction fees abated, then so did my urgency and appetite for writing this post. Going into the second half of what should be a bull market year in value and price, the mempool is idling on empty and transaction fees at the lowest end in sats per v/Byte, the consensus gathering is also idling as progressive and conservative influences within bitcoin development continue to grapple with the urgency of upgrading the code to weaponise a Layer Two that although exploding in diversity, is being stymied by the current limitations of Bitcoin script. If Ordinals/Inscriptions have taught us anything, it is that situations can change rapidly, that an empty mempool and anaemic fee market can fill up nearly overnight with organic and inorganic demand, and Bitcoin Twatter will once more explode into debating and shitposting the next op-code upgrade to gain sufficient consensus to implement and activate.
As we enter the second half of 2025 we are also seeing nation state entrance into Bitcoin. In my 2019 post I said that following the first decade of retail adoption, Bitcoin’s second decade would see increasing institutional adoption of Bitcoin as store of value, and while still early back then was basically hampered by the Democrat Party’s theft of the 2020 election and subsequent institutional and banking squeeze via the Gensler SEC’s Staff Accounting Bulletin 121 and blatantly documented Operation Chokepoint by the FDIC, dancing to the tunes of Elizabeth Warren and Sherrod Brown. 2024 saw the January waterfall of a dozen ETF’s including behemoths BlackRock and Fidelity, and the Second Coming of Trump that is relaxing and rolling back all the Democrats limitations on the adoption of Bitcoin by the world’s reserve currency and beating heart of the EuroDollar worldwide shadow banking network. While Bitcoin has already been adopted to varying degrees as a store of value and being mined at the nation state level by a handful of countries in the developing world, 2024 was the year when the bigger guns started to indicate that they were too getting into Bitcoin, whether by a strategic reserve, mining using state electricity, or as a trade settlement mechanism. With Donald Trump’s election and explicit embrace of Bitcoin for one of three great Powers, 2025 has seen the disclosure by the two other Great Powers in China and Russia of using Bitcoin to bypass US sanctions in trade settlement, while regional moves are being made by governments in South America (El Salvador, Paraguay, Panama, Argentina), The Middle East (Oman, United Arab Emirates, Saudi Arabia), and in Europe. In effect Bitcoin is being adopted ar the State level worldwide and thus is morphing to state level scale, that will bring with it an increased demand for on-chain settlement.
While it is possible and probable that Exchanges will continue to improve their software and utilise Bitcoin’s latest Taproot capabilities to upgrade their settlement of batched transactions even further, I doubt that this will be enough to keep the mempool empty, and surely nation state adoption and increasing use of competing geopolitical blocks to use Bitcoin for direct trade settlement undermining the Dollar as world reserve currency, and others scope as international currencies, will start the process of persistent block space demand. Only a persistent and sometimes acute demand for blockspace will force Bitcoin development to find consensus and code the next soft-fork scripting upgrade that gives Layer Two developers the output introspection to scale an UTXO to more self custodial users, and disappear off chain into a peer to peer economy of instant low cost transactions by-passing kyc/aml regulations and taxation, and starving governments of their tax revenues. The future of Bitcoin’s growth and development will continue to revolve around the costs of moving UTXO’s.
“The institutional splurging of fiat into Bitcoin’s store of value properties will be fuel for Bitcoin adoption on the medium of exchange level, almost like two parallel but completely different use cases and economies, and which leaves us intriguingly with the last of the trinity of the functions of currency, the unit of account… It should be clear here that Bitcoin will be valued differently at the store of value layer and the medium of exchange layer, and why this is most definitely in Bitcoin’s long term interest; when purchasing at exchanges Bitcoin as a store of value is denominated in bitcoins, one individual unit out of a market cap of 21,000,000, and today exchanges in the thousands and in the future will trade at magnitudes higher, while on Lightning and the medium of exchange layer bitcoin is denominated in satoshis and a sub-division of a single unit (there are 100,000,000, or one hundred million satoshis in one bitcoin), for example 10,000 satoshis is £0.30, 100,000 satoshis is £3.00, 1,000,000 satoshis is £30.00, 10,000,000 satoshis is £300, (0.1 bitcoin) and 100,000,000 is £3,000.00 for one bitcoin… This sub-division of bitcoin into satoshis coupled with increasing adoption of Bitcoin as a medium of exchange for future newbies, kills to a large extent the underlying retail exchange layer and the speculative competition of shitcoins spawned in large part because newbies often do not understand that you can buy fractions of a bitcoin instead of one whole, and others who pile into fraudulent scamcoins because their however many billion in market cap trades for pennies, therefore it is cheaper with more upside than Bitcoin that is very expensive, and has largely contributed to shitcoin rallies during bull markets and just creates general confusion for an uneducated public in evaluating a totally misunderstood technology, they are hypnotised by price… While prices quoted for Bitcoin will remain for the forseeable future on exchanges and in the media (both legacy and social) will be per bitcoin, I contend that newbies first contact with bitcoin will increasingly be in satoshis, through purchases, tips or micro-transactions, and a far more scalable sub-division for bitcoin used as medium of exchange, and transforms the psychology of mental calculation toward transactions and barter exchange.” – Annrhefn, Bitcoin Kills Banking Redux, February 2019.
Bitcoin Donations Gratefully Received:
bc1q49a3y9anq3a2pjqvq3gm8wj8aqqld3pnva9phwna2ftdar73mf3qak275j
