I invented the Lightning Network.

Well, not really. But to the best of my knowledge, I was the first person to write a post describing something similar to how LN is conceived today.

I’m not saying this to take credit for its advent — it’s not like I really did anything. Others have invented the concept of micropayment channels on which my suggestion relied, and I only threw out some rough ideas; I didn’t present a full-fledged design, let alone wrote any code.

I’m saying this to emphasize the point that for some of us, that has always been the vision. One of the first burning questions I had when I was first introduced to Bitcoin was how the whole thing was supposed to scale. Concepts I’ve learned of since then — like SPV and pruning — helped, but I wasn’t completely satisfied. Ever since I heard about channels and thought about how they could be used in a network, that would become one of the first things I would reference whenever discussions of scalability came up.

The ability to use an on-chain transaction to anchor a channel, so that real bitcoins can be sent over it without having to bother the entire network or wait for confirmations for every payment — in such a way that the channel can always be closed unilaterally to recover the funds as normal bitcoins sitting in an address you control — is an idea so powerful that I can’t imagine how can anyone resist falling in love with it.

But the reason I am so excited about the development of LN is not that the vision I had is finally being brought to life.

It is because LN is so much better than what I envisioned back then. Based on the protocol at the time and my understanding of it, I had in mind one-way channels with an expiration date; such channels would have to be constantly closed and reopened, as either the expiration date approached or the finite capacity was used up. If you wanted longer-term channels to reduce the number of on-chain transactions, you would have to lock up lots of funds in advance, and recovery of the funds would be greatly delayed in case of a problem with the counterparty.

But the channels used in LN have two key features:

1. They have no set expiration date. Instead they use the primitive of CheckSequenceVerify to create a differential grace period, for security purposes. But as long as the two parties cooperate, the channel can exist indefinitely.

2. They are bi-directional. Payments can be sent both ways, so that every payment going one way replenishes the ability to send payments the other way. This means that even with a finite amount of funds locked in the channel, an unbounded volume of payments can go through.

Together, these mean that in theory, a user can create a fixed number of channels that will last her a lifetime. She can receive her salary or payments through these channels, and send out payments back again through them, ad infinitum, without ever needing to close channels or create new ones.

If you read my 2012 post, you surely have noticed that what I described was basically a hub-based network, rather than a p2p mesh network. This is another ability that the new features bring to the table.

In the old model, a lot of resources would go into maintaining channels, so you had to make sure each channel counts. Opening a channel to some random user would just not do. You needed channels with large, well-connected hubs you can rely on to be able to route your payments.

But with perpetual bi-directional payments, a p2p network becomes a realistic possibility — every link improves the connectivity of the network and opens up new route possibilities in either direction.

Will the Lightning Network Save Us?

The Lightning Network is extremely powerful, and holds the promise for cheaper and faster payments than any other trustless method, scalable without bound, and potentially encompassing the entire range of payments — $10K for a car, $5 for a coffee, or $0.01 for an online news article alike.

I believe many detractors of LN just don’t understand it well enough, and present criticism based on misconceptions. The goal of this post is to clear up some of the confusion, and to establish a conceptual framework to discuss the LN and argue about its merits.

This doesn’t mean there aren’t real challenges and issues relating to it.

For starters, it is much more complicated than the raw Bitcoin protocol. Complicated things are harder to use and harder to implement. There’s more room for error in implementations and more that can go wrong.

A defining characteristic of LN is that for receiving payments, a node has to be online. This is a marked usability difference, and poses new security challenges.

These security challenges can be mitigated with additional mechanisms… That again add complexity.

Finding payment routes can be challenging even when they exist, and the privacy model is different from normal Bitcoin transactions.

Though I will argue in this post for how LN can work, nobody can guarantee that it actually will work as hoped.

Perhaps by the time LN gains traction, it will no longer be needed. Hardware advances might one day make it feasible to have all payments on-chain; and progress in cryptographic primitives, especially in the area of Zero Knowledge Proofs, might allow new designs that solve the issue of scalability in a more elegant way.

But, in case it wasn’t clear — despite all of the above, I do believe LN is a powerful tool we should have in our arsenal — on its own, or to complement other solutions.

What do we want?

I think everyone will agree that the defining characteristic of Bitcoin that we want to preserve in our discussions of its future direction, is decentralization.

The problem is, that there are many ways in which Bitcoin can become centralized. There can be centralization in network nodes, centralization in mining manufacturers, centralization in mining operators, centralization in development & protocol change decisions, centralization in exchanges, centralization in payment processors, and much more… And with a Lightning Network intact, there can be centralization in LN hubs.

When people argue it is usually because they have different ideas on which of these should be emphasized. Fully analyzing all the ways Bitcoin can go wrong is beyond the scope of this post.

I do however wish to stress that there are many tradeoffs, and often improving one aspect of decentralization harms another. We must strive for an optimal middle ground where all features are adequately satisfied.

By way of example, with plain on-chain scaling, if we set the limit on block size too low, transactions will be expensive and users will have to rely on custodial services and payment processors — a form of centralization. If the limit is too high, running a fully-validating network node can become prohibitively expensive, leading to few nodes and again, centralization. In between there is a sweet spot where neither txs nor nodes are too expensive.

It has been said that LN can create centralization, and in a strict sense that’s true. However, an often-missed point is that, when done right, this centralization can be weaker than what is caused by existing tradeoffs, while at the same time improving these tradeoffs. With LN, you can simultaneously have cheap payments, many network nodes and many LN nodes.

Specifically, let’s consider what it would take for an entire planet of 10 billion people to use Bitcoin as a global currency, with traditional on-chain scaling. Assuming each person does 1000 transactions per year, this translates to 10T tx/year. If each tx is 200 bytes, that would mean 2 petabytes just to store one year’s worth of txs (and even with pruning enabled, ideally more than one year would be stored). To this we must add the costs of bandwidth (about 200TB per month) and CPU.

This suggests that there will not be many nodes; and with few easily detectable nodes, the network is easier to shut down by hackers, governments and so on.

Enter LN — in ideal conditions, the LN might work well with as few as 1 tx per person per year. But to be on the safe side we’ll assume 10 txs per year-person (100B tx/year). This cuts the cost of running a node to a hundredth, ensuring anyone who wants to run a node can do so.

