Author: John Hardy

Bitcoin has a problem.

It used to be a geeky niché interest: a technical curiosity that only a handful intellectuals could understand, accompanied by libertarian groupies who swooned over its promise. This was an optimistic time, a community of people with different backgrounds, but one common cause.

Back then, people who didn’t understand the technology would allow those that did to get on with building it, their judgement was trusted implicitly.

Then the world’s media took notice. After becoming household name, millions jumped on the bandwagon, Bitcoin became popular.

With popularity comes problems: popular opinion is not always right.

The previous arrangement that the lead team of developers are trusted to make technical decisions is being altered. People with no technical understanding are demanding solutions which the technically minded have great concerns about.

The biggest issue revolves around the block size debate. The Core team of developers believe, amongst other things, that increasing the block size limit now through a hard fork is risky because:

1. Without optimisations the great firewall of China could struggle to pass larger blocks quickly enough which could lead greater centralisation, undermining a basic principle of Bitcoin: its decentralised nature.
2. Its not as simple as fixing ‘one line’ of code as has been suggested. Without additional work there are malicious transactions which could harm the network by alone taking over 10 minutes to verify in larger sized blocks.
3. A hard fork is inherently risky and should only be used when absolutely necessary, which right now they don’t believe it is.

The Core team of developers has decided instead to pursue other more technically complex solutions which they believe will solve the scaling problem in the best long term interests of Bitcoin. Everybody is in agreement that Bitcoin needs to scale.

This has been countered by various alternative solutions by developers who have not demonstrated the same technical skill, but have shown themselves better equipped at engaging and appeasing the masses.

Let’s consider what that means. Imagine you’re starting to feel ill. You go to the doctor who tells you not to worry as there is a pill that will leave you feeling a little unwell in the short term, but to take it easy for a few weeks and before long you’ll be feeling better than ever.

Outside the doctors surgery is a stall set up with a crowd of people who have been whipped up into a frenzy hailing a miracle cure that will make everything better. The doctor warned you about this, and said that the cure offered might make some of your symptoms disappear in the short term, but in the long term it could cause serious and irreversible damage to your health and we cannot yet be certain of the side effects.

At the moment, the Bitcoin community looks like it is heading towards the latter option, ignoring the advice of the people who have delivered near perfect health to the network for the last 7 years.

Scientific truths cannot be determined by consensus.  If bigger blocks do slow down block propagation and jeopardise the integrity of Bitcoin, it doesn’t matter if 100% of users think that it won’t.

Ultimately, yes, there are very capable people who think the block size can be safely increased. However while popular opinion consensus is very easy to measure, it is almost impossible to measure intellectual consensus.

The Core developers are the only people with a proven track record. This means, for me, they represent scientific consensus. Deviating away from their leadership leads us into uncharted waters. This dispute is about more than a tiny change of code, it’s about the direction of Bitcoin, and whether scientific consensus can be superseded by the free market.

If you are concerned that full blocks will cause the network to struggle, and a temporary fee market to form that will have a major impact, why not give the core team a chance to prove you right? Bitcoin is still experimental, temporarily seeing how it performs at the limits of capacity could provide very useful lessons for the future. If the network does start to struggle, intellectual consensus will form very quickly around increasing the block size, but it is not there yet, despite all the debate.

Sadly, I feel like a block size increase against the wishes of the Core developers is increasingly inevitable. I don’t actually think this block size increase will cause measurable harm in the short term. The harm comes further down the line once the precedent has been set, and empowered by being “proven right on the block size debate”, the masses demand further compromises of an inexperienced team of developers willing to please.

The problem with Mike Hearn’s “resignation letter” is that its full of contradictions. One the one hand he suggests “Bitcoin … has always been advertised pretty accurately: as an experimental currency”, and on the other he’s proclaiming Bitcoin has failed due to things like unpredictable fees and payment backlogs – are these not just characteristics of an experimental currency?

Another complaint he makes is that Chinese miners have a majority of network power, and consequently do not want to increase the block size because it will make it harder for them to compete. This to me is either naive or wilfully misleading. If an increased block size struggled to pass through the firewall, the side of the firewall with the greatest hashing power would benefit most (the Chinese side), as the other size would end up producing more orphan nodes. Nobody wants this, including Chinese miners, because it will damage the integrity of Bitcoin and people are willing to wait and try other solutions first.

