"Get on zero" has emerged as a powerful mantra among bitcoiners, urging people to convert their entire wealth into bitcoin. However, this approach overlooks a fundamental challenge: fiat-denominated liabilities still exist on our balance sheets.

This article explores the asset mismatch problem that arises from striving for "zero fiat." It explains why such a strategy is irresponsible and counter to Bitcoin's founding ethos, as it ultimately replicates 0% reserve banking at the individual level.

The Asset Mismatch Challenge

To get on zero fiat, individuals convert all of their wealth into bitcoin and either pay their bills directly in bitcoin or convert their bitcoin to fiat currencies when their liabilities are due. The idea is that it is financially more profitable and accelerates adoption since we expect bitcoin will ultimately appreciate against fiat currencies as it has done in the past.

The challenge with this approach is that it ignores that most people have liabilities denominated in their local fiat currency, such as taxes, housing costs, and other living expenses. In other words, getting on zero fiat is impossible because we all have liabilities denominated in fiat. For a bitcoiner "on zero," this creates a balance sheet with mismatched assets and liabilities whose units of account are wildly volatile vs. each other.

The Risks of Asset Mismatch

This asset mismatch poses a significant risk due to the short-term volatility of bitcoin's price compared to fiat currencies. In times of unfavorable exchange rates or sudden price drops, bitcoiners on zero fiat may face difficulty meeting their fiat-denominated liabilities. These situations can lead to the forced liquidation of their bitcoin holdings, potentially at a loss, and even result in insolvency.

Determining the Appropriate Amount of Fiat Holdings

To mitigate the risks associated with asset mismatch, individuals should determine how much fiat currency they need to cover their near-term liabilities. A general rule of thumb is to hold enough fiat assets to cover at least six months to two years of anticipated expenses, depending on individual circumstances and risk tolerance.

Factors to consider when deciding on the appropriate amount of fiat holdings include:

• Stability of income: Those with stable and predictable income sources may feel comfortable holding a smaller fiat reserve, while those with irregular income may benefit from a larger safety net.
• Access to credit: Individuals with access to credit or other financial resources may require a smaller fiat reserve, as they can tap into these sources if needed.
• Personal risk tolerance: Some individuals may have bigger stacks and be more comfortable with the risks of near-term asset mismatches. In contrast, others may prefer a more conservative approach to protect their nest egg.

Example Scenarios

Consider an individual who has decided to hold 12 months' living expenses in fiat currency based on their circumstances and risk tolerance.

Their balance sheet might look like this:

Assets:

• Bitcoin: 6.15 BTC
• USD Savings: $50,000

Liabilities (annual):

• Rent/mortgage (USD): $30,000
• Groceries (USD): $6,000
• Utilities (USD): $3,000
• Taxes (USD): $12,000
• Total liabilities (USD): $51,000

In this scenario, the individual has allocated a portion of their wealth to fiat currency, allowing them to cover their anticipated liabilities for the next 12 months. If they have income in the meantime, they can first use it to pay for the expenses while retaining their 12-month buffer and stack sats with any income above their expenses. This approach provides a buffer against short-term market volatility and ensures they can meet their financial obligations without liquidating their bitcoin holdings.

Now consider another individual with higher risk tolerance and access to credit might decide to hold only six months' worth of living expenses in fiat currency.

Their balance sheet might look like this:

Assets:

• Bitcoin: 8.15 BTC
• USD Savings: $25,000

Liabilities (annual):

• Rent/mortgage (USD): $30,000
• Groceries (USD): $6,000
• Utilities (USD): $3,000
• Taxes (USD): $12,000
• Total liabilities (USD): $51,000

In this case, the individual has chosen to allocate a smaller portion of their wealth to fiat currency based on their personal risk tolerance and access to credit. While this approach may expose them to greater short-term risk, they may have determined that they are comfortable with this level of exposure.

If bitcoin's price appreciates during that year, the individual holding more fiat will lose out on additional bitcoin they could have stacked. Conversely, if the individual lost their income, didn't have access to cheap credit, and bitcoin's price cratered to new lows, they would risk losing most if not all of their stack over a short time.

Recall the shock to bitcoin's price during March 2020, corresponding to when many people lost their jobs. With bitcoin's price at $3,000, the second individual would have needed their $25,000 and all 8.15 BTC to cover their annual expenses. In contrast, the first individual would have retained their 6.15 BTC as the market played out throughout that year and later in the bull market.

The Fractional Reserve Problem

Ironically, "getting on zero" replicates a mistake by fractionally-reserved banks: holding insufficient reserves to cover their liabilities. Fractional reserve banks maintain only a fraction of their depositors' funds in reserve, lending the rest out. This system works as long as depositors do not simultaneously withdraw their funds.

However, in times of crisis, such as a bank run, these banks can face insolvency due to insufficient reserves. For more on full reserve banking for fiat and bitcoin banks, please see We Need Sound Banking and I Like Bitcoin, Buy My Fractionally-Reserved Bitcoin.

Similarly, individuals who "get on zero" by holding all their wealth in bitcoin may find themselves in a precarious situation when they need to meet their fiat-denominated liabilities, especially during periods of market volatility. By holding an insufficient fiat currency reserve, they expose themselves to the risk of forced liquidation of their bitcoin holdings.

Conclusion

In conclusion, while "getting on zero" may seem appealing, it is ultimately a myth that can lead to financial instability due to the unavoidable presence of fiat-denominated liabilities. By acknowledging this reality and thoughtfully managing near-term liabilities with fiat assets, bitcoiners can mitigate the risks associated with asset mismatch while utilizing bitcoin as their long-term savings vehicle.

The privilege of living through the monetization of bitcoin and the transition of the global monetary system requires bitcoiners to make prudent decisions regarding their assets and effectively manage their finances as we inevitably encounter road bumps in bitcoin's adoption path.

Stay humble, stack sats, and match your assets to your liabilities.

We're used to altcoin salesmen approaching bitcoiners with some version of "I like bitcoin, buy my shitcoin." Perhaps the most dangerous class of altcoins and the one that is likely to wreck the greatest number of bitcoiners in upcoming years is fractionally-reserved bitcoin (FRB).

Some factors that make FRB more dangerous than other altcoin schemes are listed below and further elaborated throughout the rest of this article. Bitcoiners should be aware of these tactics to be able to identify them and ignore or dispel them as needed.

1. Bitcoin affinity
2. False equivalence with free markets
3. Brandolini's Law
4. Argumentum ad ignorantiam
5. Deceptive language

Bitcoin affinity

FRBs have bitcoin in their name, and the unit of account for these altcoins is bitcoin, though they are merely IOUs denominated in bitcoin where the actual bitcoin needed to meet all outstanding IOUs are not readily available to the issuer. Similar to how USD "depositors" may think the cash corresponding to their IOU balance is available and sitting at the bank, FRB holders may be deceived into thinking the loans they've made to fractionally-reserved bitcoin banks are "deposits" that are fully available on demand, which is, by definition, not the case. Unlike USD, however, no lender of last resort can print the difference, which is ultimately good for bitcoin holders but disastrous for FRB holders, as we experienced with the collapses of BlockFi, Celsius, and FTX.

Opposition to fractional reserve banking is native to bitcoin's history. In one of his early bitcointalk posts, Satoshi notes, Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. This isn't to suggest Satoshi was infallible or to appeal to authority in any way. Instead, it is to disprove some FRB proponents that would otherwise have you believe opposing fractional reserve banking is a recent phenomenon attributable to a Rothbardian cult that has taken over bitcoin twitter. Quite the contrary, opposing FRBs is embedded in bitcoin's DNA, and it is the so-called "free banker" cult that aims to hijack the direction of bitcoin with failed ideas of the past.

