Brink, the Bitcoin development organization, recently funded the first ever independent security audit of Bitcoin Core conducted by a third party (the full report is available here). The audit was conducted by Quarkslab, a software security firm, with the help of the Open Source Technology Improvement Fund (OSTIF) and collaboration with Bitcoin Core developers Niklas Gögge, from Brink, and Antoine Poinsot, from Chaincode Labs.
This security audit marks a milestone in the development history of Bitcoin Core, the most widely adopted and reference client of the Bitcoin network and protocol.
While Bitcoin Core security policies and practices have been steadily hardened and revised to be more thorough and comprehensive over the last few years, an external audit by a third party specialized in security review is a new bar to meet. It was met.
The audit involved manual code review, static and dynamic analysis with automated tools, and advanced fuzz testing, which takes automatically generated input and runs it through different code paths attempting to reveal unexpected or detrimental behavior.
No critical, high, or medium-severity bugs were discovered in the audit. Two low-severity issues were different, and thirteen other issues that are not classified as vulnerabilities under Bitcoin Core’s vulnerability classification criteria.
The entire process also resulted in improvements in Bitcoin Core’s testing infrastructure, including new fuzz testing infrastructure for block connection and chain reorganization scenarios, a new area to be covered by testing, file system improvements speeding up and improving fuzz testing in general, new utilities for testing back sliding code performance, and suggestions for improving code readability for reviewers and new developers.
Some of these improvements are already being worked on for eventual review and merging into the Bitcoin Core repository.
The results of this independent security audit have reinforced that Bitcoin Core’s improvements over recent years in security policy, testing, and overall quality review have had a meaningful impact on the project.
In computing, a denial-of-service attack (DoS attack; UK: /dɒs/ doss US: /dɑːs/ daas[1]) is a cyberattack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to a network. -The Wikipedia definition of denial-of-service attack.
This is a very basic concept. Someone makes use of their own resources to disrupt the functioning of other machines on a network.
DoS attacks have been an issue for as long as the internet existed. One of the commonly argued “first Distributed Denial-of-service (DDoS) attacks” was against the Internet Service Provider (ISP) Panix in the mid-90s. There were of course many prior technical examples on older internet services, but this was one of, if not the, first major examples of such an attack on the modern World Wide Web.
This attack had numerous computers start to initiate a Transmission Control Protocol (TCP) connection with the ISPs servers, but never finishing the handshake protocol that finalized the connection. This consumes the server’s resources for managing network connections and prevents honest users from accessing the internet through the ISP’s servers.
Ever since this “initial” DDoS attack, they have been as common on the internet as storms are in nature, a regular occurrence that massive pieces of internet infrastructure have been built to defend against.
The Blockchain
The blockchain is one of the core components of Bitcoin, and a required dependency for Bitcoin’s functionality as a distributed ledger. I am sure many people in this space would call so-called “spam” transactions a DoS attack on the Bitcoin blockchain. In order to call it that, you would have to define the “service” that the blockchain is offering as a system, and explain how spam transactions are denying that service to others in a way not intended by the design of the system.
I’d wager a bet that most people who believe spam is a DoS attack would say something like “the service the blockchain offers is processing financial transactions, and spam takes space away from people trying to do that.” The problem is, that is not specifically the service the blockchain offers.
The service it actually offers is the confirmation of any consensus valid transaction through a real-time auction that periodically settles whenever a miner finds a block. If your transaction is consensus valid, and you have bid a high enough fee for a miner to include your transaction in a block, you are using the service the blockchain provides exactly as designed.
This was a conscious design decision made over years during the “Block Size Wars” and finalized in the activation of Segregated Witness and the rejection of the Segwit2x blocksize increase through a hard fork pushed by major companies at the time. The blockchain would function by prioritizing the highest bidding fee transactions, and users would be free to compete in that auction. This is how blockspace would be allocated, with a global restriction to protect verifiability and a free market pricing mechanism.
Nothing about a transaction some arbitrarily define as “spam” winning in this open auction is a DoS of the blockchain. It is a user making use of that resource in the way they are supposed to, participating in the auction with everyone else.
The Relay Network
Many, if not most, Bitcoin nodes offer transaction relay as a service to the rest of the network. If you broadcast your transactions to your peers on the network, they will forward them on to their peers, and so on. Because the peering logic deciding which nodes to peer with maintains wide connectivity, this service allows transactions to propagate across the network very quickly, and specifically allows them to propagate to all mining nodes.
Another service is block relay, propagating valid blocks as they are found in the same manner. This has been highly optimized over the years, to the point where most of the time an entire block is never actually relayed, just a shorthand “sketch” of the blockheader and the transactions included in it so you can reconstruct them from your own mempool. In other words, optimizations in block relay depend on a transaction relay functioning properly and propagating all valid and likely to be mined transactions.
When nodes do not have transactions in a block already in their mempool, they must request them from neighboring nodes, taking more time to validate the block in the process. They also explicitly forward those transactions along with the block sketch to other peers in case they are missing them, wasting bandwidth. The more nodes filtering transactions they classify as spam, the longer it takes blocks including those filtered transactions to propagate across the network.
Transaction filtering actively seeks to disrupt both of these services, in the case of transaction relay failing miserably to prevent them from propagating to miners, and in the case of block propagation having a marginal but noticeable performance degradation the more nodes on the network are filtering transactions.
These node policies have the explicit purpose of degrading the network service of propagating transactions to miners and the rest of the network, and view the degradation of block propagation as a penalty to miners who choose to include valid transactions they are filtering. They seek to create a degradation of service as a goal, and view the degradation of another service resulting from that attempt as a positive.
This actually is a DoS attack, in that it actually is degrading a network service contrary to the design of the system.
Where From Here?
The entire saga of Knotz vs. Core, or “Spammers” vs. “Filterers”, has been nothing more than a miserably ineffective and failed DoS attack on the Bitcoin network. Filters do absolutely nothing to prevent filtered transactions from being included in blocks. The goal of disrupting transaction propagation to miners has had no success whatsoever, and the degradation of block relay has been marginal enough to not be a disincentive to miners.
I see this as a huge demonstration of Bitcoin’s robustness and resilience against attempted censorship and disruption on the level of the Bitcoin Network itself.
So now what?
A BIP by an anonymous author has been put forward to enact a temporary softfork that would expire after roughly a year making numerous ways to include “spam” in Bitcoin transactions consensus invalid through that time period. After realizing the DoS attack on the peer-to-peer network has been a total failure, filter supporters have moved to consensus changes, as many of them were told would be necessary over two years ago.
Will this actually solve the problem? No, it won’t. It will simply force people who wish to submit “spam” to this forked network, if they actually follow through on implementing it, to use fake ScriptPubKeys to encode their data in unspendable outputs that will bloat the UTXO set.
So even if this fork was met with resounding support, activated successfully, and did not result in a chainsplit, it would still not achieve the stated goal and leave “spammers” no option but to “spam” in the most damaging way to the network possible.
In my quest to find the best solution for Cake Wallet to offer user-friendly, non-custodial Lightning to our users, I’ve gone deep down the rabbit hole of both Spark and Ark. Both are quite novel approaches to Bitcoin layer two networks, and are designed at their core to be interoperable with the broader Bitcoin network for payments via the Lightning Network. While both can be used “just” for Lightning payments, both networks are positioned to rapidly expand and be used for far more than that over the coming months and years.
One thing to keep in mind is that while Spark and Ark on their face seem rather similar, in practice and in implementation they are quite distinct.
Why do we need new layer twos?
Bitcoin at its core is an incredible tool for freedom, but due to block size constraints, we know that the majority of the world will never be able to make transactions on-chain. Enter Lightning, a solution that allows one on-chain transaction to allow for essentially infinite off-chain transactions, expanding the usefulness of Bitcoin’s base layer and making it possible for more people to transact.
While Lightning provided a promising approach to scaling Bitcoin payments, ultimately the realization that its best role is as an interoperability layer and not as a tool for end-users to run themselves has become clear. On-chain requirements, liquidity management, liveness requirements, and other core hurdles make the implementation of user-friendly, self-custodial Lightning next to impossible. This has become apparent as most Lightning wallets and use-cases have opted to use custodial or federated models out of a need to simplify the user experience and the implementation difficulty.
The biggest win that Spark and Ark provide to the Bitcoin space out of the gate is providing a much simpler and easier way for the average developer to provide Lightning to their users, while allowing for greatly expanded functionality down the line beyond Lightning payments.
Ark, simplified
History
The concept of Ark was created in May of 2023 by Burak, a Lightning advocate and developer. The driving force behind its creation was the realization that the Lightning network as constructed was not effective as an onboarding tool for the average individual due to inbound liquidity requirements among many other things, and that privacy was often lacking. While Burak invented the protocol itself, two companies – Ark Labs and Second – have stepped in to build the Ark protocol into an end-to-end layer-two network for Bitcoin.
While both companies are building around the same open-source Ark protocol, their implementations and objectives are rather dissimilar. As a result, I’ll do my best to distill both below where possible.
Terminology
Ark: Ark is a protocol for moving Bitcoin transactions off-chain by leveraging multisig and pre-signed transactions between users and the Ark Operator. Anything you can do on Bitcoin, you can do on Ark but faster and with lower fees.
Ark Operator: The entity running the centralized Ark server infrastructure and responsible for providing liquidity for user’s VTXOs before expiry.
Lightning Gateway: The entity that provides the ability for Ark users to send or receive Lightning payments using trustless atomic swaps of Ark VTXOs. This function can be provided by the same entity as the Ark Operator, but is often distinct to spread out counter-party risk.
Virtual Transaction Outputs: Also called “VTXOs”, these are very similar to on-chain UTXOs in nature, but are virtual as they aren’t represented as unique UTXOs on-chain and live entirely off-chain. Users send and receive VTXOs within Ark.
Rounds: In order to gain true finality and/or refresh VTXOs, Ark users will need to join rounds, where they work together with other Ark users and the Ark Operator to get new VTXOs in exchange for a fee.
Making transactions
Ark functions very similarly to on-chain Bitcoin transactions, and inherits many of the same mannerisms while allowing transactions to be near-instant and trust-minimized between Ark participants. The sender works with the Ark Operator to sign the VTXO over to the recipient, or in the case of Ark Labs to create a new, chained VTXO for the recipient. This allows a user-experience similar in many ways to on-chain payments, but with far lower fees and far faster transaction times. When the user wants to send or receive Lightning payments, they can work with a Lightning Gateway to atomically swap VTXOs for Lightning payments as-needed. At the moment no offline receive for Lightning payments in Ark is possible, but it’s likely this will be solved in a similarly trust-minimized way within Ark as it is in Spark.
If the user desires finality (i.e. they’ve received a large payment), they can choose to join a round to finalize the payment and gain the same finality assumptions as on-chain Bitcoin. The frequency of this round process will vary by Ark Operator – with estimates ranging from every 10min to every hour – and requires a relatively lengthy coordinated signing process between all users seeking to join the round with the Ark Operator. The round frequency can even vary based on demand, and is not something that has to be set in stone to a single frequency unlike Bitcoin block times.
As Ark inherits Bitcoin scripting and the UTXO model directly from on-chain Bitcoin, Ark will likely be extended to support token protocols like Taproot Assets in the future.
Trust tradeoffs
Ark targets a very trust-minimized approach to scaling Bitcoin, striking something of a middle-ground in terms of usability and tradeoffs between Lightning and Spark. Note that Ark as a protocol is rapidly developing, and some of these tradeoffs will hopefully be solved through the use of novel off-chain methods or after the implementation of covenants in Bitcoin.
Lack of out-of-round finality
While Spark lacks provable finality, Ark strikes something of a middle ground. For small payments, users can rely on the Ark Operator and previous senders to not collude for security, allowing for instant transfers with no need for collaborative signing rounds. Note that by default, payments within Ark will be “out-of-round” payments that lack true finality, a tradeoff that allows Ark to deliver a good user experience out of the box.
That being said, users who do need or want true finality can have it by joining a round and receiving a new VTXO from the Ark Operator. Receivers are essentially in control of their preferred trust model.
VTXO expiration
As a result of the liquidity requirements to operate an Ark instance, Ark Operators need a way to reclaim liquidity regularly. To allow this liquidity reclamation, Ark VTXOs will expire regularly (i.e. after 30d, with the VTXO expiry being set by each Ark Operator), requiring their owners to either join a round to refresh the VTXO or risk giving up control of their funds entirely to the Ark Operator. While the Ark Operator has strong incentives to merely issue a new VTXO to the owner of the expired one when they come back online, both the Ark Operator and the user will have the ability to spend funds until a new VTXO is issued to the user.
To avoid funds expiring, users will be required to refresh their VTXOs within that window either directly or by offloading refresh to a delegate. Alternatively, atomic swaps of an expiring VTXO for one with a longer lifecycle could be done with an entity like Boltz for a fee, but that is not yet implemented.
Complex round user experience
If you’ve ever used Coinjoin on Bitcoin, you know how tedious and unreliable collaboratively signing a transaction with other Bitcoiners can be. In Ark, those seeking true finality for their VTXOs will need to be available throughout a round signing process until its completion, something that will depend heavily on other participants properly completing the signing process. While this is quite trivial to accomplish for a wallet running on an always-online server, it’s rather complex to reliably perform on mobile platforms, especially iOS where no background execution (and thus no ability to be online at the right time for signing) can be guaranteed for any app.
As a result of this complex user experience, Ark Labs have come up with a system that leverages delegated third parties performing the refresh in a trust-minimized way for users, offloading the liveliness requirement to a third party. While this third party has no ability to steal funds, if they are offline for any reason or refuse to refresh a given VTXO, the user will be forced to join a round themselves before the expiry period. To mitigate this risk, users can designate multiple delegates, shifting the trust assumptions for expiry to a 1-of-N assumption, where if any delegate is honest their VTXO will be refreshed properly.
Second also have a similarly designed system that enables trustless, non-interactive rounds for users, allowing any number of parties to sign for a user during a round (i.e. the wallet provider and a third-party delegate) where if any of those parties signs properly, the users VTXO is properly refreshed.
Note that while these two solutions can refresh expiring VTXOs, they cannot give users true finality without the user actively participating in the round themselves.
Lastly, it’s important to call out that the vast majority of complexity with the round process can be entirely mitigated if a simple covenant is deployed in an upgrade to Bitcoin, something that would unlock a vastly improved user experience for Ark.
Privacy tradeoffs
At its core, Ark inherits Bitcoin’s poor privacy and doesn’t provide any notable privacy improvements as a protocol. That being said, its ability to offload execution off-chain and expand Bitcoin’s functionality allows existing and novel privacy protocols to be built on top of it in the future, with covenants fully unlocking things like private rounds within Ark.
In the short-term, Ark Labs have planned to use WabiSabi-like blinded credentials to improve privacy from the operator when users participate in rounds.
Transaction visibility
While all transactions within Ark don’t need to be published on-chain, providing some loose ephemerality, all transaction details are visible to the Ark Operator and shouldn’t be considered private in the truest sense. Instead, viewing the ephemeral privacy provided by Ark as analogous to the VPN model (offloading visibility into transactions from the Bitcoin blockchain to a trusted third-party) is a useful mental model.
It’s unclear at this time if Ark Labs and Second will keep transaction data private or publish it publicly, but as with a VPN users should not rely entirely on a promise to not log for their privacy.
The Spark network was launched earlier this year by the folks at Lightspark, a Bitcoin-adjacent company with an interesting history. From UMA (a username system with natively integrated compliance features for their banking partners) to connections with the failed Libra currency, they have an odd track record of building tools that aren’t quite up to par with Bitcoin’s more cypherpunk roots. But, when I put aside their odd track record and focused purely on what Spark the protocol actually is, it presents a rather useful, pragmatic, and powerful tool overall.
Spark at its core takes a lot of the useful features of statechains, a novel approach to layer twos on Bitcoin created by Ruben Somsen in 2018. Spark specifically extends statechains with the idea of “leaves”, allowing users to send any amount in a transaction instead of being solely able to transact with whole UTXOs, one of the biggest issues with statechains up to this point.
Terminology
Spark Entity: the entity running a given Spark instance, i.e. Lightspark, made up of a collection of Spark Operators. As Spark is an open-source protocol, anyone can start their own Spark Entity, but each Spark Entity controls which Spark Operators can join.
Spark Operator: each Spark Entity is composed of one or more Spark Operators, each of which are responsible for validating and signing operations of users within the Spark instance, including transfers of funds and tokens, issuance of new tokens, etc. These can be the same entity as the Spark Entity, or (hopefully) distinct in relationship and jurisdiction from the Spark Entity. Currently the two Operators for Spark are Lightspark themselves and Flashnet, but more are slated to be added in the near future.
Spark Service Provider: an entity that provides various services to Spark users, including using atomic swaps to trustlessly send and receive Lightning payments on the users behalf.
Spark leaves: Spark solves the issues around whole-coin transfer requirements in statechains with the introduction of leaves. These can be thought of similarly to UTXOs within Bitcoin, as they can be freely broken up into any size necessary.
Making transactions
At its core, Spark functions by allowing users to easily move Bitcoin around the Spark network near-instantly by working in a trust-minimized way with Spark Operators to transfer ownership of individual leaves to another person. There is no need for a blockchain, confirmations, or liveness between sender and receiver, making payments simple and very fast. When a user wants to make a payment on Lightning, they atomically swap a leaf or leaves from their wallet with a Spark Service Provider who then sends the payment trustlessly on their behalf for a fee.
To transfer a Spark leaf, the sender co-signs ownership of the leaf over from themselves + Spark Operators to the new owner + Spark Operators. This is done in such a way that if any of the Spark Operators or previous owner honestly deletes their keyshare used in the co-signing operation, the leaf is then solely owned by the recipient and no double-spend is possible. As this operation only requires collaboration between the Spark Operators and sender and not any other Spark users, these signing rounds are very fast and resistant to DoS attacks.
Spark also includes a similar 1-of-N trust model to do offline receive for Lightning payments, a key user-experience improvement over standard Lightning wallet usage. This is especially important when using Spark on a mobile wallet, as mobile platforms cannot guarantee background execution or perfect network access 24/7.
In addition to regular payments, Spark has extended the idea to include native token support, with the core focus being on stablecoins like USDT and USDC able to be issued and transferred seamlessly within the Spark network. Tokens transfers themselves share a similar trust model to standard transactions on Spark, and retain the ability to unilaterally exit on-chain.
Lastly, users in Spark can unilaterally exit on-chain at any time by publishing a pre-signed exit transaction on-chain. While the cost of exiting can vary widely due to variables like leaf depth and on-chain fee rates, likely pricing out smaller amounts, it’s a critical tool to ensure that funds can be retrieved in the event of a malicious or unavailable Spark Entity.
Trust tradeoffs
Spark makes a very pragmatic set of tradeoffs that compliment the current issues befalling Lightning and Bitcoin usage today. That being said, there are some major differences with Spark compared to on-chain Bitcoin or Lightning usage. I prefer to use the term “trust-minimized” when talking about Spark (and most other layer two networks) as only self-custody of Bitcoin on-chain can truly be viewed as “trustless”.
Lack of true finality
The core risk to self-sovereignty in Spark is the lack of true finality, where users can never know for sure that their funds cannot be double-spent through collusion between the Spark Operators and a previous spender. Within Spark, finality (knowing that your funds can only be moved with your keys) exists – but is not provable – on the condition that any single Spark Operator deletes their keyshare after signing off on a Spark transaction. On the flip side, if all Spark Operators are malicious and refuse to delete their keyshare and collude with a previous sender of a leaf you own they can double-spend that leaf and effectively steal funds.
While in practice I think this 1-of-N trust assumption is reasonable, it obviously falls far short of the regular, on-chain Bitcoin trust assumptions where true finality is a default. It’s also important to note that due to the pseudonymous nature of Spark transactions, the previous sender could be the same entity as the Spark Entity.
Potentially centralized token control
While transfers of tokens themselves share the 1-of-N trust assumption of regular Spark payments, the tokens themselves can be frozen at any time if the issuer decides to enable this functionality. While this is similar to many centrally controlled stablecoins like USDT (who freeze and confiscate Tether quite often for legal reasons), it’s important to callout and will likely be enabled in many regulated stablecoins like USDC and USDT.
1-of-N offline Lightning receive security
While offline Lightning receives are not trust-minimized in the same way standard Lightning payments are, theft of funds would require all Spark Operators to collude to steal a single Lightning payment, something that is disincentivized due to the small size of Lightning payments and the massive reputational risk if caught stealing from users, something that is easy to detect due to the inherent proof of payment in the Lightning network.
Privacy tradeoffs
Spark itself should not be viewed as a privacy tool, as it inherits core privacy problems from Bitcoin’s base layer and has made some poor design choices initially when it comes to privacy. That being said, Spark’s core technology could be extended to have fantastic privacy with the introduction of blind signing for all transactions, confidential amounts for token transfers, and other privacy technologies that aren’t normally possible within the Bitcoin ecosystem.
Transaction visibility
While transactions within Spark aren’t published for all time to a blockchain like on-chain transactions, all Spark Operators do get full visibility into transactions. In theory this could provide ephemerality if Spark Operators had a non-logging policy, but in practice all transaction data is currently being published to an explorer by Flashnet, one of the Spark Operators. This means that outside observers can trivially look up Spark addresses and see all transaction details, token balances, and even link Lightning payments to addresses using timing and amount analysis.
Note that Spark is working to add the ability for wallet developers to opt-out of this data publishing by marking transactions as private, which then falls back to the same VPN-like trust model as previously described for Ark. If a wallet developer opts to enable this (as I hope they all will!), the Spark Operators will promise not to publish this transaction data publicly, but of course still have the ability to store this data locally if they so choose.
Lack of address rotation
In its current form, Spark doesn’t support spending funds from multiple distinct Spark addresses in a single transaction. While this is slated to be fixed and already acknowledged as a key shortcoming of Spark, at present it means that most Spark implementations will rely on a single, static address for all transactions, making Spark’s privacy at the moment worse than even on-chain Bitcoin. Combining this address re-use with all amounts being visible means that it would be trivial for an attacker to perform timing + amount heuristics on payments to ascertain which Lightning payments pertain to which Spark addresses.
Spark address leaks
To complete the trifecta of current privacy problems in Spark, the core SDKs provided by Spark (and used by the most common implementation of Spark in Wallet of Satoshi) by default include the user’s Spark address unnecessarily in BOLT 11 Lightning invoices. This means that anyone can easily decode a provided BOLT 11 invoice and learn every transaction from that user in Spark, thanks to the use of static addresses and all details being published to an explorer as detailed above.
Note that this isn’t absolutely necessary, can easily be disabled by wallet developers, and is already removed in the Breez Nodeless SDK that utilizes Spark and is rapidly gaining adoption but is important to callout nonetheless.
While both Spark and Ark present an exciting new time in the world of Bitcoin usability and scalability, as with all things they come with their own unique sets of tradeoffs. While neither is a perfect solution, it’s exciting that wallet developers finally have two competing and interesting options to solve the implementation of Lightning, native tokens, and other functionality into their wallets and software without the complexity traditionally associated with Lightning. Both Spark and Ark present a pragmatic outcome for scaling Bitcoin, representing a hard but sane path to do things in a way that balances trust-minimization with user-experience and scaling.
As both are rapidly evolving protocols, the hope is that the tradeoffs presented by both solutions will be rapidly improved upon and minimized in the coming months and years, providing an even better option that gets non-custodial Bitcoin into the hands of many more people while extending the things that we can build on top of Bitcoin.
A special thank you to the folks at Spark, Ark Labs, Second, Breez, Spiral, and Bitcoin QnA for taking the time to provide feedback on this article! It takes a tribe to work out all of the trust assumptions and tradeoffs of these novel systems, and I’m extremely grateful to each for taking out some of their valuable time to help here.
This is a guest post by Seth For Privacy Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
What is Bitcoin and who is it for? There are a plethora of catchphrases available on Twitter to cover this one. Bitcoin is for everyone… no wait, it’s for anyone! Bitcoin is a store of value. Bitcoin is a medium of exchange. We could do a classic appeal to authority and declare that Bitcoin is exactly what Satoshi described, “A Peer-to-Peer Electronic Cash System”.
Bitcoin becomes what we make it. It serves the people we choose to build for. If we want Bitcoin to be a store of value or medium of exchange, we have to build the protocols and services that make this happen.
Sometimes it’s more interesting to ask specifically, who are we building for? Are we building for Americans looking for a long-term investment? Are we building for a shop owner in Brazil? A reseller in Turkey? A software developer in Nigeria?
If we want bitcoin to be a medium of exchange, we need to focus on the users who need it most — and Taproot Assets is the tool for that job.
Taproot Assets
Taproot Assets allows us to take the assets, and units of account, that people want and need today as mediums of exchange — and move them to Bitcoin infrastructure on the Lightning Network.
From a technical perspective, Taproot Assets is a protocol that allows for the minting of assets on the Bitcoin blockchain in a very blockspace-efficient fashion using taproot transactions, made possible by the November 2021 Taproot soft fork activation. Client-side validation is used, the protocol is opt-in, and no consensus changes are required. Fungible assets are exchangeable on the Lightning Network, and you can use this protocol on mainnet today!
Taproot Assets is a flexible protocol that’s already opening the door to a wide variety of use cases, but the core use case is stablecoins on Lightning.
For those wanting to learn more, here are the docs, and tutorial and demo videos can be found here.
So, why is this such a powerful tool for adoption?
Meet People Where They Are
It’s easy to get immersed in the Bitcoin world — where we use bitcoin, talk about it constantly, and dive deep into all the things it fixes. That passion and curiosity is powerful. But the real magic happens when we connect that world to people outside it.
Most people don’t have the time available to study monetary theory or economic history. Free time and disposable income are not the norm in the world. Stay humble. If we want Bitcoin to serve the world, let’s meet people where they are. And we can: We have the tools and the skills to build things that are truly useful — products that people love not because they’re Bitcoin-powered, but because they solve real problems.
Adoption won’t come just from our impressive understanding of Austrian economics, it will come from building things that are so useful people can’t help using them. The true measure is in the utility. The true measure is in the users. Number of people go up!
Stablecoins
And so let’s talk about stablecoins. Love them or question them, stablecoins have clearly found product-market fit. The invisible hand has spoken!
Let’s look at some numbers:
In Brazil, approximately 90% of crypto transactions are tied to stablecoins, primarily for payments and remittances.
Tether estimates it has 434 million users worldwide, transacting $31 billion USDT daily. About 13% of the total USDT supply is held by savers who are likely emerging markets users without other access to dollars.
Tether (USDT) has a market cap of $153 billion and recorded over $10 trillion in total volume in 2024. USD Coin (USDC) follows with a $61 billion market cap. (Numbers from CoinGecko at time of writing.)
Utility
Why have the people chosen stablecoins? Utility.
Most people around the world don’t have the luxury to HODL through a bear market. Most humans don’t ponder the intricacies of fractional reserve banking. They’re busy living — busy being fathers, and mothers, and small business owners, and doctors, and carpenters, and farmers, teachers, and students. All the things that keep the world turning.
Most people are simply seeking an improvement in their day-to-day lives, and it’s our job, as experts on money, to give them what they need.
They need stability and affordability.
Infrastructure Adoption
As the Bitcoin adoption story goes, first we achieve store of value, then medium of exchange, and then unit of account — the final boss! But if we facilitate stablecoins, are we preventing bitcoin from achieving unit of account? No. Bitcoin will be a unit of account if and when the world needs it to, if and when we make it available.
Those choosing to use a stablecoin on the Lightning Network will be doing so because it is the best option for them; it’s the option that brings the most utility. They aren’t thinking about “adopting Bitcoin”, and they don’t intend to adopt bitcoin, the unit of account. But they will be adopting Bitcoin, the network. They will be adopting Bitcoin, the payments infrastructure.
We often think of replacing the Visa network and to do that we have to be more useful than Visa, which processes transactions in 175 different currencies.
Our Turkish reseller is an expert in what he does, and not an expert on decentralized networking technology. He’ll choose Lightning over Visa when it becomes the better, more affordable, easier option for running his business. And for many businesses, Lightning already is the faster, more affordable option.
Let’s imagine that precoiner shop owner in Brazil. She’s managing her business making transactions using a stablecoin via a Taproot Assets Lightning wallet. She’s made the switch to Bitcoin infrastructure. She was enticed to do so by a simple, easy-to-use mobile wallet that simplified her business, cut her costs, and reduced her risk. This wallet allows her to make instantly settled, global, incredibly affordable transactions, and to do so in a wide variety of currencies. She came for the utility of this medium of exchange, but is now one button away from losing her precoiner status.
And, should that global fiat money collapse finally arrive one random Tuesday afternoon, she just needs to push that button to switch out of fiat and into sats because she is already running on Bitcoin infrastructure.
A Multi-Asset Network
The potential and utility of a Taproot Assets-enabled, multi-asset Lightning Network is grossly underappreciated. Seriously: It’s a medium of exchange like the world has never seen before.
Application builders and their users can have any unit of account that they like — U.S. dollars, Brazilian reais, euros, etc. — and it’s all routed through Bitcoin. Taproot Assets Lightning transactions require Bitcoin liquidity. These transactions support and grow the Lightning Network and enable a plethora of options. A payment can be sent out by Alice in USD, but Bob can receive BTC. Alice can send another payment in USD that will be routed through the Lightning Network, through the sats-denominated liquidity in the center of the Lightning Network, on to Carol who opts to receive a euro-denominated stablecoin.
Our Turkish reseller can sell goods to our Brazilian shop owner using a stablecoin. Not only can he interact with businesses around the world without friction, but also any regular Bitcoiner can transact with either using sats, seamlessly. No need to touch that stablecoin if they don’t want to.
And it gets even cooler. Let’s imagine for a moment this scenario…
A global, scalable, instantly settled payment network that’s meaningfully cheaper than Visa — a payment network that now gives users the option to transact in whatever coin they prefer. This is the brilliance of building with Bitcoin as infrastructure — people adopt the network before they even know it’s Bitcoin.
Conclusion
If we want to see Bitcoin as a medium of exchange, if this is what we are building for, it’s our job as the experts to give the people what they are clearly telling us that they need: instant, low-fee, stable-value transactions. In other words, multi-asset Lightning.
Now, of course Taproot Assets is a versatile protocol. It can and will be used for all sorts of things — including use cases that appeal to the American crowd who see bitcoin primarily as a long-term investment. Yay, permissionless innovation! With this protocol, we’re helping usher Bitcoin in its medium of exchange era.
This piece is an article featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here to show the ideas explored throughout the full issue.
Login