Even if a new team was built to replace Bitcoin Core, the problem of mining power being concentrated behind the Great Firewall would remain. Bitcoin has no future whilst it’s controlled by fewer than 10 people. And there’s no solution in sight for this problem: nobody even has any suggestions. For a community that has always worried about the block chain being taken over by an oppressive government, it is a rich irony.

The rich irony here, is that increasing the block size through XT would actually exacerbate the problem, and that Mike seems oblivious to this.

Ultimately, having lost in the battle of consensus, Mike Hearn has taken his ball and gone home. Bitcoin XT could not gain consensus because enough people believe in the Core team’s vision for a more graceful and innovative solution for scaling Bitcoin, rather than clunkily just bumping up a number and hoping for the best.

Yes, its fine to be sceptical of Core’s vision, but the beauty of Bitcoin is that if SegWit and LN do not deliver on their promises, consensus will soon form around an alternative. In the mean time, if transactions slow down and the network fails, consensus may form sooner. Bitcoin is not dead, people recognise it is in an experimental phase and will be prepared to be patient. One day Mike may well regret not having a little more of it himself.

There are reasonable criticisms on both sides of the block size debate, the censorship and DDOS has been concerning, but so has the wilful misinformation coming from the other side. Even in his parting shot, Mike labels SegWit as buying a few months at most, ignoring the fact that it extrapolates onto all future increases in block capacity. For perspective, XT’s proposal of a 8MB block size would effectively be an increase to 13MB under SegWit, hardly the anaemic increase Mike describes, and far more clever than any solution he has come up with.

For Mike’s early contributions to the Bitcoin experiment, we should be thankful. However given the choice between those quietly getting on with it, and those who loudly shout about their ideas and then run off crying when they don’t get their own way, I know who I’d entrust with the future of Bitcoin.

I’ve recently started blogging about Bitcoin. If you liked this article please check out my others. Any questions or suggestions, let me know in the comments. Tips welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

In my last article, I asked whether there was a third way to increase the block size limit that wasn’t quite a hard fork and wasn’t quite a soft fork.

I think its important to follow that up with a critique, there are two sides to every story.

It has been pointed out that what was proposed was technically a type of soft fork, so I will refer to it as such. This idea has been discussed on the bitcoin-dev mailing list and while on the face of it, it’s an appealing idea, perhaps even a no-brainer, things aren’t as straightforward as they may seem.

There is technically no reason increasing the block size through a soft fork cannot be achieved by simply creating new larger blocks that are invisible to old clients. These clients are consequently still connected to the same network but not able to participate fully. This would only require a majority of mining power upgrade to be successful.

Its very easy as somebody who doesn’t have to get their hands dirty with the code to sit back and suggest that a solution like this seems obvious. Why would we risk hard forking when we can do this instead?

In reality there are a lot of things we can do in coding, the question to be asked is whether something is worthwhile.

I once built an eLearning course where the client required a progress indicator in the corner of the screen. This was easy to implement by simply positioning an image along an axis. The client, however, decided they would prefer a gauge with an indicator working its way along an elliptical curve. The project manager, with no coding experience, decided this would not be a problem and approved the change. They had only envisaged a couple of graphics changes.

What had been a simple bit of code became a far more complex mathematical procedure. I had to dust off my old trigonometry text books and, after a frustrating morning, ended up with a hacky bit of code which got the job done.

What had been gained? Very little. The graphic did exactly the same job, albeit moving along a slightly different path. Was it worth it? Absolutely not.

One problem of increasing the block size as a soft fork is that it’s hacky. We’re building a protocol that we hope will still be going strong in 100 years time and beyond. Everything we do now is irreversible, forever locked in to the protocol and requires thoughtful contemplation.

If we implement everything as a hacky soft fork, it requires a compromise in the code. Does a piece of software that has ambitions of being used and recognised as the most important tools of the technological age want to become littered with clunky IF statements?

There’s a trade off to be made though. Isn’t a soft fork still ‘safer’ than a hard fork? Isn’t the primary objective of Bitcoin to be secure? The average user will never see a line of its code in their life, what does it matter if its a little hacky as long as it works?

What are the consequences?