It does mean of course there will be 400MB of tx data per 10 minutes. To this figure we may want to add large transactions which will be done on-chain rather than by utilizing LN; if such large txs average $10K, 10B of those per year will be sufficient for $100T GDP, and increase the “block size” to 440 MB; still two orders of magnitude better than pure on-chain.

The current Bitcoin protocol only supports 4MWU, which translate to about 3MB. So it is clear that the block size will have to be increased — the only questions are when, how and how much.

My ballpark, possibly-off-by-an-order-of-magnitude estimate for the eventual cost of an on-chain transaction is $1. Too expensive to want to buy coffee on-chain; but cheap enough that opening channels isn’t too much of a big deal, and that people can still choose to pay on-chain for larger purchases.

The above estimates for transaction volume assume that payments are commensurable with contemporary payment profiles. But once LN is enabled, it shines in the world of true, sub-cent micropayments; these can be made with virtually no cost or scalability limits, enabling entirely new business models no on-chain arrangement can compete with. The total global payment volume can then grow well above the 10T/year estimation, at no additional cost.

The Hub Model

There are two primary modes LN can work — hub-based or p2p. Both are viable. I will discuss the hub model first, for various reasons:

· It is easier to conceptualize.

· It is closer to the original ideas I had all those years ago.

· A common claim is that a hub model would just be a repeat of the traditional banking system; I want to argue this is far from the truth.

The basic idea is as follows: Throughout the world there will be some number M (say, M=300,000) of hubs that offer LN payment routing as a service. Each of them will have an open channel with all other hubs (which shouldn’t be prohibitively costly for someone running them as a business).

Meanwhile, every end user will have open channels with K such hubs, say K=10. Each such channel will strive to have balanced capacity — where there is as much capacity to send from the user to the hub as the other way around.

When Alice wants to pay Bob, the payment will be routed through 3 hops: from A to a hub X which A is connected to; from X to a hub Y which B is connected to; and from Y to B. Such a 3-hop payment can be done very quickly and cheaply. Since A is connected to 10 hubs and so is B, it will be easy to find a path even if some hubs are temporarily down.

Each of A’s channels has finite capacity, and it is a common misconception that once a channel is depleted, she will have to create a new one by paying for an on-chain tx.

However, the channels are bi-directional. A can’t create money out of thin air (this is Bitcoin we’re talking about, not government money), so she doesn’t only pay people, she also receives payment — and she does this through her channels as well. Every payment she receives turns back the clock on these channels, and allows them to be used again.

In a typical scenario of an employee who receives a salary every month and spends it throughout the month, it will look as follows: At the start of the month, Alice will have almost no outgoing capacity in her channels; all funds locked in the channels will belong to the hubs she is connected to (which is equivalent to saying she starts the month with barely any money to spend). Then she receives a salary; this is routed through her different channels, replenishing them all. And now she has outgoing capacity to pay for stuff throughout the month — the same amount she received as a salary.

Of course, if she doesn’t want to live “hand to mouth” so to speak, and have some leeway in monthly spending that does not exactly match the monthly revenue, she can simply have channels with total capacity higher than her salary, to act as a buffer.

Realistically, Alice will want to save up some of her salary (say, 10%) on a timescale of years. If her savings are in other assets, such as gold or stocks, which we pays for through the channels, this is no different from paying for anything else. But if she saves up bitcoins — then even if she has extra capacity in the channels, over time they will fill up. If she goes through every month with 10 mBTC going in but only 9 mBTC going out, then the balance of the channels will be off, with more funds credited to her side of the channel.

Eventually, she will start a month without any incoming capacity in her channels, and she cannot receive her salary through them. At that point, she must create a tx to collect the funds in a non-LN address and open up a new channel with incoming capacity.

When she does close a channel for long-term storage, she can make sure to make the most out of it; if there is a non-zero, but insufficient, incoming capacity on it, she can route a payment to herself in a triangle, so that another channel is replenished and the entire capacity of the closed channel is collected.

With K=10 channels at any time, 10% savings, and total channel capacity equal to her monthly salary, about 1 channel will have to be reopened per month. This can be reduced in direct proportion to the amount of funds locked.

Going back to the overall network structure, the balance of channels between hubs also needs to be considered. If, for example, A continually sends payments to B routed through hubs X and Y; and many other users also route through the link X->Y, it can happen that the channel will be saturated, with no more capacity from X to Y.

This is solved with fee adjustment and market forces in route selection. As long as the channel between X and Y is balanced, X and Y will charge normal service fees for routing. As the direction X->Y is saturated, they will charge higher fees for routing this way, encouraging users to choose other paths over it. Additionally, they will charge lower fees for routing in the other direction, encouraging users to route this way and replenish the channel. At extreme saturation levels, they can go as far as charging negative fees for the reverse direction, effectively rewarding users for replenishing the channel. When such a strategy is combined with users who wish to minimize fees for their payments, and who have many routing options due to good network connectivity, the invisible hand plays its part and ensures the network is balanced and functional.

I have chosen the number M=300K so that, together with the parameters N=10B users and K=10 channels per user, the total number of user-hub channels will be equal to the total number of hub-hub channels, which balances the overall costs.

However, if we consider the number of hubs to be too low, or the cost to set one up too high, we can switch over to discussing a 4-hop model: We can have 4 million hubs, and each one is connected to 4000 others. Properly arranged, there can always be found an intermediary between any two hubs.

Thus, whenever Alice wants to pay Bob, A chooses a hub X she is connected to, B chooses a hub Z he is connected to, and an intermediary Y between X and Z is found. Then the payment is routed A -> X -> Y -> Z -> B.

Such a 4-hop path can be slightly more time consuming and costly than 3-hops; but this network topology allows a much larger number of hubs, and a smaller cost of starting one.

Note that even though we assume only one intermediary between any two given nodes, there is still plenty of flexibility in choosing a path in case of any issue, due to the choice in X and Z.

It should go without saying that the assumption that all nodes are connected (directly in the 3-hop model, through an intermediary in the 4-hop model) isn’t strictly necessary. Even if some links are missing, you can find alternative paths. That is the strength of a robust, well-connected network.