False equivalence with free markets

Similar to other altcoin proponents, proponents of FRBs may espouse free market ideals. Some of their free-market-driven arguments are intended to guilt and gaslight bitcoiners into believing that opposing their failed idea is equivalent to opposing the ideals of free markets. This is obviously disingenuous as most bitcoiners that oppose altcoins are doing so as part of the free market and simply rejecting products they don't like.

While we don't necessarily need to specify any particular reason to object to a given idea or product – it is a free market, after all – we actually have good reasons to oppose FRB. It is both self-serving and the right thing to do for bitcoiners to vocally and voluntarily disassociate themselves from deceptive and unsustainable products. For one, the existence of FRB would temporarily inflate the money supply. Additionally, we don't need bitcoin's reputation to be tainted in the public eye when FTX clones collapse in the future.

It is indeed the FRB proponents that are at odds with the free market when they accuse bitcoiners of being anti-free-market. Instead of accepting what the market is telling them about the inferiority of their product, they are attempting to blame the market for not being open-minded about their historically failed and mathematically-destined-to-fail idea.

Brandolini's Law

Unlike most altcoin proponents, FRB proponents may be highly sophisticated and well-versed in the history of money and banking. Some may even claim to be students of the Austrian School of Economics or at least Austrian-adjacent in their views. Others may be "OGs" in the bitcoin space. In reading or listening to their arguments, you'll likely run into many literary and historical references that can become tiresome to research and refute due to the bullshit asymmetry principle or Brandolini's Law.

None of their sophistry, however, can change the basic fact that a "bank" with X<100% reserves would fail and lead to losses for its customers when customers representing >X% of the claims show up to withdraw their funds. As time approaches infinity, the probability that >X% of the claims request redemption approaches certainty.

Argumentum ad ignorantiam

FRB proponents sometimes counter the mathematical proposition above with historical examples of free fractional reserve banking. In doing so, they ignore the math and handwave it as an issue the market can solve, as if the markets can alter math.

They also handwave over the fact that their examples are historical, as in failed and non-existent today. They treat the  historical evidence of spectacular failures as if the evidence supports their  case. One example, as Murray Rothbard notes is how "free" Scottish banks suspended specie payment when England did, in 1797, and, like England, maintained that suspension until 1821. Free banks are not supposed to be able to, or want to, suspend specie payment, thereby violating the property rights of their depositors and noteholders, while they themselves are permitted to continue in business and force payment upon their debtors.

FRB proponents argue that we simply have not had the right environment for fractional-reserve banks to flourish. This is an appeal to ignorance akin to how communists argue we have never witnessed true communism when presented with the evidence of historical failures.

In contrast to the failed history of free fractional reserve banking, as recently as the BlockFi, Celsius, and FTX failures, there is a growing ecosystem of 100% reserve banking and accompanying tools using bitcoin, including cashu, Fedimint, The Lightning Network, and The Liquid Network.

The historical record, particularly with bitcoin, favors 100% reserve banking. The projects mentioned above have a path to scaling, while no FRB solution has demonstrated the ability to survive, let alone scale beyond flawed thought exercises.

Deceptive language

Of note with FRB proponents is the language used to describe their product. The words we use in bitcoin matter, as @dergigi covers here.

Free banking

FRB proponents have laid claim to the practice of "free banking," whereas 100% reservists are typically referred to as "Rothbardians" – not exactly a household name and much less bald eagle, apple pie, and fourth of July-sounding than "free banking."

Bitcoiners need to reclaim the title for free banking based on free banks that are viable and exist today (e.g., cashu, liquid) and relegate FRB proponents to adopt an obscure non-household name for themselves. One option is "Selginite" if the good doctor wouldn't mind.

Deposits

Another trick the FRB proponents play with words is how they name customer loans to the bank "deposits."

This, of course, has the potential to cut to the heart of how "free" fractional-reserve banking actually is since the contract between the depositors and the bank cannot be considered voluntary if an overwhelming majority of the customers in that contract do not understand the nature of the relationship. This may be obvious for economists, professionals in the financial sector, or bitcoiners that have taken up the study of these matters. But, one needs only to visit a local coffee shop or another establishment to understand the general public's understanding is far from it.

Conclusion

In the words of Caitlin Long as she warned SBF prior to the collapse of FTX, a fool and their leveraged bitcoin are soon parted.

FRB are simply leveraged bitcoin wrapped in jargon and, to date, deceptive language. Fractional reserve bitcoin banks are mathematically destined to fail. While their existence in the market at any point prior to their failure wouldn't annul this mathematical certainty, they have also failed in the market each time they have been attempted. On the other hand, full reserve bitcoin banks are alive and well.

In principle, people have a right to experiment with FRB, just as they have a right to experiment with altcoins. Similarly, the voluntary and vocal opposition of bitcoiners towards FRB is equally, if not more, justified as part of the same free market. Nevertheless, bitcoiners would do well to avoid and prevent FRB as much as possible to protect themselves and others against financial loss and protect bitcoin's reputation in the eyes of the public that may incorrectly associate FRB with bitcoin.

Additional reading and viewing:

1. The Myth of Free Banking in Scotland, Murray Rothbard
2. The Great Fractional Reserve/Freebanking Debate, Stephan Kinsella
3. Rothbardians vs. "Free Bankers", Robert Murphy
4. Does Fractional Reserve Banking Endanger the Economy, A Debate

An overview of the nostr protocol for discussion on March 20, 2023.

Why did we need it?

• Decentralize the web: resist censorship, regain privacy, avoid the algos
• Blockchains can't do this: the web is 175 zettabytes = 350 bitcoin nodes x 8 billion people with no redundancy
• Free speech: rights of the consumer vs. rights of the platform

Financial market website Zero Hedge knocked off Twitter over coronavirus story

Twitter Inc has banned financial market website Zero Hedge from the social media platform after it published an article linking a Chinese scientist to the outbreak of the fast-spreading coronavirus last week.

ReutersReuters Staff

Permanent suspension of @realDonaldTrump

Suspension of @realDonaldTrump

Hearing on the Weaponization of the Federal Government on the Twitter Files

House Judiciary Committee Republicans

What is it?

• Notes and Other Stuff Transmitted by Relay

How does it work?

What can it do?

• "Twitter" and other social media
• Scalable decentralized apps without a blockchain or token
• Check the math

What can't it do?

• Trustless prevention of double spends
• Consistency: no single global state
• Identity:

https://cash.app/.well-known/nostr.json?name=jack

How is it going?

Nostr Stats

How do I join?

• nostr.com

What comes next?

• Zaps (NIP-57): Micropayments and content monetization

snort.social - Nostr interface

Fast nostr web ui

Nostr interface

snort.social - Nostr interface

Fast nostr web ui

Nostr interface

• Badges (NIP-58): "NFT" use cases like "access", "community", "accomplishment" without a speculative token

Badge

Long form notes over nostr

Badge

Long form notes over nostr

• Nostr 2.0?
• purple pill -> orange pill

Where can I learn more?

• GitHub
• Nostr Directory
• Nostr clients, relays, and other tools
• Nostr Resources by @dergigi
• Telegram group

On March 9th, 2023, Michael Barr, the Federal Reserve Board's Vice Chair for Supervision, cautioned banks to approach crypto, including so-called stablecoins carefully. He warned about the potential liquidity shocks that the issuers of these tokens may incur due to depositors demanding immediate redemptions. And, he added, "the banks we regulate, in contrast, are well protected from bank runs."