Let’s examine some undesirable consequences of a hard fork. Many argue a soft fork would prevent people from losing Bitcoins. The argument goes that hard forks risk splitting the network in two, with people transacting on both networks following a split. Merchants who receive a payment on the “losing” side of the fork may, for example, ship out an item, only to later realise that the network they received the payment on has been abandoned, and they never actually received payment on the winning network, leaving them out of pocket.

This happening would undermine confidence in Bitcoin. It would easily translate to damaging headlines “people lose money as Bitcoin splits in two”. We have to ask though, would this really happen?

This scenario presumes that Bitcoin has split relatively evenly, and is conflicted about which side of the fork will “win”. In a worst case scenario there would be two networks with 50% of mining power each. With a halving of mining power for each network, blocks would initially be created around every 20 minutes – the capacity of the network would temporarily be cut in half. A 50/50 split in mining capacity has no connection to which side of the fork the majority of users are on. Interestingly, transactions would still be sent around the entire network, and the majority would probably find their way into both sides of the fork, it would take an effort by an attacker to get a transaction included in one network but not the other, so there is some sort of built in protection from such a loss on a wider scale.

That scenario assumes a 50/50 split of mining power. Any hard fork that only requires 50% of mining support would be reckless and unlikely to achieve consensus.

Far more reasonable would be a requirement of 95% mining consensus before implementing a hard fork. In this instance, the network would split in two, but on the “losing” side of the fork, the loss of mining capacity would substantially extend the time it takes to mine a block, from 10 minutes to around 2 hours. It’s reasonable to imagine that any miners still on the old network would very quickly upgrade as otherwise they are wasting a lot of money. This would cause the old network to grind to a complete halt. Its quite possible that such a sudden loss of mining capacity could result in the old network never successfully mining another block again, ever.

In this scenario, it looks far less likely that anyone on the old network would lose money as long as they are sensible about waiting for transactions to confirm, which they never would. Effectively the outcome is not dissimilar to what we are trying to achieve through raising the block size through a soft fork, the difference is instead of possibly degrading a little more gracefully, their old software would essentially stop functioning until they upgraded.

When or even if we should increase the block size is a completely different discussion I will have another time. The case against increasing the block size through a soft fork, I now feel is strong. Hacky code has its place, but Bitcoin can do better.

Perhaps instead of adding one off hacks to the code each time we want to raise the block size, we can code a soft fork that is re-useable in the future. Instead of adding manually nested IFs to work our way through various block sizes we have preserved, we can have an array of block sizes and their activation points. This would have the effect of making block size expansion as simple as adding an item to an array, and each time we increase the block size we can enjoy the benefits of preserving some legacy function and avoid a hard fork. But then again, this is easy for me to suggest, as I’m not the one coding it.

I’ve recently started blogging about Bitcoin. If you liked this article please check out my others. Any questions or suggestions, let me know in the comments. Tips welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

The “blocksize debate” is currently a hugely contentious issue within the Bitcoin community.

Simply put, the blocksize limit is a cap on how many transactions can take place every 10 minutes and is currently limited to as many as will squeeze in a 1MB block.

There is an entirely different debate about how much or even whether this limit needs raising, but here I will solely be doing my best to explain one of the ways a future block size increase could be achieved.

To begin with, I need to explain the difference between a hard and soft fork.

It relates to backwards compatibility. Imagine you and many others are playing an online game where you all roam around a virtual world together collecting flowers to score points. You’re all trying to achieve a high score.

One day, the game releases an update, and adds mushrooms to this world. Just like flowers, the mushrooms can also be collected to score points.

How this upgrade is implemented can be compared to a soft fork and a hard fork.

If the upgraded version of the software is not compatible with the old version, you have a hard fork. In this situation, anybody who updates their software will be in a new world, we’ll call it mushroom land, and anybody who has the old software will be in flower land. The people in mushroom land know they arrived there through an update. Back in flower land, people may wonder where all the other players disappeared to, but will continue to continue playing amongst themselves, not realising that everybody else is playing an updated version of the game, and that the high scores they’ve worked so hard to achieve will be lost when they eventually realise that they need to upgrade to mushroom land.

If the upgraded software has backwards compatibility with the old version, you have yourself a soft fork. In this situation, maybe people with the upgrade can see mushrooms, but to those who haven’t, the new mushrooms just look like more flowers. Crucially, people with the old software can still play with those who have upgraded, and even though the world looks a little different – ultimately everybody is still playing the same game.