Which leads us to the infamous question…

Are LN hubs the same as banks?

I hope by now it’s clear the answer is — no, not at all.

The most important difference in my view is that, unlike banks, LN hubs don’t hold your money. Your money is stored in a channel, anchored to the Bitcoin blockchain, and only you can authorize its movement. In any case that the channel counterparty refuses to cooperate, due to malice or incompetence, you can unilaterally close the channel and receive the money back as normal bitcoins.

This ability needn’t be exercised to be useful. Simply knowing that you can easily quit encourages the counterparty to behave and offer a good service. And it alone means that even in the extreme case of a completely centralized lightning “network” with a single hub connected to everyone, this is a marked improvement over traditional banking.

Furthermore, running an LN hub is much easier and cheaper than running a bank. As we have seen, we can have million of hubs that cost a few $K each to set up.

This means that the LN doesn’t suffer from the two problems that are the bane of competitiveness — barrier of entry and vendor lock-in. Together, this means that fees for using the LN can be minimal, approaching the very modest cost of the resources consumed.

There is also the issue of privacy. Lightning hubs you are connected to will know more about your financial activity than a generic node in the traditional setting. However, they still know very little; they can learn the public key of the receiving client, but not their real-world identity or reason for payment. Also, other nodes will know much less than in the traditional model, as you do not publicly broadcast every payment. This is a different privacy model than standard Bitcoin, but since it limits the amount of parties having any information about your payments, it is arguably a better one.

As for censorship, this is more censorship-resistant than on-chain scaling. With a large number of LN hubs and network nodes (as opposed to the small number of nodes with on-chain scaling), it is difficult to coax them into censoring transactions.

So how much will it cost?

The end-user cost for paying with LN will reflect the costs of the hubs that run it. It is of course difficult to predict the exact costs of the system, but I will try to give some rough figures as a basis for discussion. The total cost of all hubs, in the 4-hop model, can be broken down as follows:

1. Running nodes: A fully-validating Bitcoin network node isn’t strictly needed for running an LN hub, and running a node shouldn’t be very expensive anyway (the whole point of LN was to reduce this cost), so we will ignore it.

2. Processing payments and routing: Since each LN payment only involves the LN nodes on its path (as opposed to raw Bitcoin transactions, which involve all nodes on the network), processing each payment requires only a small number of machines sending data and signing, hence the cost is negligible.

3. Setup and operation: Negligible, you basically just download, install and run a software.

4. Creating channels: Each hub creates 4000 channels to other hubs, and there’s no reason they shouldn’t last for, say, 10 years. There are 4M hubs, and we have assumed each channel open costs $1, so this is a total of ($1*4M*4K/10yr) = $1.6B per year.

5. Time value of funds locked in channels: This is hard to calculate. With proper fee adjustment, I believe the LN can work well with each intra-hub channel having capacity equal to a tenth of an average person’s salary. This would mean that, Alice can pay Bob a total of 5 months salary before saturating all routes between them (if she wants more, she can always pay on-chain). Note that this would not saturate the intermediate channels between Alice and anyone else, though it might saturate Alice’s own channels. If the average salary is $1000, this means a total of ($1000*4M*4K/10) = $1.6T locked. Since Bitcoin is non-inflationary, the time-value of money is low; we will use a generous estimate of 5%/yr for the time value and cost of security. This gives a cost of $80B per year, much more significant than setting up channels.

Together, this suggests a cost of less than $100B per year for all hubs. At 10T payments per year, this means that the average cost per payment will be about 1 cent.

Note that this is average, not minimal. The main costs for running hubs are opening channels (which are depleted in proportion to amount of funds paid) and locking funds. Accordingly, the fees they will charge are proportional to the amount sent. This means that the average fee of all payments, small and large will be 1 cent, but for small payments the fee will be much lower, with a minimum of perhaps a hundredth or a thousandth of a cent. This allows true micropayments, as well as payments in poor countries for which 1 cent tx fee might be prohibitive, but the typical payment is accordingly small and cheap.

I did not include in the above calculation the costs borne by users to set up their own channels, but these are comparable.

This is all just about how cheap LN payments are. It’s worth pointing out again how fast they are. Unlike on-chain txs which require confirmations in a block before they are considered secure, LN relies on already-confirmed channel-opening txs on the blockchain; and thus each payment is completely confirmed and secured nearly instantly. This, perhaps, is a bigger deal (and a harder feature to provide with other means) than simply scalability and tx cost.

The p2p model

I have written at length about how the LN can work in a hub model while still remaining decentralized. But perhaps a more interesting vision is a true p2p mesh network.

I have discussed 3-hop and 4-hop hub models. If we take it to the extreme, we can examine what it would take to have any two users connected by up to T hops. If we engineer the connections correctly, we can minimize the number of channels required for each user. Finding exact bounds is an open research problem in graph theory, but for T=10 hops, each of the N=10B users needs to be connected to K=15 others.

Of course, such a carefully engineered network might not be considered truly peer to peer. So we may ask about a completely random network, with a total of NK channels which need not even be evenly distributed between users. It turns out that if K is greater than half the natural logarithm of N (in our case, K should be at least 12), then almost surely the graph will be connected.

This result says nothing about the number of hops required. At the threshold K=12 this can be quite large. However, by increasing K we can decrease T. Most research on random graphs gives asymptotic limits, and numerical simulations for a 10B-node network are difficult; but by extrapolating from scaled down versions, I estimate that with K=20, any pair of users will be connected with 8 hops on average — and with many possible paths. Increasing T leads to exponentially many more paths. By allowing, for example, 12 hops, there can be millions of alternative paths between every pair of users.

And this is all assuming a completely random network. In practice, it will not be really random — each user has more economic activity with some peers than others (e.g. peers in the same geography, industry etc.), and will focus on activity with such favorites. The economy in such sub-networks can be done with fewer hops. Also, there is no need to fear the occasional distant peer — if a user needs to send payment to someone on the other side of the network, he can simply spend an on-chain tx to open up a new channel, and have easier access to this remote part of the network for future payments.