One day after Mr. Barr's speech, on March 10th, Silicon Valley Bank (SVB), a top 20 bank in the US by asset size that has very little to do with crypto and is subject to the regulations Vice Chair Barr cited in his speech, suffered a bank run that led to its shutdown. It is unclear whether customers will fully recover their deposits at SVB, and leading venture capitalists known for their otherwise laissez-faire approach to markets are calling for a bailout (edit: as of 6:15 PM ET, the Treasury, Fed, and FDIC have announced approval of actions that will fully protect depositors).

The events of last week (and potentially, the following weeks) highlight a fundamental need currently unmet by our banking system: individuals and businesses want a mechanism by which they can warehouse their cash without their bank lending it to anyone else.

Following the collapse of FTX in late 2022, many of us in the bitcoin and crypto space attempted to point out that FTX wasn't a failure of bitcoin, or crypto for that matter, but a somewhat vanilla run on a bank with fractional reserves that took place at Twitter speed.

With the collapse of SVB, we witnessed the same flavor of failure at an identical speed. The difference between the two scenarios is that SVB was a top 20 bank in the US, under the supervision of federal agencies, which became insolvent due to losses incurred in its US Treasury portfolio. In contrast, FTX was an off-shore crypto exchange that incurred losses on its token (FTT), where regulators cited the lack of oversight as one reason for its failure. One day after Mr. Barr's comments about regulated banks being "well protected" from bank runs, we witnessed our second largest bank failure.

While bank runs have always been a risk to fractional reserve banks, we haven't always lived in a world with bitcoin, Twitter, and soon, FedNow. Unlike our world fifteen years ago during the Great Financial Crisis, we now have an alternative monetary system designed to avoid some of the risks inherent to our current monetary and banking systems. Additionally, we have a technically-savvy generation of consumers that are increasingly aware of the shortcomings of fractionally reserving demand deposits. We have smartphones and social media platforms that allow us to communicate news at the speed of light. With FedNow, we are moving towards near real-time settlement mechanisms that accelerate withdrawals of deposits. Unless something fundamental changes, bank runs will continue and only happen faster.

In the bitcoin economy, survivors of the bitcoin winter continue to build financial infrastructure with protocols and entities that aim to remain fully reserved. The permissionless peer-to-peer Lightning Network is fully reserved at all times. Federated sidechains like Liquid are verifiably fully reserved. Federated Chaumian mints will need full reserves to avoid the consequences of today's fractional reserve banks. And lastly, bitcoin and crypto exchanges and custodians are looking for more ways to demonstrate their reserves to their customers in near real-time.

If the USD-based banking system is to compete in a world with bitcoin, Twitter, and FedNow, we need the option to fully reserve demand deposits. We need banks that can hold cash deposits at the Fed and either collect a spread on the interest or charge fees to warehouse their customers' money. The Narrow Bank attempted to establish such a model in the past, which the Fed denied in 2019. Recently, Custodia Bank proposed a similar model to serve bitcoin and crypto companies, which the Fed denied earlier this year.

Without full reserve deposit accounts, we may experience further consolidation of the banking sector due to additional bank runs on smaller banks and the socialization of depositors' losses to taxpayers every time a fractional reserve bank fails. Neither of these outcomes would help us achieve a more resilient banking system for people simply looking for a place to safekeep their money without lending it out.

In short, times have changed, and our banking system needs to change with the times. We need to allow for banks that offer fully reserved demand deposits. We need to do so without stifling competition or innovation where banks and customers that prefer the risks and returns associated with fractional reserves can continue to exist. We can leave it to the market to design their products and assign a risk premium based on the various models. But we must acknowledge that we need a fully reserved alternative for demand deposits to give depositors this choice. Otherwise, as more and more people realize it's not their money in their accounts, the USD-based banking system will have a hard time competing with the bitcoin-based banking system that is slowly but surely coming to life.

I graduated from a Raspberry Pi for my home server and have been exploring how to configure ZFS on Ubuntu for some time. This article is a summary of the information I wish was compiled when I first learned about ZFS and got it running on Ubuntu for the first time.

I've created the cheat sheet below as general guidelines when creating your ZFS layout for Ubuntu.

These work well for me, but your mileage may vary, and your hardware and usage patterns may merit a different setup. I'm not a professional system administrator, so if you find errors, tweaks, or more nuanced guidelines that work better in different situations, please share them with me so I can reference and update this article and cheat sheet accordingly.

If you are unfamiliar with ZFS, you can read more about it here and here.

See this guide for a complete set of instructions to install Ubuntu with root on ZFS.

Disks and Partitions

Below, I provide layman's heuristics and considerations to determine a ZFS layout for Ubuntu based on your hardware and use cases.

• Bootloader: This is where your bootloader will reside to select our OS upon boot or enter recovery mode. 512 MiB is sufficient.
• Swap partition: The swap partition is where your server parks data when fully utilizing your RAM. The swap partition should not be less than the greater of 2GiB or the square root of your RAM. Your swap partition doesn't provide any performance benefits after reaching double your RAM size. If for whatever reason, your server will hibernate, the minimum size of your swap partition should be your RAM plus the square root of your RAM. The only downside to a larger swap partition is that you would be unable to use that data for something else, whereas too small a swap partition may lead to performance loss or crashes. If disk space is not an issue given the other considerations, you can shortcut this decision and allocate double the size of your RAM. Some advocate that you don't need a swap partition with ZFS, and others still prefer it, primarily for debugging after crashes, but also if you use 'tmpfs' for /tmp, which we will, to prevent out-of-memory situations.
• Boot pool partition: This is 'bpool' in Ubuntu, which requires a minimum of 500MiB and a maximum of 2GiB. If disk space is not an issue, you can allocate 4GiB to be safe, as there are varying reports here and here regarding the minimum requirements.
• Root pool partition(s): If you glanced at the Ars Technica primer, you would have noticed that zpools are the highest level of the ZFS storage hierarchy, comprised of one or more vdevs. These vdevs must include at least one storage vdev and up to three support vdevs.

Below are two videos covering the support vdevs and how and when to use them. The first video by Lawrence Systems is an excellent overview of cache and log vdevs.

The second video is by Level1Linux and provides an overview of the special device vdev.

Below are some rules of thumb to determine your need for these support vdevs and how much space to allocate to each partition.

• Cache (i.e., L2ARC): ZFS uses a portion of your RAM as an ARC (Adaptive Read Cache). An L2ARC is a read cache that resides on an SSD (solid state drive). Somewhat counterintuitively, however, an L2ARC requires additional space in RAM and may reduce overall performance for most builds instead of helping it. In general, if a system has less than 64GB of RAM, L2ARC is likely detrimental to performance. For systems with more RAM, the size of the L2ARC should not exceed five times the amount of RAM. Your cache vdev need not be mirrored or redundant in any other way. Since the L2ARC contains exact copies of data in your storage vdevs, you can fully recover a zpool even if the cache vdev fails.
• Log (i.e., ZIL): The ZIL (ZFS Intent Log) is a storage area that temporarily holds a synchronous write cache until ZFS writes this data to the storage vdevs in the zpool. Whether or not you allocate a separate disk or partition to it, ZFS always uses a ZIL. Including the ZIL as a SLOG (separate log) on an SSD should improve performance if you are operating synchronous writes, such as busy Network File Systems (NFS) or databases. If you don't allocate a SLOG, your ZIL resides on your spinning hard disks, and the performance of those disks binds its performance. If you use a dedicated SLOG, the maximum amount of space you will need is 16 GB (though likely a lot less). Of further note, IXSystems claims that adding other caching functions on the same SSD as the SLOG may hurt performance, though this may not be as detrimental as claimed given its widespread use in online communities, as seen here, here, and here. You can read more about ZIL/SLOG from Jim Salter here. You should mirror your log vdev to avoid catastrophic situations as described here and here.
• Special (aka., special allocation): The special allocation class was introduced with ZFS version 0.8 and primarily serves to index metadata that resides in storage vdevs. This indexing can significantly improve random I/O operations on slower disks when allocated to an SSD. In addition, the special vdev can directly store file blocks below a specific size as a secondary function. However, there are potential issues, such as ensuring that the number of small files does not become so significant to push the metadata out of the special vdev to the slower storage vdev. You can avoid these issues by setting a small enough file size and adding a quota to the file storage above and beyond metadata. You can read more about this vdev here and here. You should target your special vdev to be 5-10% of the size of your storage vdev(s). If you have extra space, you can use the special vdev to store small files. If you have less than the ideal amount of space, you can consider eliminating your L2ARC or accepting the metadata flowing back into the slower disks. Lastly, you should always mirror the special vdev as the entire zpool will be irrecoverable if the special vdev becomes unavailable.
• Storage: A sole storage vdev is the only mandatory vdev required to create a zpool. As noted in the diagram above, there is no redundancy at the zpool level, and you need to implement redundancies at the vdev level. The generally applicable best practice is a well-tuned pool of mirrors, where tuning includes appropriately sized cache, log, and special vdevs and creating different datasets within the zpool with appropriate record sizes for the data type in a specific dataset. Mirroring refers to having at least one complete copy of every disk (stand-alone drive or partition). While more than two mirrored devices within a vdev are possible, it's likely overkill. But your storage vdevs must be in pairs to have a better chance of avoiding data loss as the entire zpool will become inaccessible if any vdev within it fails. For example, if you have two spinning hard disks, you will create one storage vdev. With four, you would create two mirrored vdevs, and so on.

Datasets and Record Sizes

You can have multiple datasets within a zpool, and more importantly, you can assign each dataset a specific record size. ZFS stores data in records, and the default record size at zpool creation is 128 KiB. This record size is the maximum size for a given record, and records may still be smaller. In general, you can improve your server's performance by setting a dataset's record size in line with that dataset's typical workload.

If you want to keep it simple, an untuned default of 128 KiB for all datasets may work fine. Still, you can gain additional performance by adjusting the record size of media folders to 1 MiB and datasets containing SQL databases to 16 KiB. You can read more about the trade-offs associated with ZFS record sizes here. Some real-world tests indicate that 16 KiB record sizes for SQL databases noticeably improve performance.

Additionally, you can consider setting 'special_small_blocks' for certain datasets to store small blocks in the special vdev. For example, if your record size is 1 MiB, ZFS will split any file larger than 1 MiB into pieces, with the last bit likely smaller than 1 MiB. You want to use this setting to allow low-latency access to files smaller than some size, but you will inevitably end up storing some of the smaller tail blocks of larger files in your special vdev as well.

Snapshots and Replication

Snapshots and their easy replication to onsite or offsite "backups" is one of the most powerful features of ZFS. To automate your snapshots and replications, you will want to get cron jobs set up for sanoid and syncoid, where sanoid automates the snapshots your system takes, and the syncoid automates the replication of your datasets to other drives. See more about the installation and configuration of these tools here.

Final Words

You will inevitably run into issues you need to troubleshoot as you toy around with Ubuntu and ZFS. I recommend searching the archives of r/zfs or posting detailed descriptions of your problems on the subreddit if you get stuck. The community may not seem that active, but I've been able to find solutions to nearly all of my problems in their archives. Good luck!

When designing a product that requires a network to be successful, there is the additional complexity of the cold start problem. As discussed in The Elements of User Experience, product designers should aim to design every aspect of the user's experience with conscious intent. As part of scoping the features of a product, or a minimum viable product (MVP), it's vital to prioritize features that can help overcome the cold start problem. With the proper framework, we should be able to translate the complexities of a cold start problem into clear guidelines that help guide the scope of our product's features and user experience.

This article aims to provide such a framework by focusing on the aspects of Andrew Chen's five-stage network growth model that prioritize the initial set of user needs and features. Andrew Chen's book, The Cold Start Problem: How to Start and Scale Network Effects, is available here. Camin McCluskey has summarized Chen's book here.

Network Effects

Network effects are where a product or service's value increases as more users engage with it. Similarly, network effects kill products that cannot simultaneously acquire the right users and content as there is no value for a new user upon encountering the product, also called anti-network effects. Hence we have the cold start problem where the network needs to be cold-started until it reaches the tipping point where network effects become a positive rather than negative force for growth. Andrew Chen calls this tipping point the Allee threshold, borrowed from the biological phenomenon where meerkats obtain increasing benefits from adding new members to their community.

In Andrew Chen's framework, there is also the concept of a carrying capacity, a limit in the growth from network effects, which may or may not be possible to overcome. Examples of signs that a network has reached carrying capacity include problems like spam and trolls that have become commonplace on popular social networks.

Cold Start Theory

The Cold Start Theory is a five-stage model of network growth.

1. Cold Start
2. Tipping Point
3. Escape Velocity
4. The Ceiling
5. The Moat

Each stage has unique considerations and problems that product designers need to overcome. This article focuses on the concerns related to the prioritization of a product's features and user experience design to harness positive feedback loops from network effects while overcoming and avoiding anti-network effects.

1. Cold Start

Every network must bootstrap from a cold start – the lack of a network.

The Atomic Network

The Atomic Network is the smallest network that can stand independently and sustain engagement with your product. This network is small but dense and stable in terms of interconnectedness among the initial users. Further, this network is likely smaller (in the 100s) and more specific than the user segments identified in your strategy document.

To appropriately test the hypothesis for an initial atomic network, product designers should prioritize features that:

1. meet the needs of users in the initial atomic network, and
2. encourage connection density and stability in the initial atomic network while

deprioritizing features that:

1. only meet needs unique to users of subsequent atomic networks,
2. solve problems of larger networks that do not currently exist, and
3. seek aggressive monetization before establishing an atomic network.

The Hard Side

Networks often have a hard side and an easy side. The hard side is usually a small minority of users who create disproportionate value in the network.

Product designers should prioritize features that:

1. meet the needs of the hard side, and
2. encourage engagement by the hard side to grow the network and interact/transact with the easy side while

deprioritizing features that:

1. do not engage the hard side, or
2. create friction for the hard side.

The Killer Product

The killer product is usually a simple, one-click experience. Therefore, product designers should deprioritize bulky features. Also, see How to Un-Bloat Your MVP by Liron Shapira.

Magic Moments

Magic moments are the instances where a product feels like magic. An example of a magic moment is a car arriving at your doorstep at the touch of a screen. The opposite of a magic moment is a zero.

Assuming a product can deliver magic moments with a mature network, product designers should focus on avoiding the opposite of these magic moments by prioritizing features that:

1. guide the user to prevent a zero upon onboarding or initiating the product, and
2. detect and correct zeros (e.g., by nudging other users to create a more magical experience for the user who experienced a zero)

while deprioritizing features that create the potential for more zeros, similar to reducing bloat above.

2. Tipping Point

The Tipping Point is where the network is ready to transition from nascency to hypergrowth. Chen lays out several strategies that can help prioritize features for a product:

1. Invite-Only: Consider invite-only features to provide a better experience for new users, who are more likely to be more connected to the existing network and potentially hard side users. There is the added benefit of containing growth while creating FOMO for parties without the invitation.
2. Come for the Tool, Stay for the Network: Provide utility to users beyond the network and work to pivot them from using the tool to participating in a network.
3. Pay up for Launch: Pay for, or provide monetary benefits to the hard side, if needed. For example, Tinder paid for parties where they required attendees to download their application.
4. Flintstoning: Simulate a functional network until it's on auto-pilot if needed. For example, the founders of Reddit programmed bots to post links until they had sufficient user-generated content on their website.

3. Escape Velocity

Escape Velocity is the hypergrowth stage, achieved through the convergence of three distinct forces.

The Engagement Effect

This is the effect that engagement increases as the network reaches escape velocity.

This effect can be acquired using features that reactivate dormant users, which may be by notifying them that someone they know has joined the network or pointing them to content that may be of interest.

The Acquisition Effect

This is the effect of organically acquiring new atomic networks. Features should enable quickly onboarding new users via invites and integrating them into an atomic network in which they may be interested.

The Economic Effect

These are features that increase the economic performance of the network, such as those that encourage increased conversion to paying users.

4. The Ceiling

The Ceiling is the point at which the network growth begins to stall.

Saturation: New Atomic Networks

Saturation may signify that a new smaller network is required to stack onto the existing network. Therefore, new features should focus on attracting new atomic networks, which may differ from the features that attracted the initial atomic networks.

Shitty Clickthroughs: New Acquisition Effects

Every acquisition channel eventually deteriorates. Therefore, features at this stage should reinforce acquisition effects instead of increasing spending on channels with diminishing returns.

Network Revolts: Hard Side Professionalization

Features favorable to the majority of the network, the easy side, may face adverse reactions from the hard side. Features should nudge the hard side towards professionalization to a point where they can earn a livelihood participating in the network.

Eternal September: Fragmentation and Spam Prevention

Sudden network growth spurts can lead to alienating users due to context collapse. To prevent context collapse, features should:

1. enable users to retain smaller networks, e.g., bilateral DMs, group chats, and communities, to avoid context collapse as the network grows, and
2. prevent spam using downvotes, moderation, proof-of-work, and paywalls.

Overcrowding: Curation and Discoverability

As the network grows, it may be difficult for users to find content that is interesting to them. There may be "old money" effects where earlier users have large audiences that promote their content. Features should:

1. curate content relevant to the users' needs, whether manually or algorithmically, and
2. provide discoverability to new hard side users to avoid churn.

5. The Moat

The Moat is the stage at which the network needs to protect itself from competitors.

One aspect of networked products that Chen does not directly address is the case where a networked product is intentionally interoperable with its competitors.

Such effects exist when building interoperable networked products with Bitcoin and the Lightning Network. Until recently, it would not have been possible to conceive of incentives beyond the ideological and activist realm into the economic realm on such protocols. However, with Bitcoin, products using its currency, its blockchain, or the Lightning Network can benefit economically from its adoption.

Instead of building moats, as in the case of closed networked products, interoperable networked products must differentiate themselves based on improved user experience. As a result, there is likely to be increased competition since switching wallets or on- and off-ramps will be trivial for users. At the same time, cold starts may become easier to execute since a network already exists, and new products may better serve different niches within that network by cherry picking.

The Future of Network Effects

While Chen is more excited about "crypto becoming infused into every aspect of software" than he is about Bitcoin, this contradicts a core insight from the book: networked products lean toward a winner-take-all outcome. One would then posit that one winner will take all, or at least most, of the currency use case. That winner, to date, appears to be Bitcoin.

Symbiosis and Parasitism

Beyond the fact that their special purpose currencies need to compete with bitcoin and other currencies for liquidity, products built on blockchain-based protocols are not technically viable to reach the scale to replace the currently prevalent closed networked products. In contrast, interoperable networked products built on protocols such as nostr have a  chance of working. Unlike Bitcoin, however, interoperable networked products without a currency would not have the embedded economic incentives to drive their adoption. Instead, their growth beyond a user base of ideologues and activists requires economically viable products in symbiotic or parasitic relationships with other thriving networks whenever possible.

External symbiosis for an interoperable networked product may involve providing desired functionality to users of Bitcoin or the Lightning Network to benefit from the existing user base and simultaneously grow both networks. External parasitism may include features that allow seamless migration from a closed networked product (e.g., nostr-based competitors to Twitter, Uber, and potentially GitHub, discussed here, here, and here).

Internal symbiosis may exist until the network reaches a ceiling that the collection of interoperable networked products can't overcome. Internal parasitism would be the natural end state for interoperable networked products once the network reaches its global ceiling. After that, there may only be a need for a few decentralized alternatives to a particular application.

While Chen may have been overly optimistic about "crypto" providing the foundation for future networked products, it is more plausible for interoperable networked products based on open protocols without separate currencies to provide this foundation. Product designers who choose not to compete with Bitcoin by issuing distinct cryptocurrencies should consider externally symbiotic and parasitic features to other networks when prioritizing their scope to overcome the cold start problem.

Don't trust, verify: This article is based solely on my personal views and does not represent the views of my employers. This article is for informational purposes only and does not constitute an endorsement of any products and services discussed or investment, financial, or trading advice. I do not guarantee the reliability of the content in this article and shall not be held liable for any errors, omissions, or inaccuracies.

This article is a summary of instructive notes based on Jesse James Garrett's book by the same title, available here.

User experience (UX) is an often neglected facet of most applications.

User-centered design takes the user into account every step of the way along the product development lifecycle.

In user-centered design,

• no aspect of the user's experience happens without your conscious intent, and
• the designer considers every possibility of every action the user is likely to take.

The most common pitfalls during UX design are:

• Design by default: The new product is complementary to an existing product, and it "defaults to" the design choices of that product.
• Design by mimicry: UX is designed by mimicking familiar conventions from other products regardless of their appropriateness.
• Design by fiat: Instead of user needs or product objectives, personal preferences drive the UX.

The Five Planes

It is best to begin work on a plane when ~80% through the prior plane. Decisions made in lower planes will impact possible options in higher planes.

1. The Strategy, in the form of a Strategy Document
2. The Scope, in the form of Functional Specifications and Content Requirements
3. The Structure, in the form of Architecture Diagrams
4. The Skeleton, in the form of Wireframes
5. The Surface, in the form of Design Mockups

Each plane has considerations regarding functionality and information:

1. Functionality: Consider the product as a tool the user employs to accomplish one or more tasks.
2. Information: Enables users to find and consume the product information quickly.

These planes and their functionality and information elements are summarized below.

1. The Strategy

Why are we making this product?

What will the users get out of the site/app, e.g., buy/sell products, the role of advertising, or user-created content in the business model?

The strategy elements should be documented and maintained in a strategy document.

1.1. Product Objectives

Our objectives as the product developer.

1.1.1. Business Goals

Define the conditions for success, but not the path to get there.

1.1.2. Brand Identity

Define a set of conceptual associations or emotional reactions that interactions with the product should create.

1.1.3. Success Metrics

Define the measurable indicators to influence decisions and evidence whether the product meets its objectives and user needs.

1.2. User Needs

Goals of users outside the product organization.

• Functionality: What functionality is needed to accommodate the user's needs?
• Information: What information is needed to accommodate the user's needs?

1.2.1. User Segmentation

Define segments of users with common characteristics. These characteristics may be:

• Demographic: gender, age, education level, marital status, income, etc.
• Psychographic:  attitudes and perceptions users have about the world, the functionality, and the information in the product

1.2.2. Usability and User Research

