I’ve gone to quite a lot of trouble to write out my advice for the core developers at Bitcoin.
I realise it’s lengthy and somewhat daunting and we all have constraints on our time, but I’ve taken the time to write it, so if you’re involved in Bitcoin do me a favour and take the time to read it
The first half is mainly context for anyone who hasn’t been following Bitcoin closely. If you don’t need that, skip down to the second heading that ends with “potential split” – most of the detailed advice is right towards the end.
For those who haven’t heard – Bitcoin has suffered a serious rift over the last few months, culminating yesterday in Mike Hearn (one of the small team of core developers who look after the project) storming out in a bit of an angry cloud; saying bitcoin was an experiment that has failed, and he effectively washes his hands of it. This caused a 15% drop in the price of Bitcoin.
As a result of this, I did some research to work out what’s going on. – Although I use bitcoin, and know it well from a currency perspective, like a car, you can drive it around perfectly fine without ever looking under the bonnet (that’s the “hood”, to all you American folk). Until now I understood the basics of how it worked and never really delved too much deeper, either into the specific code that holds it all together, or into the organisational structure responsible for maintaining it – I just kinda assumed all that had been pretty well sorted out – clearly I was wrong.
Now Mike Hearn is wrong, Bitcoin isn’t dead, it’s very much alive – there are hundreds of companies with investment in the technology, ranging from tiny tech start ups that have grown directly out of the block-chain, through to the organisations that run the exchanges and wallets – beyond that you’ve got some quite major players who have put time into accepting Bitcoin as a payment method, and the thousands of users who are following it either for the purposes of speculation, or simply out of curiosity for the technology. Bitcoin has actually got quite a lot of weight behind it at the moment, it’s spawned an entire industry, all of which to some extent or another has its fortune entangled with that of Bitcoin itself.
In short, there are probably hundreds of thousands of people with some level of investment in Bitcoin and its associated technology, many of whom are eagerly supporting it as an alternative to the status-quo – a vote against “the system”. Bitcoin represents a economic, social and political movement, of far more importance than the finer details of how the system is implemented technically – it’s like arguing over how many tiny dots to place around the queen’s head on a one pence piece. Bitcoin is a belief, a philosophy, and a challenge to the mainstream, many people passionately support it as an idea, not as a piece of software. This is why Mike’s blog post made such a big impact – it tramples on dreams. People see Bitcoin going somewhere, it’s depressing to be told it’s a dead end.
Bitcoin is not dead, not by a long way, but it is in very real mortal danger.
So what’s all the fuss about anyway?
I’ve gone to the effort of picking apart the technicalities of this rift that appears to have formed among the core team of developers. Ostensibly, the disagreement came out of an argument over what to do about the block size limit.
I’ll try to explain this problem in simple terms (if you’re already familiar with this, skip the next couple of paragraphs). The block-chain is effectively a ledger – every time some amount of bitcoin is transferred from one address to another, an entry is recorded in the block-chain, and the block-chain is magically distributed throughout the network such that there can be no argument about what’s on the ledger – once a block has been encoded, it’s there permanently (due to some clever crypto voodoo that we won’t go into right now).
Now, as a detail of the way the original developer chose to implement Bitcoin, the block-chain (which, remember is really just a ledger (transaction log) – a list of items saying (effectively) “Kieran transferred 1 bitcoin to Bob at this precise time” – that log is divided up into individual blocks – think of each block like a page in a ledger book. Before a transaction is visible on the network, the transaction must be included in a block, and that block must be distributed to all the members of the network. If you use the book analogy – you can tear a page out of a book, photocopy it and give it to someone, and that page might contain a few hundred individual entries on it. There’s no easy way to send individual transactions or smaller units – you wouldn’t send someone half a page, you send them the full page even though there’s nothing written on half of it – it’s the smallest unit you would reasonably send someone – one page.
So, with that bit of background explained – here’s the problem: blocks are a fixed size, plus, due to the nature of the network: there is a limit to the rate at which blocks can be added – this means there’s a ceiling to the number of transactions that Bitcoin can actually process within a given time frame. In the earlier days of Bitcoin, those blocks were largely empty, there simply wasn’t enough transaction volume to cause a problem – you were in effect photocopying large pieces of paper with only a few lines in the top left corner. Suffice to say, that is no longer the case, now we’re regularly seeing a situation where the entire block is full, and transactions are being queued for the next block – sort of like a traffic jam building up. This is detrimental to the performance of the network because transactions will take longer to confirm, and, left unchecked – this limitation will stifle the growth of the technology.
As computer scientists it makes us uneasy that the block-chain ledger is filling up and transactions are getting queued – that doesn’t feel good to a programmer because it’s the kind of thing we experience when our server isn’t fast enough to handle our application – it means you need a bigger server, and it shakes your trust in the system. But to an economist, the ledger being full is not necessarily a problem. Supply and demand, first rule of economics. Until now supply of space on the ledger has far exceeded demand, but we’re hitting the point where that’s no longer the case – we now have a limited supply and a steadily increasing demand. Supply and demand is by nature a self-regulating system, people won’t pay more than they consider reasonable, so transaction costs probably won’t spiral out of control, and to some extent the demand will be moderated by load on the network.
Think of it like a public transport network – if you find the bus is always overflowing with people when you try to use it, some of those bus users will inevitably end up buying a car and giving up on the bus, thus bringing the number of people on the bus down, making it more tolerable, there’s an element of feedback which makes the system self-regulating – this is where it becomes stifling to Bitcoin though – if users are finding alternative options as a result of the delay in processing transactions, Bitcoin is in-effect losing market share. However, no evidence is telling me that we’re anywhere near that point yet – I think we’ve got a fair bit of margin before the sky comes tumbling down.
My obvious and immediate reaction to all this was “well if the block size is a constraining factor, just make the block size bigger” – problem solved. I can therefore completely sympathize with Mike Hurd’s obvious frustration when he tried to increase the size, and realised that he couldn’t get all of the other key developers to agree with him. Mike paints a very black & white picture in his blog post – either you increase the block size as soon as possible, or you are completely impotent and doomed to go the way of the dinosaurs.
It would be easy to be swept up with Mike’s worldview. However, the truth is, it’s a bit more nuanced than that. Firstly, I think really we’re talking about the difference between raising the block size now, or waiting a bit and then raising it at a later date, or finding a different technical solution to the problem. I don’t think anyone would seriously suggest we intend to live with this particular limitation forever. The other developers didn’t obstruct the change out of malice, they had their reasons for thinking sticking with the status-quo was the best course of action at the present time.
I’m not going to delve massively deeply into this, but I’ve worked out a few good reasons why you might decide to take a “wait and see” approach. The most obvious one is that the block-chain is already a *massive* set of data, it’s already quite unmanageable, if we double the block size, we’ll double the amount of data that we’re adding on a daily basis. Furthermore, there’s some argument to say Bitcoin could do with some structures of intrinsic regulation – it might make it more stable. The supply and demand system that would result from space scarcity within each block is a self-regulating system, we know this from simple economics – if people want their transaction done quickly, they will pay higher fees, but they’ll never pay more than they think it’s worth, because who does that?
Also let’s not forget that until now transactions on Bitcoin have been effectively free – miners get paid because the currency automatically dilutes itself in order to pay them – this is, in effect, a tax on the network that everyone has to pay in the form of a devaluation of the currency (hey, if governments are doing it, why shouldn’t bitcoin?) – In order to send money from one address to another, though – until now, that’s basically been free, the cost of mining is absorbed into the wild price fluctuations of the currency, and everything else, well it’s basically just not paid for.
When you think about it though, that’s a perverse system – Bitcoin requires resources to run, all systems do, you don’t just get something for nothing in life. Bitcoin is software, it has to run somewhere, and the machines that it runs on have to be paid for. I’m not just talking about the mining rigs – they’re already paid for by the payout lottery and the automatic dilution of the currency (for now), the costs I’m thinking about here are the CPU time on all the nodes in the network and network bandwidth used by bitcoin nodes talking to each other – the hard disk space taken up by multiple copies of the entire block-chain in many locations around the world. Ultimately Bitcoin requires quite a lot of infrastructure, and most of it is currently “on the blag” (to my American friends – that means it has been sponging off its parents for a bit too long and it’s about time it stood on its own feet).
Fundamentally, what we have here is a limited resource – yes, we can increase the block size, and that will mean you can get many more transactions processed within a block, but the point is, processing transactions incurs a cost, and that cost is not being properly reflected in what people are actually paying. Follow through to its conclusion, you realize that it’s actually quite dangerous to allow the system to continue to grow, while the costs of running it are not being properly reflected in its financial mechanics. If you want an example of why it’s a bad idea to sweep costs like this under the carpet, take a look at the big polluting industries, like fossil fuel-based energy generation for example – what you see there is an entire financial system based around a model which leaves out one of the biggest costs of the whole thing! Fossil fuels are cheap because their costs are defined entirely in terms of the short term – digging a mine or floating an oil rig cost a lot of money, sure, but they pale in insignificance compared to what your costs would be if you had to pay future costs to all of humankind. The economic model is broken because it does not factor-in the single largest cost – the debt you owe to future generations for screwing up their climate! If you forget to include costs like this, it always comes back to bite you later – this is what happens when you don’t properly identify and account for all the resources that your system is using – system goes evil and destroys the planet! Of course “Carbon Credits” are a very crude attempt to put a price on destroying the planet to re-balance the relationship, but we’ve left it a bit late and we’re probably going to need more extreme measures.
Okay perhaps a slightly facetious analogy, but being pragmatic for a moment let’s look at the actual facts – yes blocks are sometimes entirely full, and that’s not really ideal. However, the system is not actually broken, it still works fine, and there’s no reason to think we have to be immediately worried that things will grind to a halt. Plus, the system has never reached this stage before, and we don’t know exactly what will happen when ledger space becomes a commodity – there’s no real harm in leaving the system as-is and finding out, then perhaps making a change when we’ve more of an idea what we’re dealing with. After all, Bitcoin is an experiment right? Wouldn’t you like to know what happens when ledger space becomes a limited resource? If anything does go wrong, it will go wrong fairly slowly and we’ll have time to sort it out. Sometimes it’s bad to rush into action before you know what you’re dealing with – a conservative approach is to stand back and observe the situation for a bit before you dive in.
So in other words, although we’re filling blocks and, as a result, transactions are getting queued and delayed before they make it into a block-chain, we’ve got a little way to go before the entire system grinds to a halt, any urgency is really false urgency. Also, there are valid arguments on both sides, and it’s not a clear-cut situation where you can definitely say “this is the correct thing to do”. Nobody knows precisely what the correct thing to do is, so there are bound to be some disagreements.
Bitcoin needs to be really smart about how it manages its resource utilisation in future releases – if it places too much burden on the infrastructure without having the means to pay for what it uses, it’s just completely unsustainable. We should take our time about deciding to make major changes, if we can possibly delay it to give us more time to collect data and contemplate how to design it – we should take all the time we can. Somewhere I saw suggested the idea that the block size would just double at regular intervals, exponentially increasing to infinity. That did not strike me as a particularly good idea. The block size should only be as big as it needs to be, no bigger, for efficiency reasons, which means whatever scheme we put in to control the block size should increase it in steps, only when required – with exponential growth, the block size will quickly become large enough to start causing problems. There’s lots of shades of gray here, it’s far from a clear cut either/or situation.
So that’s my understanding of the current technical disagreement that’s triggered a potential split.
The real split in Bitcoin is social though, not technical.
Although on the surface the split seems to have been caused by this disagreement over whether to increase the block size or not, actually, that was just a trigger, when you think objectively about it, that decision really doesn’t threaten Bitcoin either way, it’s a complex decision that involves economics and finance as well as programming, and there’s bound to be a spectrum of views. Within most corporate environments, these kinds of situations are normally dealt with by sitting around a table and thrashing it out, and if consensus can’t be reached by the end of it, then a majority decision settles it – with the boss or whoever’s in the most senior position having the final say and often the ability to overrule a team decision; “If the boss says this is what we’re doing – this is what we’re doing.”
The threat to Bitcoin isn’t anything to do with block size, it’s not even a technology problem – the technology has some limitations but ultimately it’s working pretty well. The problem that could cause the whole thing to collapse, is the fact that there is no formalized method for deciding disputes, no hierarchy or structure, just a bunch of guys with differing opinions and nobody to act as referee. This is true of all organisations when they initially start out – with just a small number of people, and steadily grow, they will eventually reach the point where they need to start implementing structure – departments, chains of command, rules, regulations, etc. All small organisations have to go through this process, and it’s often a painful one, but Bitcoin has it worse than most – the project sprung from just one man(/woman/group), the illusive Satoshi Nakamoto, Bitcoin was his brainchild and he would’ve been its natural leader. But for reasons best known to himself, this figure has disappeared from the public sphere, leaving Bitcoin entrusted to, well, whoever he could convince to take on the responsibility at the time. A group of somewhat reluctant developers who probably feel a little burdened by the duty to keep the system going.
In effect what we have with Bitcoin is an Empire that lost its Emperor – it does not have that cohesive force that would bring things together, it does not have its “Steve Jobs”, “Bill Gates”, or “Linus Torvalds”. It was abandoned at birth, and left in the care of a team of people perhaps not best equipped to take on the task. Organisations need that guiding force to rally-around at this stage in their development – someone to lay down the law and say “this is how we’re going to do things from now on”. As an organisation grows, it must implement structure otherwise it will become unmanageable. I believe this is basically what’s happened with Bitcoin – nobody is in charge, it’s just a free-for-all, rife with frustrations, resentments and anger.
Unfortunately Opensource projects are somewhat more prone to coming a cropper at this particular stage of organisational development. There are many many examples of Opensource projects that were forked as a result of some fundamental disagreement over the future direction of the project – exactly like the “shall we increase the block size?” issue – it’s quite normal for disagreements over things like that to cause angry in-fighting and a lot of resentment between the two warring parties. Of course one of the big advantages of Opensource code, is that, because the code is available, if you disagree with the direction the project’s going in, you can always take the code and start your own version. This is called “forking”, and it happens a lot – people are talking about it potentially happening with Bitcoin.
Opensource evangelists use the ability to “fork” to highlight the advantages of Opensource development over traditional commercial software – you can’t just go in different directions if the project you’re working on is a commercial piece of software – if you disagree with the direction you’re being told to go in – tough, sometimes you just have to deal with it or leave, and of course if you leave, you can’t take their code with you! Software is the intellectual property of the company you work for, and when you leave, it’s entirely theirs and you have no claim over it. Opensource is different because everyone has equal claim over the code – it makes it easy to split an entire project over disagreements, because you can both take the code with you, neither side has to back down and accept the other’s will – people are less willing to compromise, because they’ve got less to lose, they can walk away and still take the project with them.
Of course, we all secretly know that forks aren’t really a good thing – when a project is forked, 9 times out of 10 it’ll be because two of the core developers have had a major disagreement and the situation has often become fairly acrimonious. This is actually a weakness of opensource software, not a strength. It means just at the point a project should be growing and building a management structure, instead it often divides into two separate tiny entities, which then continue to go off in their opposite directions, still not having built any management structure, and now each of the two child projects is diminished in its scale by half. It doesn’t normally benefit the project for it to fork, and coming from the world of commercial software development, some of the types of technical disagreements that have been known to cause forks seem so trivial to me – if those kinds of disagreements happen in the world of business you’ll discuss the relative merits of each side of the argument, and then somebody will make a decision and that’s that – under good management, disagreements aren’t allowed to fester on indefinitely.
This is where Opensource projects fall down so easily. More often than not an opensource project is run by a group of 3-4 developers, all with roughly equal status relative to each other, and none having an absolute right to overrule another. In projects where it all started from an individual programmer’s initial idea, he will often come out as the de-facto leader, and that’s what has allowed Linux Torvalds and the Linux project to be so successful. But the problem you get with teams of programmers is that often none of them are natural leaders – programmers like technical detail and accuracy, but sometimes struggle with seeing the big picture and making strategic decisions. Without the ability to defer to authority, Opensource projects have no arbitrator to settle disputes, and to some extent the boundaries of professional conduct get stretched in the heat of the moment too – I’ve seen Opensource developers rip into each other online in ways that would be considered quite inappropriate in an office environment.
There’s a sort of romantic idea that opensource development is some kind of Utopian hippie commune, we don’t need order, or authority, or a business plan, or an organisation structure, or any kind of organisation at all really, just love and peace and flowers in the hair etc. Unfortunately hippie communes work much better when everyone smokes a lot of weed, guess it stops arguments breaking out. Sadly it’s quite hard to write code while you’re stoned, so Opensource development often ends up quite tense. I wish it weren’t the case, but unfortunately our entire social structure and sense of how to interact with the world is based around an implicit hierarchy, observance of rules and doing what you’re told. Take that away and humans get a bit lost. There’s a reason every game of football has a referee. Without someone in charge, things quickly turn ugly. Programmers often don’t naturally organise themselves into a hierarchical structure though – in some cases totally opposed to any form of authority.
Add to that, the fact that with Opensource development, often the developers will feel a much stronger emotional bond with the project they’re working on – when you’re writing software for a company, it’s their software, when you’re writing opensource software, it’s yours – you care more because it belongs to you. I think that often adds to the heat of any disputes that do occur. In a commercial operation, if someone overrules you even though you’re adamant they’re wrong to do so, ultimately you just convince yourself “who cares? it’s only work”. But with Opensource software people really do care, so I think it’s easy for people to get carried away.
I’ve been in that position where you’re working on a project, and it’s fun and you’re making real progress and everything seems fine, until one day you wake up and realism the project is actually bigger than you are, and that’s quite daunting and stressful. When things get tough in a large corporation, there are support mechanisms – your boss will notice and (with any luck) try to help, failing that you may have an HR department to go to with problems. When you’re working in a small start-up organisation, you don’t have that, you have only yourself – that can be quite an overwhelming feeling.
So, this leads me on to the solution. Bitcoin is mortally wounded, but it can be saved. Actually the task of doing it is relatively trivial. Make no mistake, there will be a crypto coin that breaks through into the mainstream and begins to take serious chunks out of the market capitalization of the existing traditional currencies. If it’s not Bitcoin, it’ll be one of the slew of crypto-coin alternatives, but why allow another to take all the glory, when Bitcoin was what started it, Bitcoin already has all the momentum, Bitcoin should see it through – stupid to give up now. The challenge, is getting everyone to agree to what’s needed. However, those of us who genuinely want to see Bitcoin continue and expand as a rival to traditional fiat currency will understand why this needs to happen, and hopefully there’s enough of us to get it put in place.
How to fix bitcoin
All of the events leading up to this point make one thing abundantly clear – Bitcoin is in trouble as an organisation because it has no structure – it’s not even really an organisation, no formal rules for dealing with disputes, no real sense of direction or clear line of accountability. I suspect to some extent the members of that small team of developers who’ve been keeping Bitcoin going must be exhausted and feeling pretty burned out – it’s too much responsibility for a team of three or four people with very little support.
What Bitcoin desperately needs -(in fact what any crypto-currency is going to need to survive long-term), is to be backed by an organisation with a clearly defined mission statement, set of rules and conventions of operation, and a much wider and more accountable team making the crucial decisions. You can’t have a situation where one or two people are mediating what gets committed to the code base that’s running
So here’s my idea. Bitcoin needs a non-profit, perhaps an NGO? It needs to have a board of directors, 8 to 12 of them with a range of skill sets. There’s no reason why all the key players that are currently involved couldn’t have a seat on that board. The board would be responsible for all major decisions affecting the Bitcoin platform, and disagreements would be settled by vote. Wait a second, I’ve just described the Bitcoin foundation right?
Hold on a minute, Bitcoin Foundation is very nearly what is needed – it just has no credibility, no budget and no mission statement! Oops!
Forget advocacy and educational outreach – the Bitcoin ecosystem is full of evangelists that’ll be more than happy to spread the word for free – The Bitcoin Foundation is wasting its time trying to do that.
Here’s my suggestion: redefine the Bitcoin Foundation as a sort of indecent standards/regulatory body, with the responsibility to arbitrate any contentious development decisions. Seriously, this isn’t the first time there’s been major arguments in the Bitcoin project, and it will continue to happen until you put in place a system where overriding control. You need oversight, because sometimes people need to be forced to back down and compromise. Without that authoritative arbiter to resolve disputes, Bitcoin will constantly be in a state of warfare, and everyone involved will be gradually become more and more irritable and resentful. It’s not good!
.. and perhaps it takes an outside to point of view to highlight this to you, but I’d just like to draw your attention to this quote from Mike’s blog:
But every Bitcoin user, miner and investor faces a stark choice:
Bitcoin Core: a project run by two men who have shown clear opposition to the block chain having a future. One of them works for a company that makes more money the worse the block chain gets: conflicts of interest don’t get more extreme than that.
Bitcoin XT: a project run by two men who already shipped a compromise solution that reflects the demands of miners, users and companies.
Do you have any idea how bad that sounds? We’re taking about a system with a market capitalization of $6,648,121,625 – and that responsibility rests on two guys? That’s just totally crazy, no wonder there’s arguments. You need a team of about 6 people to collectively take responsibility for that job otherwise it’s just too much stress to put on a person. It may seem weird to give control away to for the final live commits, but giving away that power to the board of directors will set you free as developers to focus on writing code rather than tearing chunks out of each other. Honestly, I’ve seen some of the communications between you all on Reddit, and I have to say the language and tone that’s being used is an utter disgrace! You’re grown adults, fighting like spoiled teenagers. It’s a threat to Bitcoin and it’s making you all look a bit like morons, stop it. I’m not trying to be rude, but sometimes it’s important to tell things like you see them!
Anyway, to sum up – I think you should completely rehash the Bitcoin Foundation. Just looking at the website it’s clear that organisation has big problems. No full time employees, a partially-disgraced board of directors, no money in the bank, and thanks to the minutes they’ve been uploading from their meetings – I can see that they basically meet up once a month, sit around wondering what they’re supposed to be doing, can’t think of anything, so fall back to “perhaps we should just give up and go home?”
It’s depressing. Perhaps the Bitcoin foundation is past saving and it’s best just to liquidate it and start again – choose a new name for it and bring in a completely new set of directors there’s no lingering accusations of corruption – perhaps call it the “Bitcoin Council”?
In one of the meetings that I remember reading from the Bitcoin Foundation, the directors literally sat around and effectively said “well we don’t really have any money or goals or direction, so that pretty much rules out taking any kind of action at all!”
It’s just absurd!
Here, I’ll write the mission statement for you; “The Bitcoin Council’s role is to promote mutual understanding and information transfer between the stakeholders and the Bitcoin development team. The council’s goal is to improve the quality of the Bitcoin platform, uphold its values and ensure that any issues or disputes are dealt with swiftly and fairly”.
I’ll also write a director’s job description: “Directors are expected to take all necessary steps to understand the stakeholder experience and represent that to the development team, where appropriate offering suggestions to the developers to enable them to improve the end-user experience. Directors will also be expected to arbitrate any disputes that may occur, and should maintain a balanced and independent outlook while doing this, to ensure that all sides are treated fairly and proportionately”.
You really should work our the precise organisational structure and have it written down by a lawyer in a completely custom document. For a moment I got excited when I saw the “By-laws” section on the Bitcoin foundation website – I got excited and thought “at least they’ve done this properly”, but then I read the document that’s on there and realised it’s just a lightly modified boilerplate document not dissimilar to the one we used to have at my tech start-up.
The organisation that’s needed for Bitcoin is significantly different to a standard corporation, and i think you’d benefit from having those documents drawn up from scratch with professional legal advice – it’ll help you to codify what’s expected of everyone, and tie it into a contract that everyone is required to uphold. The precise details of that would probably require quite a bit of hammering out.
i’m also aware that what I’m suggesting probably goes against your natural instincts – Bitcoin is your baby and i’m sure you’re reluctant to give up control in any way. Also, I suppose some may see the involvement of such an organisation as “centralization”, which is obviously counter to the project’s goals. Just bear in mind though, that the responsibility for live code releases currently rests on just two individuals – that’s about as centralized as you can get. To share that responsibility among a board containing say 8-12 members actually represents a considerable move to de-centralize that power structure.
It’s important to precisely design the organisational structure that you need though because it is quite different to a standard commercial company – in particular, your directors’ primary obligation would be to the stakeholders – their duty is primarily to the stakeholders rather than shareholders, and the goal is to further the cause of Bitcoin in collaboration with the dev team and the stakeholders – it’s important that they would maintain a healthy separation from both sides, such that they were able offer an unbiased and un-emotional viewpoint. For that reason it’s potentially a conflict of interest to have a member who is both on the board and in the development team, but I suppose you could work around that by classifying that role as “technical director” and removing the responsibility to arbitrate disputes.
Furthermore, your board of directors would have a formally defined obligation to represent the views of the wider Bitcoin community. If you allow the board to decide these occasional contentious issues when they crop up, you’ll cut your own stress levels by an order of magnitude, and have much healthier and happier working relationships, and you’ll probably find that the decisions that are made are objectively better, and consequently the pace of development will increase.
If you give yourselves the breathing space to step back and think strategically for a while, and arrive at well-considered and well-planned course of action as a collaborative effort between the development team, the board, and the wider Bitcoin community. I do feel the development team has become somewhat blinkered, and has perhaps lost sight of the bigger picture. It’s worth remembering some humility – Bitcoin is a complex and multifaceted thing, and it’s both possible and likely that the development team would benefit from some expertise in other fields to augment their coding capabilities.
Rather than the occasional heated arguments between a small team of highly-involved developers, what you really want is a much wider and lower intensity kind of feedback. Sometimes it’s more important to hear what the end-user has got to say than to hear the competing opinion of another developer, particularly if neither developer has a fully comprehensive understanding of the end-user’s actual perspective. That’s why you need an external somewhat objective viewpoint to determine which of potentially many competing viewpoints is the most important one to hear – and it’s not always a programmer!
I can tell that the Bitcoin development have a rigorous and thorough commitment to producing good quality and “correct” code, and that’s very admirable, but I sense that perhaps it would help to inject a hint of pragmatism into that outlook – it’s worth remembering that you can construct a beautiful and amazing machine without and external input, but if nobody gets to see it, what use it is? All creative works (including software) must come into contact with the outside world if they are ever to really serve their purpose.
This is what it will take to keep Bitcoin going, and give it a fighting chance at breaking through into the mainstream.
As an example – one of the main barriers at the moment to using Bitcoin for quick purchases in a shop is that it’s simply a bit of a hassle to get your phone out and muck around with QR codes to transfer money to the shopkeep. For that, really what you need is a UX designer – someone with an instinctive understanding of how people interact with portable devices. That’s quite a different skill to software development, it’s always worth taking node of any outside input if it’s available – it can only make you stronger.
So anyway, that’s it – I guarantee you, this is the plan you need to follow if you’re going to make Bitcoin into a robust and permanent part of the online landscape. If you do not set up some form of organisation with oversight capabilities, able to assist with dispute resolution, I guarantee you will be stuck in this highly unstable and stressful state indefinitely.
I realise there are one or two hurdles – to begin with, I know the Bitcoin Foundation is effectively bankrupt, so you’re going to need some funding just to have the various documents drawn up and put the correct structure in place. You’ll know better than I do what funding options are available to you, but at a completely random guess I’d say you need about $10k. I think if you present a coherent plan to the community (the one I’ve just given you), and convince them it’s going to be implemented rigorously and properly, I think you’d easily be able to raise the funds directly from the community via something like Patreon. Or you may have various other funding options available – venture capital or a loan from funding-tree.co.uk or somewhere like that.
I think once you clearly establish the plan and make it clear that one of the purposes of the organisation is to provide a direct conduit between the developers and the stakeholders (ie your corporate partners like OKCoin, BitStamp etc) – they’ll be totally all over that, there’s a major benefit to them if they can get their feedback and suggestions heard – I’d expect the board to hold regular drop-in workshops for stakeholders to turn up and discuss their progress and experiences with the platform. That way you make the stakeholders feel valued, and potentially get some genuinely useful feedback, plus they’re obviously going to be much more happy to pay you large sums of money if they feel they’re getting something in return.
Basically you’d be building a consortium, not unlike the unicode consortium. I’d suggest a few different levels of membership, with one option being cheap enough that it’s basically a no-brainer even for the smallest of Blockchain start-ups – plus then obviously charge a bit more to the large corporations who can afford to pay.
Under that model I’d expect to turn over enough cash to fund a couple of full-time employees – I’m not entirely sure how the existing board have managed to bankrupt the organisation to the extent that it’s not even capable of that – just looking around at the number of companies that have some interest in Bitcoin, there’s literally hundreds, I’m pretty certain it’s a viable business model – either you’re not currently collecting membership fees from all the potential targets, or your operational expenses have run out of control for some reason, but I seem to remember reading in the board notes that there’s been some effort to reduce op-ex to basically $0?
If anyone’s going to fund this they’re going to need to be satisfactorily convinced they’re not just paying for the existing Bitcoin Foundation to piss away more money on well.. who knows what? There’s a lot of negativity towards that organisation and it’ll take a clear and visible break from the past in order to shake that negative reputation. The benefits when you pull it off though – well, they’ll seem like small miracles. Not only will you be happier and more comfortable while working, but you’ll also do a lot to boost confidence in the stability of the currency. This year is going to be a big year for Bitcoin – there’s a lot going on with new Blockchain startups etc – but the Bitcoin team itself needs to be in the best possible position to capitalize on that opportunity and push Bitcoin through to the next level of mass-market adoption.
I’d publish strict guidelines on who can be a director, and I’d make sure those guidelines contained at least the following two rules: 1) no criminal convictions 2) no conflict of interest with other business activities. It needs to be a bit of a public relations exercise too – if you’re bringing in unknown people for the board you’ve got to visibly introduce them to the community and give people a chance to get to know them. That’s how you rebuild trust after the history of misdemeanors that has befallen the beleaguered Bitcoin Foundation.
I think that’s the end of my advice now I’ll also give you a brief description of my credentials – I’ve been a programmer literally since I was 7 (started on BBC BASIC), I’m 30 now and know pretty much all the languages. A little over 5 years ago I set up a technology start-up, which was originally a custom fully-distributed web hosting platform, although shortly after I left the company they pivoted slightly and now they mainly focus on Docker containers – if you wish to check them out the URL is http://clusterhq.com/ – my job title was Marketing Director, but I actually spent most of my time writing PHP and answering customer support requests – prior to that I worked for a number of years at a marketing company, as “Senior Network Manager”, which basically meant “Anything electronic, it’s yours”. I no longer have any commitments to either of those companies, I sold most of my shares in ClusterHQ a couple of years ago and no longer sit as a director. These days I’m doing what takes my fancy, which is currently using artificial intelligence and machine learning to auto-trade Bitcoin derivatives (at BitMEX and OKCoin) – I therefore have a vested interest in Bitcoin, but not a conflicting one, as I want the same thing you do – for it to be stable and reliable.
You can get some sense of the sorta stuff I get up to by checking out my website website, which is obviously here ^^^^^ Just don’t look at the HTML source code, I wrote it a long time ago before the days of HTML5 and it’s probably pretty awful by modern standards.
I’m willing to help out with Bitcoin in whatever way I can, and I’m currently in the position where I could do that for free. I could probably make an effective contribution to the Bitcoin code base if I looked into it, but I’m already buried deep in neural nets, so I’d probably prefer not to take on any more programming work. I think I’d probably be more useful to Bitcoin in an advisory or guidance capacity anyway. I’d probably be up for standing as a director if a position is going, although that’s not why I’ve gone to the trouble of writing out all this advice – the reason I’ve gone to the trouble is because I’ve written loads of code to work with Bitcoin and it’d be extremely inconvenient to me if Bitcoin were to unexpectedly go belly-up. I’ve watched the various disputes and arguments in the Bitcoin team and I feel like I’ve got a fairly good understanding of what the root cause of the issue is, so I’m sharing what I know in the hope it’ll be useful