Since the network will not be random, but rather built organically based on actual needs, it will have much better performance numbers than predicted by the random graph model.

So users are connected by paths. But is there capacity along these paths in the required direction?

The analysis of the hub model applies here as well. Users will strive to have their channels balanced, and will adjust fees to modulate this. This means that whenever a payment is routed, then among the many possible paths, one will be chosen that replenishes as many as the channels as possible.

On the individual level, a user is expected to receive as much payment value as he sends, so his channels are expected to be balanced. Any large movement of funds, or correcting any imbalance that can result from savings, can be done with an occasional on-chain tx.

The future

So which one is it? Will we have hubs, or a p2p network?

Well, why don’t we have both?

There will be hubs, and users will connect to them. And users will also connect to their peers — friends and business partners. It’s probable that most payment volume will use short routes through hubs. But the interconnectedness of users and their peers will make sure the network stays robust even if something should happen to these hubs.

Finding the best routes in this jungle is up to the client software, and this is not necessarily easy — but if routing on the internet works, I see no reason the LN shouldn’t work as well.

I have focused on analyzing a future scenario where everyone uses LN. Of course, this can be decades away. It’s not clear how exactly we will get to this state, but it will surely involve gradual, steady, organic growth. Starting with early adopters connecting to their friends and service providers, and creating new channels whenever the need arises, the network will be built up and offer more and more value.

Like a flash of lightning, the future is bright.

I was at a conference yesterday. Estimates say that 1000 people attended. At 15:00 people have left the lecture halls and swarmed the lunch hall.

The rate at which food can be dispensed is finite, so people had to wait a long time in line to reach the coveted buffet. Those who decided to wait half an hour before going to eat (and struggle to find something to do in that time, seeing as everyone is eating), could get to the food without effort — but may have missed an opportunity to enjoy the entire variety the meal started with.

Likewise, when everyone is off the clock at the same time and drive home, they encounter traffic — but those who wait until 3 AM to hit the road, has the whole road to himself. This is the way of many aspects of life — if you try to do something at the same time many others are, you will run into overload.

Bitcoin is the conference, and lunch is being served. We are amidst a wave of interest in Bitcoin and its kin. This is not the first wave of its kind, but it is the biggest so far in absolute terms. Anyone who tries to go into the field at the same time as everyone else, sees that every system collapses under the load.

It begins with the Bitcoin network itself, where demand for transactions exceeds the available block space, and transaction fees go up.

Exchange services get hundreds of requests daily, and sometimes there are delays or missed messages.

Among the hosted wallets, those that are considered more reliable (such as Coinbase) are overloaded and struggle to handle support requests.

Other hosted wallets, which to begin with had been a scam, have decided that now is the time to pack their bags and vanish.

Public forums are overloaded, every thread is buried under many others within an hour, and there are more newbies asking questions than veterans who can answer them.

Physical community hubs are overloaded, and people who bother to arrive in person and consult, have to wait in line until an ambassador is free to assist them.

I, personally, am also overloaded with both messages and strategic activity, and one comes at the expense of the other.

When someone encounters a problem, it is hard to tell if she had unfortunately stumbled upon a scam, or whether it is a legitimate service that is experiencing load, or there is overload in the Bitcoin network, or that herself she erred in handling the wallet. And when she comes to ask and consult, she has trouble receiving answers.

Some people have lost money due to this whole mess.

Sad and doesn’t further a solution, but that is the situation today. For those who cannot accept that, I truly recommend to pass for the time being on buying Bitcoin (or Ether or ICO tokens or anything else). He can wait until the dust settles and things clear up, and one of two will happen — either the wave of interest will fade, and we go back to earlier demand levels which the systems can handle; or demand continues to grow, and over times the systems will upgrade to handle it — Segwit will be enabled, exchangers will hire more staff, and the community will muster more knowledgeable people who can support the newcomer.

If someone thinks that if he does not but bitcoins this very moment, he will miss the opportunity to get rich… Well, I can’t really tell him not to buy, and I do of course in favor of bitcoins being distributed among as many people as possible, and not concentrated in the hands of a few veterans. But he should know what he is going into, and not complain about anyone else but himself.

If you can’t take the heat, stay out of the kitchen.

If you’re reading this, you probably know that the Bitcoin community is amidst a civil war.

And you might also know that for almost 2 years, I’ve been advocating the position that if no agreement or compromise can be reached, the best course of action is to have a clean split of the network into two incompatible, competing currencies.

However, I also said that a compromise is the better outcome if at all possible. And I also said that for a split to work it must be done properly, and my fear that this will not be the case is growing.

Which is why I think we should give diplomacy another shot and pursue a genuine compromise, and why I urge people from both sides of the fence to be more receptive to it. And yes, compromise does mean giving up things that you hold dear.

I will not go into exact detail about what such a compromise could consist in. But overall, two key components will almost certainly have to be activation of Soft-Fork SegWit as soon as possible, together with a hard fork to increase the block size further (perhaps with a built-in growth schedule) without more delay than is necessary.

My own side in the debate is no secret — I believe that the best technical solution is to activate SegWit immediately, and figure out later whether we need a hard fork, and which.

But I support a compromise along the aforementioned general lines, for several reasons which I will explain.

Technical merit

I’ve said before that I didn’t really personally experience the dreaded datageddon that others reported, with slowly confirming transactions and prohibitive fees. Transactions still confirmed quickly and with relatively cheap fees. This made me question the need to rush the scaling solutions.

But time has passed and I’m sad to report this is no longer the case. Bitcoin has experienced another burst of explosive growth, and so did demand for space in the blockchain. I’ve observed firsthand that getting transactions confirmed within reasonable time requires fees upwards of a dollar. I don’t care too much about my own costs, but I’m beginning to feel embarrassed to praise the merits of Bitcoin as I have always done.

This leads to two conclusions: First, we need to resolve the situation, we can’t remain in the current situation indefinitely. If a compromise is what it takes to move forward, so be it.

Second, if previously I thought that SFSW is good enough for now — now I think that SFSW is probably sorta kinda good enough for now. If growth continues as it has so far, we’ll need a more aggressive blocksize increase sooner rather than later. So despite all the risks and disruptions, an expedited movement towards a hard fork starts to sound like not such a terrible idea.