So is there a third way?

Maybe there is. Let’s imagine that for technical reasons there is no way mushrooms can be introduced, even as flowers, without a software upgrade. Perhaps though, all players can participate in the same virtual world, except that those with the upgrade can also see mushrooms, while those without cannot. Crucially, people are not playing a completely different game, and when someone in flower land does upgrade they can take their score with them, and start collecting mushrooms without losing out.

How can this be achieved in Bitcoin?

Instead of just losing points, a worst case scenario for a Bitcoin hard fork would be people losing money. Whatever happens, there must always be a block produced with 1MB or fewer transactions, otherwise Bitcoin will hard fork as old software will not recognise the new block.

So how do we prevent anybody losing money? We create a mushroom block. This mushroom block can be larger than 1MB. The existing 1MB block remains in place as a legacy block. Transactions that make it into the legacy block can be viewed by everybody on the network, those in the mushroom block can only be seen by those who have upgraded.

Once any Bitcoin has made its way into a mushroom block, it can not be viewed or spent again by software that has not been upgraded. This isn’t quite a hard fork though as people on the old software will still be participating in the same network, they just won’t be able to see all the transactions that are actually taking place. If they try and spend Bitcoin that appears to be theirs on the old software, but actually has been spent on a mushroom block and belongs to someone else, all that will happen is that the miners will reject the transaction and they will not be able to spend it.

Ultimately, this is not ideal, and while it would no doubt create confusion, it would not create a complete hard fork and should not lead to anybody losing Bitcoin.

The only people who would actually need to upgrade for this to take place would be the miners. Technically speaking, they could have already done this and none of us would know. Since mining is far more centralised and dominated by a smaller group with a huge financial stakes, it is likely that such an upgrade could be achieved rapidly, once the software is ready of course. For everyone who hasn’t upgraded, Bitcoin would just become increasingly less useful until they did so.

There are a few ways this type of upgrade could be implemented. In its harshest form, the 1MB block could be mined empty with all transactions occurring on the mushroom block. You would think people would start to upgrade pretty quickly as this would basically be a forced upgrade as their software would be useless to them. More reasonably, transactions generated by older software, and with the highest fees should be included in the smaller block, while those who have upgraded could be rewarded with lower fees having their transaction included in the upgraded network where there is more capacity.

When or how a block size limit will increase remains to be seen, but here is a very simplistic explanation of one way it could be achieved. There are no doubt many technical obstacles and reasons why this concept may not be viable, but I wanted to at least try and explain the principle, I hope you’ve found it helpful.

For a far more technical explanation, credit to ZoomT, head over to BitcoinTalk.

I’ve recently started blogging about Bitcoin. If you liked this article please check out my others. Any questions or suggestions, let me know in the comments. Tips welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

Bitcoin is a complex beast, and if you’re like me, you’ll often tie yourself up in knots trying to explain it.

So I decided to set myself a challenge, to best explain the basics of Bitcoin in 100 words or fewer. Here’s my effort:

Alan has $1000 and wants to pay Barbara $500.

Currently the bank updates Alan’s balance in their database to $500, and Barbara’s to $500. We must trust the bank to be honest.

In Bitcoin, Alan writes a note saying he wants to pay Barbara $500 and sends it to everyone.

Everybody also keeps a copy of every single valid note that has ever been written (the blockchain).

Everybody checks through their old notes to make sure Alan has $500 to send, and if he does they add his note to their collection.

For privacy and uniqueness, Alan calls himself 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE.

What do you think? Feel free to have a go yourself in the comments, maybe we can crowd source an elegant way to effectively explain Bitcoin. I may try and explain a few other concepts around Bitcoin in 100 words or fewer, so look out for those.

I’ve recently started blogging about Bitcoin. If you liked this article please check out my others! Tips welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

There has been an uneasy tension simmering in the Bitcoin community over the blocksize – the limit on how many transactions can take place every 10 minutes, which is increasingly being reached.

Initially I was attracted to the idea of increasing Bitcoin block sizes. My frustration at the core team was palpable; it seemed such an obvious thing to do, Moore’s law superficially makes 1MB blocks in 2015 sound pathetically small.

Then I took the time to wrap my head around the technological arguments against increasing the block size (centralisation, scalability) and my view was transformed.