Define how to identify and test user needs. Methods include market research, contextual inquiry, task analysis, and user testing.

1.2.3. Creating Personas

Define fictional characters that represent different segments and segment cross-sections of target users.

2. The Scope

What are we going to make?

The functions and features that will be permitted by the site/app and how functions of the site fit together.

Features should be prioritized based on the priorities laid out in the strategy.

2.1. Functional Specifications (Functionality)

Functional Specifications are detailed descriptions of the feature set of the product.

• Be positive, e.g., direct user vs. disallow user.
• Be specific, e.g., videos with most views in the last week vs. popular videos.
• Avoid subjective language, e.g., hip and flashy, meet hipness expectations of X. Better to define branding guidelines and conform.

2.2. Content Requirements (Information)

Content Requirements are descriptions of the content elements of a product.

• Separate format and purpose, e.g., need FAQ vs. the need to provide users with access to commonly needed information.

3. The Structure

How do the features fit together as a cohesive whole?

The structure of the site/application and how different pages/screens are organized.

Interaction Design and Information Architectures can be expressed as diagrams based on the Visual Vocabulary.

3.1. Interaction Design (Functionality)

Which functions end up on which screens?

Interaction Design describes possible user behavior and defines how the product responds to the user.

3.1.1. Conceptual Models

Users' impressions of how the interactive components will behave, e.g., shopping cart.

3.1.2. Error Handling

• Make errors impossible, if possible.
• Make errors difficult otherwise.
• Fix errors if appropriate or handle them to give the user the choice to recover.
• Provide warnings to prevent errors if they may be irrecoverable.

3.2. Information Architecture (Information)

Information Architecture is the arrangement of content elements to facilitate user consumption based on specific aspects of what users need (strategy) and what information meets those needs (scope).

3.2.1. Structuring Content

Organizational and navigational schemes allow users to move through the site content efficiently and effectively.

3.2.2. Architectural Approaches

Architectural Approaches define the approach by which information will be organized.

• The basic unit of information is a node.
• Hierarchical structures (hub-and-spoke) have parent/child relationships.
• Matrix structures allow the user to move along two or more dimensions from node to node.
• Organic structures allow free-form exploration from node to node.
• Sequential structures are common in books, articles, audio, and video.

3.2.3. Organizing Principles

Define the criteria by which nodes will be grouped or separated.

• Organizing principles at the highest level, tied to the product objectives and user needs
• Lower levels of the architecture are influenced more by decisions specific to the content and functional requirements

3.2.4. Language and Metadata

Define a controlled vocabulary: a set of standard terms for the site, a thesaurus that maps commonly used words to the controlled vocabulary, and metadata.

4. The Skeleton

Placement of UI elements (e.g., text, buttons, controls), arranged for maximum effect and efficiency. Wireframes capture all skeleton decisions in a single document that is a reference for visual design work and site implementation.

4.1. Interface Design (Functionality)

How are functions realized on the screen?

Interface Design provides users with the ability to do things. This arrangement of interface elements enables users to interact with the feature set.

• Users immediately notice the important stuff.
• Unimportant stuff is often not there at all.

4.2. Navigation Design (Information)

Navigation design provides users with the ability to go places. This set of elements allows the user to move through the information architecture.

• Provide users with a means to get from one point to another.
• Communicate the relationship between the elements it contains.
• Communicate the relationship between its contents and the page the user is viewing.

4.2.1. Navigation Systems

• Global navigation: Across a broad sweep of the entire product
• Local navigation: Access to nearby architecture
• Supplementary navigation: Shortcuts to related content that are not readily accessible in global or local navigation
• Contextual navigation: Inline navigation for easy access
• Courtesy navigation: Access to items that users don't need regularly, provided as a convenience
• Remote navigation: Navigational devices outside the product, typically used if users are frustrated with the navigational systems provided within the product

4.3. Information Design (Functionality & Information)

Information Design communicates ideas to the user. It is the presentation of information for consumption by the user.

• Group and arrange information elements to reflect how users think.
• Wayfinding is a set of design elements that enable users to orient themselves using colors or icons, similar to parking lots.

5. The Surface

The Surface is the user interface, including text, images, and any interactive components. The considerations at the surface can be subjective. See the work of Marc Andrew for helpful guides and design systems.

5.1. Making Sense of the Senses

• Smell and taste: Choice of materials for physical products, e.g., "new car smell."
• Touch: Industrial design, materials, shape, vibrations
• Hearing: Sounds to inform the user and give personality to the product, encourage recall
• Vision: How effectively does the design support objectives of each plane? Communicate brand identity.

5.2. Follow the Eye

Where does the eye go first?

• Successful designs will have smooth eye flow. User feedback that suggests the design is "busy" or "cluttered" indicates that the flow isn't smooth.
• The surface plane should provide a guided tour of possibilities without distracting from information or functions to fulfill those possibilities.

5.3. Contrast and Uniformity

• Contrast to draw attention, e.g., brighter components for navigation
• Uniformity, e.g., same height buttons

5.4. Internal and External Consistency

• Consistent "look-and-feel" within and across other similar products

5.5. Color Palettes and Typography

• Use colors and typography effectively
• Associate colors with similar elements
• Differentiate text components with different typography

5.6. Design Comps and Style Guides

• Design composition should mirror wireframes
• Style guides enforce design consistency

— Marvin Gaye on the storage, latency, and throughput limitations of blockchains

The indexed Web currently contains 3.83 billion pages [1] that serve five billion people [2], with an expected data footprint of 175 zettabytes by 2025 [3]. Every second, we transmit over 150 TB of data, including over 3,000,000 emails, 100,000 Google searches, 10,000 tweets, and 1,000 Instagram posts [4].

Meanwhile, the entire Bitcoin blockchain is 420 GB [5], and an archival node of Ethereum is "units of terabytes" [6] in size.

To some, it is intuitive that blockchains cannot meet the data storage needs of the Web and that the protocols and applications based on blockchains cannot serve the processing needs of everything we want to do online at the volume and speed we want to do those things.

To others, the indefinite optimists, as Peter Thiel would call them [7], a web built on blockchains is still a possibility. Yet, blockchain-based protocols cannot give us the Web we want, even in the most optimistic scenario. So, instead, we should explore alternative protocols to serve as the foundation of the Web.

The remainder of this article covers:

• the Web we want,
• the blockchain,
• the alternative, and
• unchaining the Web.

We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.

— Eric Hughes on the Web he wants in A Cypherpunk's Manifesto [8]

The Web we want

The Web we want is:

• Private: Privacy is the ability to selectively reveal information about oneself to others, whether it's another person, a vendor, or an application. Many online applications we use today collect excessive information about us. They monetize our data to bring their products to market and frequently leak our information, compromising our identities, contact information, and even physical location. The Web we want minimizes the personal data required to function and empowers individuals to disclose only the information they wish to reveal to others online. Minimizing private data collection can protect individuals, businesses, and governments from threats they may face due to cybersecurity breaches. The recent leak of one billion individuals' data in China [9] illustrates how dangerous the world can become without privacy.
• Verifiable: Verifiability is the ability to ascertain the validity of some information and ensure that it has not been tampered with by unauthorized parties. Today's popular applications are full of fake accounts, which can disseminate information from sources that we cannot verify. Because most of these applications are closed source, we cannot verify the algorithms that serve us the information either. Instead, centralized parties judgmentally "verify" accounts using "checkmarks," which they can revoke at will. The web we want empowers individuals to verify the protocols, applications, and information shared in those applications while encouraging them to communicate with others in a verifiable manner.
• Censorship resistant: Censorship resistance is the ability to avoid restrictions on participation in a protocol. Centralized services, whether because of the authoritarian regimes in which they reside or their policies, unapologetically censor their users at increasing rates. Some open protocols, including blockchain-based ones, have faced numerous denial of service attacks that prevent all users from participating in the protocol. The web we want does not allow any one party to prevent other parties from participating in a protocol and empowers its users to identify and defend against denial of service attacks.