The other technical issue is that I think we should be more open to the concept of a hard fork. When I got into Bitcoin I didn’t sign up to the idea that a hard fork would occur only whenever a mule foals. There are many much-needed upgrades to the protocol which can only be done by way of a hard fork. If we can’t even change a well-understood parameter, it doesn’t inspire confidence that we’ll be able to handle the bigger changes ahead.

Conservativeness in forks is important, but there is such a thing as too much conservatism, and we might be approaching that point. Which is why, again, expediting the hardfork schedule might not be such a bad idea.

For people, by people

More important than the technical reasons why a compromise is palatable, are the social reasons why we need it.

I don’t see Bitcoin as a piece of art, an engineering wonder that I can put on display and marvel at its technical correctness. It is a tool created by people with the goal of benefiting people. If it fails at this purpose, it should be fixed.

And right now Bitcoin is stuck, and what’s important is to unstick it, not to pat ourselves on the back for how rigorous our technical development methodology is.

Furthermore, Bitcoin is not as robust as some people might think — it is always at the risk of attack by a determined attacker of means. Its security is based on a combination of its own technical defense mechanisms, together with making sure it has as few enemies as possible. Bitcoin has enough enemies from without to worry about. It doesn’t need infighting and the threat of some segments of the Bitcoin community attacking others, which may well be the case if we go for the more militant methods of resolving the conflict. Bitcoin is strongest when all its proponents are allied, and this is what a compromise aspires to achieve.

But the issue goes much deeper than that.

The debate, it seems, becomes more and more divisive every passing day. People who express disagreement are labeled as sellouts or traitors to the Bitcoin cause. Demonization, personal attacks and mudslinging are rampant. People have picked sides. Propaganda has succeeded. It’s sad and doesn’t further a solution.

It is becoming clear that people have firmly tethered their identity to their side on the debate. And this is bad news. As Paul Graham eloquently explains, you can’t have a rational, civil debate when people’s identities are on the line. People adopt new ideas and resist others not for their underlying merit, but for which side the idea is associated with. This can quickly escalate (and in our case, already has), as people become more and more entrenched in their position, and the more vile a person is perceived just for expressing a dissenting position.

I miss the times when all Bitcoiners were on the same boat. When we could discuss technical topics based on their technical merits. When you could express an opinion without being painted as belonging to one camp or another, or having your opinion ignored just because you are already perceived as belonging to the wrong camp. When ideas were just ideas, not “the ideas of this side” and “the ideas of that side”.

But despite our sad state of affairs, I hope that we can reach a compromise. That we will each make sacrifices and rally behind the same banner. If we can do that… Then I hope it will take us back to those better times. That it will diffuse all the tension that has been built up over the years, and take the sting out of the debate. That we will be able to trust each other once more and spend our energies not on quarreling, but on moving forward and furthering solutions.

That, I believe, is a vision worth fighting for.

Part 1 — How I learned to stop worrying and love the fork
Part 2 — I disapprove of Bitcoin splitting, but I’ll defend to the death its right to do it
Part 3 — And God said, “Let there be a split!” and there was a split. (this one)

A year ago, I’ve written How I learned to stop worrying and love the fork, espousing my view that a split of Bitcoin into two networks is possible, and might even be good under the right circumstances and with proper preparations.

Half a year ago, I’ve followed up with I disapprove of Bitcoin splitting, but I’ll defend to the death its right to do it, which elaborated a bit and aimed to refute some misinformation.

I’ve been meaning to write another followup to address some questions that have been raised…

And then Ethereum Classic happened.

For those of you who’ve been living under a rock, a recap: Ethereum is an alternative cryptocurrency featuring Turing-Complete smart contracts. One such contract, theDAO, raised an investment of $150M. Unfortunately, Ethereum makes it easy to write buggy contracts, and theDAO had a serious bug that caused invested funds to be stolen. The Ethereum Foundation decided to roll back the theft, and dissenters who believe in decentralization refused to accept the rollback, leading the Ethereum network to split in two — the version promoted by the Ethereum Foundation, and another version which received the name “Ethereum Classic”.

Ethereum classic has been running for 2 weeks; some alt exchanges have enabled trading in it, and it now goes for a third of the price of the “official” Ethereum. This is well beyond the “momentary split that will immediately coalesce”, and deep into “short-term split” territory.

The story is still unfolding, but there are already multiple lessons to learn from it.

First, if anyone had any doubts that such a thing is possible — it’s possible. It’s happened.

You might be wondering how a split in Ethereum proves anything when the original debate was about Bitcoin. I firmly believe that Bitcoin is not just Bitcoin, and that any cryptocurrency or decentralized technology is within the realm of the general sense of the term “Bitcoin”. And Ethereum, specifically, is similar enough to Bitcoin in the senses that matter so that insights from it are directly applicable. There is, though, one important difference which I will soon address.

Now is as good a time as any to mention that I had predicted in advance that Ethereum would split — or rather, that it could. At a talk I gave at the virtual OnChain Scaling conference on June 27 (Video, Script), back when the rollback was uncertain speculation, I mentioned that if a rollback would indeed take place, it could possibly lead to disagreement and a split of the network, into a part which believes in rollbacks and one which does not. Basically, exactly what’s happening right now.

In that talk I’ve also explicitly defined a classification of splits according to their length, which I will repeat here as it was absent from previous posts:

In a short-term split, one of the networks soon realizes that it has virtually no support at all. Everyone is using the other currency. Due to the network effect, even those who prefer the protocol of Bitcoin A will be unable to use it. After a few days or a few weeks, even the supporters of Bitcoin A will abandon it, and reluctantly start using Bitcoin B. Bitcoin A will die, and Bitcoin B — the network which has an economic majority — will emerge as the one true Bitcoin.

In a medium-term split, both networks have significant support and they coexist for a while. But after several months or years, it becomes apparent that the protocol of Bitcoin A is problematic. It doesn’t function as well as the network of Bitcoin B, and over time, people switch from one to the other. Here, too, Bitcoin B will ultimately emerge as the one true Bitcoin.