I am now completely on board with the core team vision: elegant solutions such as segregated witness (SW) and lightning network (LN). I realise ingenuity and innovation is going to save the day versus the comparatively clumsy solution of a block size increase.

I use an SSD in my laptop and haven’t run a node on it for over a year, since space is at a premium and in order to continue participating I’d have to pay for an upgrade. This exact same scenario is about to play out for Bitcoin transactions.

I have concerns… on one hand I have been convinced of the technical argument for avoiding increasing block sizes, and am incredibly excited about LN. I am prepared to patiently wait for these solutions to be implemented and solve Bitcoin’s long term challenges.

On the other hand, we are heading into unchartered territory. Bitcoin is being advanced on two fronts, we are building a revolutionary technology, and we are building a public vision of what that technology can do.

These two battles require very different skills, and triumph in both is essential for Bitcoin to succeed. If you have the technology but fail on persuading the public, you’ve got yourself a Betamax.

Bitcoin has a problem in that the community hasn’t been persuaded, let alone the public.

The core team state that anybody who disagrees with them is free to build their own competing solution. While technically true, this is disingenuous. The barriers to and reasons against a split are vast, the momentum and status quo is with core. However, even more importantly, the core team HAS WON the technological debate. Their solutions aren’t just the best for Bitcoin, they are a necessity for Bitcoin to succeed and scale.

I’ve been evangelising Bitcoin for the last 4 years. Our winning line is that you can send money very quickly and very cheaply. In a recent discussion with someone who works in ‘the city’ and had clearly done some Bitcoin homework, the technology was dismissed and I was told “Last week it took around 6-10 hours for a 40c fee or $2 for something quicker”. The fact this is incorrect is irrelevant, in the battleground of ideas, people switch off easily.

In Bitcoin we need to switch on as many people as possible. A fee market can create the very real possibility of slower transactions and higher fees. Anyone with an anti-Bitcoin agenda can use it as a stick to beat Bitcoin with for long after the issue has been resolved. Once someone has seen a headline and been turned off to an idea, it’s a lot more difficult to re-engage them.

So, what’s the solution?

Increasing the block size is not an option. Even if the code was released today, it would still require a lengthy wait before the increase could be activated to give as many nodes as possible the opportunity to upgrade – a hard fork should never be undertaken lightly. By that time, we should already be seeing the benefit from other the solutions the core team are pursuing and block size issues should be solved.

In the short term, like it or not, we’re about to enter a period where the utility of Bitcoin is going to be negatively affected. As a community we need to shape the public narrative, we need to sell the exciting developments that are around the corner. This should be easy… truly revolutionary developments really are coming. Let’s get behind and give our support to the core developers, they are going to deliver on their vision, now all we can do is rally behind them.
I feel bad for the core developers. These are technology people who have undoubtedly have Bitcoin’s best interests at heart. They have also had politics thrust upon them when they are not politicians.

They can also learn from this experience though. I recently saw a comment from a core dev which said he didn’t care about Bitcoin in the short term. If you believe the long term of health of something depends on the short term, as I do, this language is troubling no matter which side of the debate you are on.
The community and developers need to understand each other better. The community has been worrying about block limits creating a fee market for years. A fee market also requires a political/economic consideration, not just a technical one.

Perhaps the current dynamic, ‘developers’ and ‘users’, cannot be sustained in its current form. I think we need a level of mediation, a political layer which can represent the interests of all Bitcoin stakeholders and articulate to both sides why their approach and opinions are important and stand a better chance of reaching consensus and sooner.

In the current climate, I feel a compromise of 2MB blocks to keep the metaphorical wolves from the fee market door while SW and LN are introduced would bring the community together – the problem is, the time we would have needed to reach that consensus in order to get the wheels in motion, the community was suggesting wild block size increases and would never have compromised on 2MB, but will now also feel they are having a fee market imposed upon them.

Let’s embrace what we’ve got. Yes, we’re going to have a fee market and no doubt other bumps along the way, but we also have a core team whose hard work and ingenuity are laying the foundations for Bitcoin to become truly scalable and world changing. On our two battlefronts we can be certain we are winning on the technology side. We just need to make sure the whole community is singing from the same hymn sheet so that together we can generate a tidal wave of positivity and surf our way to the… future (and moon).

This is my first article on Bitcoin, I’m probably going to start talking a lot more about it and attempting to explain some of the basics. Tips welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE