Category Archives: Uncategorized

There Is a Satoshi of Truth in Every Joke

(Originally posted in Bitcoin Magazine)

This rather long meme, which has been circulating lately, makes fun of the views of Bitcoin supporters by listing commonly made statements and contrasting them with contradicting statements or developments.

This was obviously intended for humorous purposes, and as such, I should probably not take it too seriously.

But as the titular proverb goes, there is a grain of truth in every joke, and the existence of this image sheds light on what some people think. I found here an instructive opportunity to dissect the arguments and share my thoughts on them.

“Peer-to-peer electronic cash” vs. “Pushing people to spend is a scam”

The former is in the title of Bitcoin’s white paper; the latter appeared in a presentation by Giacomo Zucco.

This a contentious issue in the Bitcoin community. I am of the opinion that spending Bitcoin is extremely important and should be encouraged. Others think it is unnecessary — or worse.

So in a way, I kind of agree with the image creator here.

However, one argument in favor of the latter statement is that the key word is not “spend” but rather “pushing.” Even if spending Bitcoin is great, people should be free to do whatever they want, and pushing people to do anything could be frowned upon.

“In BTC bugs like this ‘never’ make it to production” vs. “CVE-2018-17144 is the biggest bug to date”

Never say never. Where there’s smoke there’s fire, and where there’s code there are bugs. It should be obvious that anyone who said that critical bugs can never make it to production in Bitcoin was overly enthusiastic.

The only thing we can do is have a rigorous development and testing process that seeks to minimize the occurrence of critical bugs and to deal with such bugs effectively once they are discovered.

The fact that we haven’t had a bug like this in the past five or eight or 10 years (opinions vary) speaks volumes about the effectiveness of this effort.

To drive the point further: The worst bug in the past eight years is one that was fixed before it managed to have any effect at all. This can be seen as a positive sign, and I wish all bugs were as benign.

This argument should not be seen as belittling the severity of CVE-2018-17144. It was very severe: It shouldn’t have happened, the fact that it happened is a failure of the process, it undermines Bitcoin’s path to mainstream adoption, and we should study how it happened and make changes to hopefully prevent bugs as severe from recurring in the future.

“Users have to be free to run the version they want” vs. “Upgrading to 0.16.3 is required”

I think the former statement is inaccurate. The correct statement, of course, is that users can run any version that is compliant with the protocol consensus rules. 0.16.2 is not compliant with the protocol, and thus nobody should run it.

It doesn’t have to be 0.16.3, though. 0.15.2 and 0.14.3 are also compliant, as are versions of separate implementations.

“SegWit is optional, that’s why we made it a soft fork” vs. “Upgrading to 0.16.3 is required”

I think the former statement mixes up a few notions.

Usage of SegWit transactions is optional. Someone who doesn’t want to use this new feature can continue using Bitcoin just as she has so far. This is in contrast to changes that could modify or invalidate existing usage practices.

Compliance with the protocol rules that make up SegWit is not really optional. They are part of the consensus rules, and all nodes should be compliant. The fact that it’s a soft fork doesn’t change that.

What using a soft fork enables is graceful degradation. Using a non-SegWit node is far from ideal, but it does not cause the node to be immediately booted from the network. It can still understand most of what is going on in the network; in particular, those parts that are relevant to it (assuming it uses neither SegWit nor anyone-can-spend opcodes that were commandeered for SegWit).

This does not mean it makes sense for anyone to purposefully handicap themselves and use a version that specifically does not understand the entirety of the consensus rules.

But if one insists … I guess he can also run pre-SegWit versions (or perhaps a new version that excises SegWit out), as long as they are not affected by CVE-2018-17144.

In addition, there is a big difference between forcing everyone to upgrade just because we want to add a new feature, and forcing everyone to upgrade because we have found a critical security bug.

And the kicker: If we do something like a hard fork, block-size increase, any non-upgraded node will be completely disconnected.

As for CVE-2018-17144: Even though the official requirement is to patch (and you should all do that!) if someone didn’t get the memo and is still running an unpatched version, he should still be fine, as long as he waits for confirmations and almost all other nodes on the network are patched.

“There’s no way to track the growth of LN (privacy!!!)” vs. “Lightning Network is growing strong”