In a long-term split, neither of the networks is clearly superior. Each has its own advantages and disadvantages, and each has its supporters and preferred use cases. This will result in two different currencies, that will coexist indefinitely, which were both spawned from the same original coin.

With only two weeks on its belt, I don’t yet consider the Ethereum split a medium-term one. So it has not yet been proven conclusively that medium-term and long-term splits are possible, but it certainly starts to seem more likely.

Moving on, one important aspect of my posts on the matter, which I’ve written before in comments but for emphasis I will write in the post in bold, is that for the most part, my analysis is not descriptive, it is normative. It doesn’t aspire to say what will happen, but what should happen. I am advocating the view that the right to split is bigger than the details of any particular argument we could be splitting over. The right to split is bigger than the question of 1MB vs. 20MB, it’s even bigger than the question of allowing rollbacks vs. not allowing rollbacks. Personally I’m with the “no rollbacks” side (if I wanted rollbacks, I’d stick with the banks), but who cares what I think? As long as there are people who believe in rollbacks and people who do not, they have a sacred right to split off. I bear no ill will (well, not a lot) towards those who choose a different side.

I’ve been criticized with the argument that a split will never happen, because the majority side will >50% attack the minority and kill it. Sure, it could happen, and I can’t give any guarantees that it won’t happen. But why should it happen? Miners on the majority side might think they are morally justified in attacking the minority. I am here to say that, no, the minority has a right to coexist, and you are no more morally justified to attack it than banks are justified in attacking Bitcoin in general. They might also think they are financially incentivized to attack the minority, to keep their own favorite chain stronger. I am here to say that, no, they’d be cutting down the branch on which they’re sitting — by condoning attacks on minority splits, they are promoting a version of Bitcoin (again, “Bitcoin” is not just Bitcoin) were splitting is frowned upon, a version with tyranny of the majority and without the potential to evolve — a version of Bitcoin which is weaker overall.

In other words — I am afraid that split attempts will fail, and that is exactly why I try to convince people that splits are ok and they shouldn’t fight against them — to prevent the splits from failing!

Well, it turns out I was wrong. There’s no need for people like me who tell everyone that splitting is ok. If a split needs to happen, it will just happen. No ado, no fuss, no worries, and not much planning either — people cared deeply enough that they just choose to ignore the reigning authority’s version of the code, and viola, a split is born. (I’m only 40% serious here — despite everything, I still think posts like this are important.)

It’s interesting to note — but not very surprising to me, though — that apparently, there haven’t been attempts to commit a hashrate attack against Ethereum Classic.

Now, mining can be problematic even if the miners are not malicious but mere-profit seekers. If a network like Bitcoin were to split, with the two sides using the same hash function (and hence, the same hardware), then assuming pure profit-seeking miners, the ecosystem would suffer from a severe oscillation problem. What would happen is this — at any point in time, one network will happen to have a higher price/difficulty ratio. All miners will mine on this network, and none on the other network. After a week, the difficulty in the first network will retarget and double, making it less profitable. Then everyone will switch to the other network; after a week, everyone will switch back, and so on. This means that for each network, one week out of two, there will be no blocks at all, making transaction confirmation impossible. The retarget mechanism isn’t effective at balancing this, because difficulty retargeting requires blocks, and there will be no blocks in nobody mines, which is the case if the difficulty is too high and there is an immediate, better alternatives.

In reality not literally everyone will switch so readily, but many will, leading to big fluctuations in hashrate and processing rate for each of the networks. My suggestions for combating this were choosing a different hash function when doing a split, and/or improving Bitcoin’s retarget mechanism.

Ethereum itself already has an (ostensibly) improved retarget mechanism, and as far as I can tell retargets every block. Combined with faster block times, this should create a much more immediate response to hashrate changes, leading to a stable equilibrium rather than wild oscillations. By the way, this also is not a problem in pure PoS chains, which Ethereum plans to become.

This technical detail, in my opinion, is a key part of what makes the Ethereum split viable. In Bitcoin it would have been much more difficult, and without proper preparations could lead to dire consequences.

Speaking of preparations, my earlier posts advocated the position that some must be made for a split to be executed harmlessly, and it doesn’t seem many were made for Ethereum classic. It seems there have been indeed issues of ETC coins being misappropriated or lost by some exchanges, due to either malice or incompetence. But I’ve yet to hear about trouble with locally held coins. So it seems the split is faring well, its relative haste notwithstanding. Perhaps some aspects of Ethereum’s inner workings (of which many are unknown to me), like the retarget method mentioned above, helped facilitate this. And perhaps such a hasty split is perilous after all, and we have simply not yet seen the extent of the troubles it could cause.

The only question that remains is — are splits good? It’s still too early to tell. I believe that given the rift between people upset over losing $150M, and people who actually believe in decentralization, it’s good that the split happened. It’s good that everyone got to pick sides and enjoy the chain he believes in. It’s good that splits have proven to be viable, at least short-term. But again, we do not yet know what kind of ripples will propagate from this fracture, and it could end up being too divisive and harmful.

But even if the split proves detrimental to Ethereum, I still believe the split is good for the cryptocurrency ecosystem in general. There’s so much we can learn from it, and we will thrive on this knowledge.

Full series:

Part 1 — How I learned to stop worrying and love the fork
Part 2 — I disapprove of Bitcoin splitting, but I’ll defend to the death its right to do it (this one)
Part 3 — And God said, “Let there be a split!” and there was a split.

In a slideshow published by Brian Armstrong, CEO of Coinbase, he promotes the view that Bitcoin is currently undergoing a winner-takes-all elections, and that variety in Bitcoin protocols is akin to variety in web browsers.

I find this incorrect, misleading and destructive.

Unlike physical currencies, governed by the laws of nature, and centralized currencies, governed by the whims of their issuers, it’s not at all obvious what ultimately governs a decentralized digital currency such as Bitcoin. There’s the protocol and the code, of course, but those are mutable and thus adhere to a higher authority.

This authority is the agreement between people — as long as users agree to use a currency with a specific protocol, this currency exists and is usable and valuable. If users agree to collectively switch to a different protocol, so be it.