In terms of its performance, the Web we want has:

• High availability
• High throughput
• Low latency
• Low cost

Today's web applications are highly performant but lack privacy, verifiability, and censorship resistance. As long as they're in the hands of a few centralized authorities, the Web today is not the web we want.

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

— Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System [10]

The blockchain

A blockchain is an append-only data structure (a chain of sequenced blocks) containing transaction data, ranging from the movement of funds to more complex transactions embedded in "smart contracts."

A blockchain-based protocol (e.g., Bitcoin, Ethereum) is a set of communication instructions and verification rules based on these append-only data structures, which allow the protocol users to establish a common global state.

A node on a network that uses a blockchain-based protocol needs to have:

1. Enough data storage to store everyone's data, all the time, sequentially, since inception and
2. Enough computing power to process everyone's data, all the time, sequentially, since inception.

Further, each node needs to store and process the necessary data with:

1. High enough throughput to accommodate the volume and
2. Low enough latency to accommodate the speed at which we interact online.

Storing only cryptographic hashes of data on blockchains instead of the underlying raw data and processing proofs of each computation on blockchains instead of the underlying computations does not alter the need for everyone to store and process that data all the time, sequentially, since inception.

As long as there are non-zero storage and processing costs required for the things we want to do online, it is infeasible to use a data structure that requires everyone to agree on a common global state of everything we do online. Then, we should consider the limited set of applications where it would make sense for society to bear the costs of a blockchain's inefficiencies. One such application is global, digital, sound money, i.e., Bitcoin. It makes sense to incur this cost for Bitcoin because we have not stumbled on a more efficient way to ensure global, digital, sound money exists. All nodes on the Bitcoin network must store and process everyone's transactions, all the time, sequentially, since inception, to establish account balances and validate the total money supply. The storage, computation, throughput, and latency requirements are tolerable enough to subject ourselves to the limitations of a blockchain for this one application as it has the chance to serve the role of money with a total addressable market of $420 trillion or more [11, 12].

Satoshi started with a particular problem and settled on a blockchain as a means to solve that problem. Thanks to his work, we now have global, digital, sound money. But, what application besides money needs a blockchain to be private, verifiable, and censorship-resistant? The use cases to date are typically new forms of limited purpose monies or securities issued without being subject to the necessary disclosures. Putting questions of ethics and economic viability aside, these applications cannot give us the Web we want.

Governments are good at cutting off the heads of centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.

— Satoshi Nakamoto on centralized vs. p2p protocols [13]

The alternative

With a blockchain-based protocol, the following limitations apply to nodes so that they may determine the common global state, i.e., consensus:

1. Everyone must store and process the data: Every node using a blockchain-based protocol must store and process data. If an application doesn't need every user to store and process data, it shouldn't be on a blockchain. If not every user needs to store and process data (or hashes, pointers, proofs of the underlying data), it also does not need to be built using peer-to-peer (p2p) protocols, a superset of blockchain-based protocols.
2. Everyone's data must be stored and processed: Nodes using a blockchain-based protocol must store and process data for every user. "General purpose" blockchains like Ethereum are further limited in their scalability as users of one application must also incur the burden of storing and processing data for users of all other applications on the protocol. It is unlikely that any application needs this level of storage and processing.
3. Data must be stored and processed all the time: Nodes using a blockchain-based protocol must store and process data all the time to verify the most current global state. Since everyone must store and process everyone else's data, a node cannot stay in sync with the consensus reached every block and serve other users unless it is storing and processing data all the time. In applications that don't have an inherent double-spend problem, there's no need to introduce a double-spend problem, and users can verify information without the need for an always-on node.
4. Data must be stored and processed sequentially: Nodes using a blockchain-based protocol must store and process all data sequentially. The reason for doing so is again to prevent the double-spend problem per the protocols' rules. Non-monetary applications don't need to be constrained tools specific to solving monetary issues if they are setting out to provide solutions to other problems.
5. Data must be stored and processed since inception: Nodes using a blockchain-based protocol must store and process all data since inception. In most non-monetary applications, this is too high of a burden to bear. Furthermore, as time goes on, the ability to scale applications on blockchain-based protocols worsens.

It would be prudent for every user of a global, digital, sound money to store and process all data (i.e., run a full node) such that they don't need to trust another node to verify their balance or the total money supply. Money is an application that everyone in the world needs to use multiple times every single day.

If an application does not require any of the above, it doesn't need to be burdened by a blockchain, and alternative protocols should be developed and used.

An example of a protocol that embodies an alternative to build the Web we want is nostr (Notes and Other Stuff Transmitted by Relays) [14], initially developed by fiatjaf.

With nostr:

1. Only some users (i.e., relays) must store and process data: Instead of everyone storing the data, only relays offer to store data. If a relay attempts to censor a user, the user can choose a different relay or use multiple relays at any time.
2. Only some users' data can be stored and processed by any given relay: Instead of storing everyone's data, every relay is free to store only the data it wishes to store. Additionally, a user can run a relay that only serves their data.
3. No relay needs to store and process data all the time: Multiple relays can store data such that no single relay has to store and process data all the time. It is sufficient for there to be at least one operational relay for each user to serve the queries from the network.
4. No relay needs to store and process data sequentially: The sequential nature of blockchains and the rules embedded in the protocols using those blockchains prevent double-spending. There isn't a double-spend problem we need to solve with "tweets" or any application other than money (i.e., value storage and transfer), so the precise sequence of all "tweets" worldwide is not a concern to any given user or relay.
5. No relay needs to store and process data since inception: Since we don't have the problem of calculating account balances or total money in circulation, relays are free to choose how far back to store and transmit data.

Unlike a blockchain-based protocol, more flexible protocols like nostr have a chance of working and satisfying the attributes of the Web we want:

• Private: No user needs to disclose any information about themselves that they don't wish to reveal. Anyone can anonymously run a relay. Users may anonymously compensate the relays that serve them using global, digital, sound money, and both users and relays can build reputations based on their public keys.
• Verifiable: Every user can hold their private keys and communicate in a verifiable manner using cryptographic signatures. Further, separating the protocol from the user interface allows a user to select an interface where they can verify the algorithms used by the application in presenting the queried information.
• Censorship-resistant: Every user is free to run a relay or provide their data to any relay willing to host it. While any relay can censor as it pleases, users only need one third-party willing to relay their data or self-host for their followers to continue receiving their broadcasts.
• High availability: Bitcoin is highly available because it has extreme redundancy. Bitcoin's excessive redundancy is necessary as any one of the eight billion people across the globe may need to communicate with others on the Bitcoin network at any given time. On the other hand, a redundancy of a handful of relays should be more than sufficient for most applications using nostr, even for the most influential of influencers to reach their followers. More importantly, anyone can run a relay and self-host if needed or desired. Thus, nostr applications can achieve sufficient availability with ten relays as opposed to ~50,000 Bitcoin nodes [15] and ~5,000 Ethereum nodes [16].
• High throughput: Bitcoin's throughput is at most 4 MB every 10 minutes [17] or 0.053 Mbps, and Ethereum's throughput is at most 1.875 MB every 15 seconds [18, 19] or 1 Mbps. In comparison, the throughput for a user of nostr is constrained only by the user's download speed and the upload speed of his relays. With a median fixed broadband speed of 64.70 Mbps [20], nostr provides three orders (1,213x) more throughput than Bitcoin and one order (65x) more throughput than Ethereum.
• Low latency: The median latency of fixed broadband users is 10 ms [20], while two confirmations (~20 minutes = 1,200,000 ms) are standard practice to confirm settlement on Bitcoin, and equivalent settlement (finality) assurances currently require 3x as much time (3,600,000 ms) on Ethereum [21]. Nostr, limited only by the latency of the users' and relays' Internet connections, is five orders faster than Bitcoin (120,000x) and Ethereum (360,000x).
• Low cost: The cost of storing and processing data on Bitcoin and Ethereum depends on the supply and demand for bitcoin and ether, whereas the cost of storing and processing data with nostr is more likely to rely on the cost-plus pricing of the underlying commodities (data storage and bandwidth) similar to cloud service providers. At the current fees of 3 sat/vB on Bitcoin [22] and average gas price of 35 Gwei on Ethereum [23], it would cost ~0.03 BTC ($635) and ~0.56 ETH ($753) to store 1 MB of data on Bitcoin and Ethereum, respectively. With the price of a 10 GB DigitalOcean droplet at $4/month and assuming a 100-year data storage duration, the marginal cost of 1 MB of data for a single nostr relay is $0.48. With ten relays, the fees are $4.80: two orders cheaper than both Bitcoin (136x) and Ethereum (157x). Of course, this assumes one needs to store data that long to begin with, which is not a choice when it comes to blockchain-based protocols but is a choice for alternative protocols such as nostr.

Performance comparison

In discrete terms, the average nostr user can achieve 65 times the throughput, 360,000 times faster, and 157 times cheaper per unit than the average Ethereum user. All in, nostr is ten orders (1.98e10 = 1,213 * 120,000 * 136) more performant than Bitcoin and nine orders (3.68e9 = 65 * 360,000 * 157) more performant than Ethereum when considering throughput, latency, and cost.

Scalability comparison

Now consider that a nostr user needs only fetch data directly relevant to him, while the blockchain user needs to fetch everyone's data, all the time, sequentially, since inception. Split equally among the five billion Internet users, and assuming the average Internet user fetches the data of 5,000 other users, the average nostr user would require six orders of magnitude less data than the average blockchain user. By design, the raw performance demand on a nine-order less performant system like Ethereum would be six orders more than the alternative, making Ethereum fifteen orders less scalable than nostr to achieve the same objectives.

Best case scenario for blockchains

Vitalik Buterin suggests that Ethereum can scale 10,000-fold (four orders) using rollups and sharding [24]. Assuming he can deliver on this promise, Ethereum would still be eleven orders less scalable than nostr.

Suppose we further eliminate the need for settlement assurances and assume that Ethereum is a single node with a latency of 10 ms. Ethereum would gain an additional five orders of performance while destroying any remaining hope for privacy, verifiability, and censorship resistance. In such a scenario, Ethereum would still be six orders less scalable than nostr without the privacy, verifiability, and censorship resistance benefits of nostr.

Further, we can expect the cost of storing and processing one unit of data on blockchain-based protocols to increase as the number of users increases, resulting in increases in their token prices and on-chain fees. In contrast, we can expect the cost of storing and processing the same data using protocols like nostr to decrease due to improvements in the underlying hardware and infrastructure (Moore's law).

The above estimates are point-in-time with embedded assumptions. As such, they should be considered illustrative rather than precise comparisons of performance and scalability. Nevertheless, whether the exact difference in scalability ends up being six or fifteen orders of magnitude, it is clear that blockchains are not the tool for the job.

Since blockchains cannot give us the Web we want, we need alternative protocols. More specifically, we need protocols that don't require everyone to store and process everyone else's data, all the time, sequentially, since inception.

Let us proceed together apace. Onward.

— Eric Hughes, A Cypherpunk's Manifesto

Unchaining the Web

Today's Web relies on centralized services that lack privacy, verifiability, and censorship resistance. An alternative web built on blockchain-based protocols would be limited in scale and performance. Without a quantum leap, blockchain-based protocols cannot reach the scale and performance of today's centralized services without falling back to the same trappings of centralization.

The Web we want is private, verifiable, and censorship-resistant. It has high availability and throughput and low latency and cost. A peer-to-peer protocol with a blockchain is an excellent tool to establish global, digital, sound money. We haven't been able to develop a better alternative, and it has a good chance of working. The characteristics that make a blockchain necessary for this one application also make it inefficient and unsuitable for building the Web we want. While another limited application for a blockchain-based protocol may emerge, these protocols cannot provide us with every application we want to use online at the volume and speed we want to use those applications.

The Web we want requires scalable protocols. Luckily, the development of these protocols is in-flight today, and they have a good chance of working to give us the Web we want. In addition to nostr, protocols and applications are being developed by bluesky [25], Holepunch [26], Impervious [27], Synonym [28], and TBD [29], to name a few. We should support, use, and improve those protocols so that one day, we may have the Web we want.

Acknowledgments: I thank all contributors to the nostr protocol for their work, which inspired me to write this article. I also thank Baris Sarer, Cem Kozinoglu, fiatjaf, Jack Ronaldi, rhinovesting, and other anonymous individuals for their time reviewing and commenting on earlier drafts.

References:

1. https://www.worldwidewebsize.com/
2. https://www.statista.com/statistics/617136/digital-population-worldwide/
3. https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf
4. https://www.internetlivestats.com/
5. https://blockchair.com/bitcoin/charts/blockchain-size
6. https://ethereum.org/en/developers/docs/nodes-and-clients/
7. http://www.zerotoonebook.com/
8. https://nakamotoinstitute.org/cypherpunk-manifesto/
9. https://www.wsj.com/articles/china-has-a-problem-with-data-leaks-one-reason-is-its-surveillance-state-11658410752
10. https://bitcoin.org/bitcoin.pdf
11. https://www.credit-suisse.com/about-us/en/reports-research/global-wealth-report.html
12. https://www.bcg.com/publications/2022/standing-still-not-an-option
13. https://satoshi.nakamotoinstitute.org/emails/cryptography/4/
14. https://github.com/nostr-protocol/nostr
15. https://luke.dashjr.org/programs/bitcoin/files/charts/historical.html
16. https://www.ethernodes.org/
17. https://bitcoinmagazine.com/guides/what-is-the-bitcoin-block-size-limit
18. https://ethereum.org/en/developers/docs/blocks/
19. https://blog.bitmex.com/ethereums-new-1mb-blocksize-limit/
20. https://www.speedtest.net/global-index
21. https://howmanyconfs.com/
22. https://mempool.space
23. https://ycharts.com/indicators/ethereum_average_gas_price
24. https://www.youtube.com/watch?v=UuMOQAVpI2c
25. https://blueskyweb.org/
26. https://holepunch.to/
27. https://www.impervious.ai/
28. https://synonym.to/
29. https://developer.tbd.website/projects/web5/

Additional reading:

1. The Bitcoin Standard by Saifedean Ammous
2. Bitcoin, Not Blockchain by Parker Lewis
3. An Economic Analysis of Ethereum by Lyn Alden

Don't trust, verify: This article is based solely on my personal views and does not represent my employer's views nor the views of reviewers of earlier drafts of this article. This article is for informational purposes only and does not constitute an endorsement of any products and services discussed or investment, financial, or trading advice. I do not guarantee the reliability of the content in this article and shall not be held liable for any errors, omissions, or inaccuracies.