The Lightning Network does have the potential to offer improved privacy over Bitcoin, but there are different levels of privacy. There is complete zero-knowledge where you don’t know anything about what’s going on, other than that it follows the protocol. You can have a system where you know the aggregate total of activity, but you can’t match it to individual transactions or people. You can have a pseudonymous system where you know of all transactions, but the identity of the people involved is obfuscated. And many other variations.

With the standard way of using Lightning, you can know the number of channels and total amount of funds locked in them, but not necessarily the volume of payments done on it. So you can know that it is growing even without knowing a lot about what is going on in it.

Future usage patterns might make tracking growth harder, but not necessarily impossible.

“You need to run your own full node to help secure the network” vs. “The network is safe since all the miners have upgraded”

The former statement is a somewhat contentious topic; but it is important to distinguish what running a node does fo you from what it does for the network.

Running a node helps keep you secure, by guaranteeing that when you receive bitcoins you actually receive bitcoins, and that those bitcoins comply with the protocol you agree with.

As for how it helps the network, I wouldn’t use the word “secure.” What it does is add redundancy to the data and improve connectivity, in order to make it easier for other nodes to access it.

There is also a distinction between systemic and personal risk. If you didn’t upgrade your own node, there is always the chance you will be fooled, but that is your own problem. But if an invalid transaction is being included in a block and accepted by major service providers, that is a risk to the integrity of the currency as a whole, which is much more severe.

Miners have a key role to play here, and, as long as a supermajority of miners are patched, the systemic risk is minimal.

“BTC is secure because it has the most accumulated hashrate” vs. “F*** those selfish egoist miners”

Miners are selfish and egoistic. And they should be. The system is based on an incentive mechanism that lets agents secure the network while seeking their own financial benefits. We should thank the miners for participating in this selfish way.

The only problem is when short-sighted greed causes some miners to act in a way that harms both themselves in the long run and also the network.

Anyway, one of the things that makes Bitcoin secure is indeed the large amounts of hashrate that (selfishly) rallies behind it.

“The ledger is immutable” vs. “In case of exploit the ledger would have been rolled back”

Here we get to the interesting part — which justifies a whole article on its own, so I’ll be brief here.

The meaning of “the ledger is immutable” is that:

  1. There are protocol rules that dictate which transactions are valid
  2. The protocol rules will not be changed just for the purpose of invalidating some particular transactions that people don’t like.

But that is not what is happening here. It’s not like someone stole a private key and used it to sign a transaction that is contrary to the wishes of the original owner but is still perfectly protocol compliant … and that we now wish to reverse it.

Instead, we found out that previous software versions failed at enforcing the protocol rules we all thought we were agreeing with. The default course of action (if there are indeed such invalid transactions) would be to simply run a patched version that enforces the rules more rigorously.

The problem is that such a move could basically invalidate all blocks since the first invalid transaction, which would be catastrophic. So it could be appropriate to tweak the consensus rules slightly to handle this move more gracefully.

The significant difference is that we are implementing a systemic protocol change to fix a systemic problem and not a systemic protocol change to fix an individual problem, as we’ve seen in some other cryptocurrencies.

“In Bitcoin code is law” vs. “Bitcoin is a social contract”

The latter statement is more correct.

There is a level in which code is indeed law. As long as everyone agrees on the protocol rules, what matters is the code that runs on every node on the network and mechanically enforces the rules; not any individual deciding which transactions to keep and which to throw away.

But who decides which code to run? Who decides the protocol rules? This is deferred to a higher authority: the social contract between people who use Bitcoin and give it value, known as the economic majority. Bitcoin is what people decide Bitcoin is.

“Bitcoin is valuable because of its network effect” vs. “Reducing total usage is a way to increase full node ratio”

The former statement is true, and we’ll be hard pressed to find anyone who disagrees. Currency is not something you can use by yourself; you can only use it if other people use it as well. So a strong network is necessary for Bitcoin to have value.

As for the latter, I have not previously heard of the concept “full node ratio,” and there is hardly anyone who advocates for “reducing total usage,” so I can’t really comment on that. Indeed, the two statements seem to be at odds, and it is the former which is more sensible.

And as for that guy at the end of the meme who is so stressed out by the decision he has to make …

There’s no need for stress or anxiety. As long as we remember what Bitcoin is, why it’s here, how it works and what the fundamental principles behind it are, we should be able to tackle any challenge that lies ahead.

Between two extremes, but not quite in the middle

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.