But a core part of Bitcoin’s vision is that users can also agree to disagree. If a group of users wants to use a specific protocol, they have the right to do so, regardless of what anyone else says. Nobody can force a user to adopt a specific protocol. Bitcoin is not, and never has been, a democracy, governed by majority vote. It is something much better, a plurality — the ability of everyone to choose their own path.

Of course, if the advocates of a specific protocol are too few, this will make their currency less usable. So if at all possible, users have an incentive to go with the flow, join the majority and enjoy the network effects. But if it’s not possible — if the disagreement is too severe — they have the sacred, inviolable right to split off; and it is important that everyone remembers they have this right, and not be fooled by anyone who wants them to think they must settle for the view which happens to be dominant at the time.

I used to think this was meant to be only a theoretical possibility, something that exists to keep everyone working together, and protect against rogue developers. But it’s no longer theoretical — I believe we have reached the point of no return, where we have 2 warring camps disagreeing on so many levels that a compromise will not be found. So we should split, let each faction live in peace, and make sure we do it as cleanly as possible. My views on this matter have not changed considerably since I wrote this post to the same effect half a year ago.

So much for the vision. As far as technical details go, there is indeed an instability inherent in having multiple major currencies based on the same PoW hash function. This can be alleviated by one of the sides switching to a different hash function — but in any case, it’s important to first understand the vision, then work out the technical details.

It has been suggested that in past instances of a hard fork, the network quickly collapsed on one of the sides. But this is of course ridiculous. There was never anything in the history of cryptocurrencies that even remotely resembled the situation we have now. There is no past experience to draw from. All we have is the realization that there are powerful forces on all sides of the debate which are *not* going to simply capitulate.

Finally, it’s important not to be confused between variety of protocols, and variety of software implementing a given protocol. I can use Thunderbird to send an email to someone using Outlook. I can browse a web page and see more or less the same thing whether I’m using Firefox, Chrome or IE. Analogously, I can use Bitcoin Core to send bitcoins to someone who uses Electrum — this is because both programs adhere to the same underlying Bitcoin protocol, and are thus compatible and interoperable. But the situation is very different if the sender and receiver obey different protocols — because what I am able to send is different from what the other party is able to receive.

The situation is much worse than with traditional software, because what I’m sending is not just information, but rather tokens of value. So any compatibility layer will be fundamentally financial in nature, not programmatical. Perhaps one day we will have the infrastructure for seamless conversion between different digital currencies. But until then, we should see the multiplicity in protocols for what it is — a hard split into incompatible currencies — and not muddy the discussion with naive, broken analogies to web browsers.

It would make me quite happy if a compromise is found that will allow all current Bitcoin proponents to be part of the same network. But if not, I like having the option to split, and will defend our right to do so. You should too.

Full series:

Part 1 — How I learned to stop worrying and love the fork (this one)
Part 2 — I disapprove of Bitcoin splitting, but I’ll defend to the death its right to do it
Part 3 — And God said, “Let there be a split!” and there was a split.

It’s hot in Israel in August, but not nearly as hot as the global debate surrounding the release of Bitcoin-XT and the contentious hard fork that would ensue if enough people adopt it. It seems that both proponents and opponents of Bitcoin-XT dread the possibility of the network splitting in two, and focus on making sure everyone switches to their side to prevent this from happening. Contrary to this post’s title, I don’t actually like the prospect of a fork; but I do claim that having two networks coexist side-by-side is a real possibility, that it is not the end of the world, and that we should spend more energy on preparing for this contingency.

It’s possible

Let’s start with the feasibility of this. The ways this could unfold, in decreasing order of my estimate for their likelihood, are:

1. Bitcoin-XT will not reach the threshold required to actually diverge from the current Bitcoin on the blockchain level within a reasonable time, and we will meet again for round two of the debate.
2. Bitcoin-XT will form a separate blockchain and network in or near January 2016.
3. A compromise will be reached which will make Bitcoin-XT obsolete as a separate initiative.
4. Bitcoin users will, virtually unanimously, switch to Bitcoin-XT.

Option #4 was included for completeness, but in my opinion is pretty much impossible. There is too much disagreement about the technical issues, the change in governance, and the bold forking attempt for everyone to just drop everything and tag along. The prospects for compromise (#3) look grim at the moment, the gap in philosophies seems too large to bridge. #1 is highly likely — Bitcoin-XT has support, but I don’t think enough to pass the 75% threshold. But if it does have enough… We find ourselves in scenario #2 — the unprecedented event of a significant cryptocurrency having its network, blockchain and community split in two.

It’s (relatively) safe

Is it bad? Well, yeah. First, Vires in Numeris — Bitcoin is subject to strong network effects, and two networks of roughly half the size are not as strong as one big network. Second, there’s bound to be confusion all around, with two separate currencies each claiming to be the one true Bitcoin. Third, people will think that it is bad (for both real and imagined reasons) and lose faith, stunting Bitcoin’s growth.

How bad? Let’s analyze the short-term effects from the point of view of four types of Bitcoin users:

1. The merchant that accepts Bitcoin payments. He doesn’t have to do anything about this, at all. He teams up with his favorite payment processor, as he did before, and lets the processor, and the Bitcoin enthusiast that will pay him, work out the details.
2. The Bitcoin investor. If she bought bitcoins before the fork, she needn’t do anything at all. If she bought 1000 bitcoins, she will now have 1000 coins on the Bitcoin core network and 1000 coins on the Bitcoin-XT network. Whether the currency that will survive is one, the other, or both, her investment is safe. If she considers investing after the fork, she should probably buy both, or maybe even an ETF which tracks their sum.
3. The Bitcoin enthusiast. He will probably have to carry two Bitcoin wallets around (or a special wallet that separately manages funds for both networks), and whenever he wants to pay with Bitcoin, he may have to figure out which version of Bitcoin the recipient expects. That’s extra work and trouble. But it’s okay, he can deal with it. He’s an enthusiast.
4. The Bitcoin miner. To a first order approximation, mining hashrate will be distributed between the chains in proportion to the exchange rate of each coin. This will result in an equilibrium, where it is as profitable to mine on either chain. The problem is that this is not a stable equilibrium — the way Bitcoin’s difficulty retarget mechanism works means that profit-maximizing miners can hop between chains on every retarget, making the hashrate (and block intervals) oscillate wildly. Working around this is still an open problem; it will be alleviated if miners commit, in appropriate timescales, to one chain or the other; or resolved with the painful move of switching to a different hash function.

I will talk more about longer-term prospects in the section about preparing for the fork. But for now I’d like to say a few more words about confusion. Often I’m frustrated by the obscene amount of misinformation about Bitcoin that is spread around, and then I realize that… That’s not a unique problem for Bitcoin. The world is full of ignorance, misinformation, disinformation, persistent myths, propaganda, misnomers, downright confusion, and simply people who are wrong. Humanity still hasn’t figured out an efficient way to organize the world’s knowledge to be accessible and reliable. And yet earth hasn’t exploded. We get by. We study the things we truly care about, we understand meaning from context, and we make the most out of the information available to us. So I doubt making the Bitcoin ecosystem a bit more confusing will make it collapse.

This and other concerns will, of course, have a negative impact — but they’re little more than bumps on Bitcoin’s road to success, of which Bitcoin has already had plenty and will have many more.

Furthermore, a fork was in some ways inevitable. Remember that nothing like Bitcoin was ever done before. We had physical currencies, where the rules were determined by physical laws; and we had centralized currencies, where the rules were set by a predetermined, trusted (even if untrustworthy) 3rd party. But a decentralized digital currency? That’s a strange beast, and we all signed up to the notion that what keeps it intact is consensus among people. But it is presumptuous to expect that all of humanity will agree on all the rules all the time. There are differing opinions and philosophies, and when those manifest, camps will part ways. Much like living organisms, cryptocurrencies will replicate. They will compete. They will die. They will survive. They will evolve. And in so doing, they will become stronger.

And I’m not saying, of course, that it’s good that we’re forking right now. We should still try to prevent it if at all possible. But a fork is bound to happen sometime (even if for wholly unrelated reasons), so we may as well gain some experience about the process. We could learn that forks are terrible and we should never let them happen again… Or that forks are great and we should do them all the time… We could learn how to prevent or prepare for future forks, Or we may learn something else entirely. It may be more chaotic than hoping that the mere fear of a fork will keep everyone together, but it’s certainly less rigid and fragile, and more flexible.

Be prepared

So how should the fork unfold? Ideally, the changed version (Bitcoin-XT in this case) will have a different transaction structure for txs that take place after the blockchain split, so that transactions on one network will never be valid on the other, and vice versa. Unfortunately, I have seen no indication that such a thing exists or is planned for Bitcoin-XT (a major red mark for its developers, by the way, assuming there is nothing I missed), so things might get a bit messier. Left to their own devices, transactions might be accepted by one network, the other, or both, and it’s difficult to control which.

A prudent user will consider the currencies as separate, starting from the block where the chain splits. Each will have its own balances, its own exchange rate against other currencies, its own list of places that accept it, etc. But he will need to be careful not to send currency A, and have his transaction accidentally picked up by network B, which will result in him losing his coins B without compensation from the receiver, who never requested coins B.

To do this he will need to decouple his coins into their components. The way to do this is to get some coins generated as coinbase in a post-split block (or coins that can have some trace of those) — those will function as a collapse agent, since they are valid in only one of the networks, say A. Then he will send all his coins — both pre-split UTXOs with his savings, and the post-split collapse agent — to himself. This transaction will only be vaild in network A, so in the receiving address he will have a coin (UTXO) with the total of his balance, that is strictly of currency A. Once this transaction is confirmed, his original UTXO is collapsed into currency B, since in network A they were already spent. Then he can manage his currency with two separate wallets, knowing for certain which currency he sends at any given time.

If he stores coins in a paper wallet, he needn’t worry about it at first. He can extract and decouple the coins at any time. Waiting has the added benefit that one of the networks might die by then, meaning he can claim the coins in the only network that matters without extra effort.

Of course, all of this might be too cumbersome for typical users. Ideally, there will be exchanges and wallet services supporting both currencies which can facilitate the process. Users of these services will have a separate balance for coin A and coin B. The user can simply send coins to his deposit address for the service. The wallet will credit the user’s balance for coin A, B or both depending on which networks acknowledge the transaction. The wallet will then hold superposed coins, and will decouple them as above. When the user wishes to withdraw funds, he will separately withdraw each currency to different wallets, and the service will make to sure to send him only decoupled coins. Then, again, he can know for certain which coins he has in which wallet, and use each to pay when appropriate.

If the user has strong beliefs favoring one currency or another, he can use the exchange to sell just the other currency. He can then even use the funds to buy more of his favorite currency.

The Bitcoin URI for requesting payments should include information about which coin is expected. This will be used by merchants and so on, according to the preference of their payment services provider. The user who wishes to pay can use the information to pay with the correct wallet.

Ideally, smart wallets will be developed which hold both coins A and coins B, and when given a payment request, automatically send the correct type. For example, if we are buying a product worth $280, a bitcoin A is worth $140, and a Bitcoin B is worth $70, the merchant will display either a request for 2 bitcoins A (worth $280) or a request for 4 bitcoins B (worth $280), according to the merchant’s preference. The user will just scan it as normal and have the wallet send it. Users doesn’t really need to worry about it — it suffices to make sure he always carries around both types, assuming he’s expecting to find merchants accepting either type.

Going forward, one of two things can happen:

1. One of the currencies will be significantly less popular than the other. It will see less merchants accepting it, its exchange rate will drop, and its technology will develop slowly. Users will be disillusioned by this and migrate to the other currency. Eventually it will for all intents and purposes disappear, and the popular currency will rise as the one true pretender to the Bitcoin throne.
2. Both currencies will enjoy a significant following, forever (or until the heat death of the universe, or whatever). Each will have its own advantages and disadvantages, and people can freely choose between using one, the other, or both. In this case, it is not sufficient to have software and services to handle the plurality seamlessly — the name ambiguity should be resolved, and it will be prudent for the less popular currency (measured by market cap if no better metric is found) to give way, change its name, and finish its cycle of separating from the other currency.

It will be a bit messy, but we can handle it. A fork in the road is not the end of the world.

Originally published at fieryspinningsword.com on August 24, 2015.