John Hardy | SeeBitcoin

Cynical miner power grabs are healthy for Bitcoin and should not be feared. Cryptoeconomics will always triumph.

There are competing visions for Bitcoin.

I support the Core scaling roadmap. I believe in prioritising off chain scaling where possible but also for SegWit and hard forks to increase the block size as required to allow Bitcoin to grow exponentially.

Others believe the block size should be left to the miners. I think this could enable a path towards centralisation and fundamentally change Bitcoin’s value proposition.

Some miners are signalling for Bitcoin Unlimited – a hard fork to enable this. It is rumoured some would attack the other chain in the event of a fork to ensure there is no permanent split and their vision is realised.

Miners are within their rights to attack another chain. This is crypto economics in action, if you don’t like it then cryptocurrency by its nature is not for you.

If miners attempt this power grab they are taking a huge risk and we are within our rights to plan for how we could mitigate it and punish them. There may be a permanent fork, but as long as one becomes economically dominant this isn’t a problem. When the battle is over the loser will be just another altcoin.

I’m skeptical this power grab will come to fruition but if it does I believe the best approach would be increasing the proof of work methods from 1 to 4.

Ideally a ‘Quad Core’ fork could trigger when 75% of miners are signalling for an implementation like BU. This would allow the remaining 25% to bring their hashpower to the new chain and abandon the other one. The opportunity should also be taken to activate SegWit and introduce a block size capacity increase.

The addition of Scrypt, Ethash, and Equihash methods of PoW would provide a mix of CPU and memory intensive implementations and improve diversity of hardware. Each having a target block difficulty of 40 minutes would retain 10 minute block intervals overall. This should reduce centralisation and these are proven PoW methods in use with other altcoins and so there would be a willing mining infrastructure already in place.

If successful this would prove bitcoin resistant to hostile miners.

I actually think this would be quite exciting. Each side of the fork would have a clear mandate for their scaling vision and the market would decide the winner. This is exactly how crypto economics works and should be celebrated rather than feared.

No politics, pure numbers: if the blockchain grew at its current rate and hard drive prices fell at their current rate – what storage cost in 20 years?

I decided to look objectively at one of the costs of scaling on chain. This is pure numbers, no politics.

Storage is currently a very small part of the cost of running a full node. The block chain is around 100GB. With storage currently available from as little as $0.019 per GB, that’s just $1.90.

This is just a look at storage alone, it does not consider bandwidth, CPU or electricity requirements of operating a full node.

According to http://www.statisticbrain.com/average-cost-of-hard-drive-storage/ the 6 years from 2010-2016 saw the cost per GB fall from $0.09 to $0.019 – a fall of 79%.

This equates to an average fall in price of 23% each year.

From 1995 to 2000 the cost per GB fell by 99% – an average of 60% each year.

This represents a fall in the rate at which prices drop by 5% each year on average.

I will perform two calculations:

Assuming the price continues to fall by 23% each year
Reducing the rate at which the prices fall by 5% each year

I will also estimate blockchain growth based on actual current levels of growth.

For example the blockchain sizes: 2013: 13,490MB, 2014: 27,840MB, 2015: 53,700MB equates to an increase of 2014: 14,350MB, 2015: 25,860MB, so 2015 saw an increase of 80%. Through 2012 to 2016 the blockchain transactions grew by an average of 88.6% each year (used in calculations).

This gives the following results for the next 20 years:

Year ending	Blockchain Size (MB)	Annual Increase (MB)	Average block size (MB)	Cost per GB (USD)	Storage cost	Cost per GB (5% slowdown)	Storage cost
2012	4270	3637	0.1	0.06	$0.25	0.06	$0.25
2013	13490	9220	0.2	0.05	$0.66	0.05	$0.66
2014	27840	14350	0.3	0.03	$0.82	0.03	$0.82
2015	53700	25860	0.5	0.022	$1.15	0.022	$1.15
2016	96345	42645	0.8	0.019	$1.79	0.019	$1.79
2017	176759	80414	1.5	0.01463	$2.53	0.0148485	$2.56
2018	328391	151633	2.9	0.0112651	$3.61	0.011766323	$3.77
2019	614318	285927	5.4	0.008674127	$5.20	0.009446048	$5.67
2020	1153477	539159	10.3	0.006679078	$7.52	0.007676459	$8.65
2021	2170144	1016667	19.3	0.00514289	$10.90	0.006310283	$13.37
2022	4087226	1917083	36.5	0.003960025	$15.81	0.005243396	$20.93
2023	7702182	3614956	68.8	0.003049219	$22.94	0.004401214	$33.10
2024	14518739	6816557	129.7	0.002347899	$33.29	0.003729648	$52.88
2025	27372412	12853672	244.6	0.001807882	$48.33	0.003189008	$85.24
2026	51609997	24237585	461.1	0.001392069	$70.16	0.002749851	$138.59
2027	97313708	45703711	869.6	0.001071893	$101.87	0.002390104	$227.14
2028	183495118	86181409	1639.7	0.000825358	$147.90	0.002093056	$375.06
2029	346003480	162508363	3091.9	0.000635526	$214.74	0.001845931	$623.73
2030	652438106	306434626	5830.2	0.000489355	$311.79	0.001638882	$1,044.21
2031	1230267939	577829833	10993.7	0.000376803	$452.70	0.001464248	$1,759.20
2032	2319855365	1089587426	20730.4	0.000290138	$657.30	0.001316023	$2,981.43
2033	4374440803	2054585438	39090.3	0.000223407	$954.37	0.001189464	$5,081.29
2034	8248679087	3874238284	73710.8	0.000172023	$1,385.71	0.001080796	$8,706.19
2035	15554153957	7305474870	138993.1	0.000132458	$2,011.98	0.000986992	$14,992.02
2036	29329755549	13775601592	262092.9	0.000101992	$2,921.30	0.000905613	$25,938.87
2037	55305780734	25976025185	494216.6	7.85342E-05	$4,241.60	0.000834677	$45,080.52

Assuming the optimistic scenarios that Bitcoin continues to achieve the levels of growth it has the last 4 years for the next 20, the cost of storage hardware alone to operate a full node would be $4,241.60 by 2037 – assuming the price of storage continues to fall rapidly.

If the rate at which storage gets cheaper continues to fall by around 5% each year, the cost for storage hardware alone would be $45,080 by 2037.

That’s just the numbers based on past performance. Past performance is no guarantee of future results.

Like this research? Please consider donating to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE and I’ll try and find the time to do more.

I analysed 24h worth of transaction fee data and this is what I discovered

The idea of allowing of allowing miners to increase the blocksize with demand is an interesting one but creates a problem: miners can game such a system by filling the blockchain with transactions at zero cost.

Asking miners to pass on a portion of the transaction fees to the next block would solve this problem as the miner would then incur a cost. Unfortunately this introduces a new problem: miners are incentivised to accept fees away from the blockchain (out of band).

What if there were a way that could not be manipulated without an economic cost to the miner for doing so?

I decided to do a little analysis of the last 24 hours worth of transaction fees:

Satoshis/byte group	Transactions	MB used	BTC fee	Cumulative MB %	Cumulative BTC %
0	81	0	0	0.0%	0.0%
1-10	686	0.3	0.02	0.2%	0.0%
11-20	2588	1.2	0.18	1.0%	0.2%
21-30	3755	1.7	0.43	2.2%	0.5%
31-40	2677	1.2	0.42	3.0%	0.8%
41-50	13654	6.3	2.84	7.2%	3.1%
51-60	15052	7	3.85	11.9%	6.2%
61-70	108748	50.2	32.63	45.8%	32.4%
71-80	27432	12.7	9.53	54.3%	40.0%
81-90	32969	15.2	12.92	64.6%	50.4%
91-100	31188	14.4	13.68	74.3%	61.3%
101-110	13704	6.3	6.62	78.6%	66.7%
111-120	38051	17.6	20.24	90.4%	82.9%
121-130	4510	2.1	2.63	91.8%	85.0%
131-140	6294	2.9	3.92	93.8%	88.1%
141-150	2793	1.3	1.89	94.7%	89.7%
151-160	3021	1.4	2.17	95.6%	91.4%
161+	14015	6.5	10.73	100.0%	100.0%
Totals	321218	148.3	124.7

I collected data on evening of 10th January 2017 . The transaction data came from https://bitcoinfees.21.co/.

I used an average transaction fee of 462 bytes from here, and also had to average out satoshis/byte groups. Despite multiple data sources and rounding I was happy with how closely these calculations tallied up with the 24 hour stats at https://blockchain.info/stats:

Blocks Mined	150
Total Transaction Fees	118.84277985 BTC
No. of Transactions	313900

What does the data tell us?

It compares fee level groups in two ways:

How much space they use
What fees they generate

This shows how the fees generated and capacity used were distributed:

A fairly expected distribution, no odd outliers.

The cumulative BTC column in our chart shows us that the median economic fee is around 90 satoshis/byte.

What’s the idea?

I wondered if we could use this data to generate a threshold to calculate whether the network is ready for a block size increase.

Let’s say we need blocks to be considered 75% full for miners to activate an increase.

If we did that currently there is no cost to the miners to fill every block with transactions and force an increase as they get all the fees reimbursed.

What if we discounted all transactions of a fee below half the economic mean for the threshold? That would equate to around 45 satoshis/byte.

From the table we can see that around 95% of transactions are above this level. Since the blocks are consistently over 95% full at the moment and we’re counting 95% of the transactions toward the threshold, 0.95 * 0.95 gives us a figure of over 90% – well above the required level.

How could we stop miner manipulation?

Well, technically we can’t. We can disinsentivise manipulation by making it expensive though.

I’ve taken the original figures and reduced them by 25% to simulate less full blocks. I’ve then filled this freed up space with the cheapest but non-free transactions. This shows what it would look like if miners themselves tried to fill blocks with cheap transactions to activate a block size increase.

As you can see the manipulation is obvious but the protocol cannot see charts. We need to calculate how full the blocks would be considered for activation purposes in this scenario.

Since 25% of transactions are in the 1-10 satoshis/byte group they are discounted from the calculation.

Infact only around 72% of the transactions are above the 45 satoshis/byte required. 0.72 * 0.95 gives 68.4% full blocks for activation purposes – short of the 75% threshold.

Getting to the point

There are benefits to allowing miners to signal for block size increases. It’s quicker and less risky than hard forking each time for a start.

The problem of miners accepting fees out of band to avoid paying to signal for an increase can be completely mitigated – if miners do not vote for a block size increase they can keep 100% of their transaction fees as normal.

If there is consensus, miners passing transaction fees to the next block will average itself out. Only miners who consistently signal for a block size increase against consensus will incur an economic cost.

Signalling to increase the block size while simultaneously receiving fees out of band is counter-productive as those transactions will not count towards the reaching the activation threshhold.

While it may superficially appear the case, zero and low fee transactions are not punished under this implementation. They are effectively just factors in a scoring system when miners are suggesting additional block space is required. Remember that miners currently cannot signal for an increase at all, so this does not alter any fundamentals or discourage low fee transactions when there is capacity.

Thank you for reading, let me know any thoughts in the comments!

Dynamic block size with economic safeguards – could this be the solution that we can all get behind?

One side of the block size debate wants to hand over control of the block size to the miners. Many fear such an implementation would cause catastrophic failures of consensus, and that miners could even be incentivised to bloat the block size at a rate that overly compromises Bitcoin’s decentralistion.

Others are worried that scaling solutions such as Lightning Network and sidechains will take too long and not achieve sufficient gains, stifling Bitcoin’s network effect and preventing its continued exponential growth.

What if there were a way to simultaneously allow for exponential growth on chain if needed – allowing time for layer two solutions to take some heat off the chain, but also creating an economic disincentive for miners trying to inflate the block size arbitrarily.

Such a solution should allow for an exponential increase in block size if miners were in consensus, but require they face an economic risk when signaling for a block size increase where there was no consensus. Cryptoeconomics is built on incentive game theory, why not introduce it here?

Allowing the block size to change dynamically with demand would reduce the risk of requiring additional contentious block size hard forks and hostile debate. I fear a simple 2MB increase would reignite the debate almost as soon as it was activated, we need to buy as much time as possible.

Any solution is going to be a compromise, but by allowing a few years of exponential growth with strict safeguards and appropriate economic incentives we can hopefully achieve that.

So how do we do it?

My basic idea is for miners to vote in each block to increase the block size.

Allowing for exponential growth would mean that the block size could double every year.

This would be achieved by each of the previous 2016 blocks voting to increase the block size by the maximum amount of 2.7% each time. An increase of 2.7% every 2 weeks would result in an annual block size increase of 99.9% (rounding).

We only need to use 3 bits for miners to vote on block size:
000 = not voting
001 = vote no change
011 = vote decrease 2%
101 = vote increase 1.35%, pay 10% of transaction fees to next block
111 = vote increase 2.7%, pay 25% of transaction fees to next block

Not including any transactions in a block will waive a miners’ right to vote.

Each block is a vote, and the block size change could be calculated by averaging out all the votes over 2016 blocks.

In order to achieve an increase in block size, the blocks must also have been sufficiently full to justify one. Transactions with no fee and perhaps outliers far from the mean tx fee/kb should perhaps not be included.

By asking miners to pay a percentage of their transaction fees to the miner of the next block, you discourage miners from stuffing the blocks with transactions to artificially inflate the block size.

If miners are in unanimous agreement that the block size needs to increase, the fees would average out and all miners should still be equally rewarded. Only miners trying to increase the block size when consensus is not there would incur a cost.

There should be a limit on the maximum increase, perhaps 8MB. This isn’t a permanent solution, it is just to create time for Bitcoin to progress, and then re-evaluate things further down the line. Combined with SegWit this should provide a reasonable balance between satisfying those who are worried about missing out on exponential growth for a few years if LN and other solutions are not as fast or effective as hoped.

This is my rough idea for trying to find a compromise we can all get behind. Please let me know any thoughts or suggestions in the comments.

By 2017, Bitcoin had calculated more hashes than there are stars in the observable universe… by this incredible multiplier

I’ve sadly not had time to blog as much as I would like recently, but I thought I would share with you all some interesting facts about the number of hashes performed by the Bitcoin network by the end of 2016.

Method

I built a spreadsheet with the difficulty for every single day the Bitcoin network has been in operation up to 31st December 2016.

I used the following formula:

=SUM(DIFFICULTY * POWER(2,32) / 600)

This gave the hashes per second for each day’s Bitcoin difficulty level.

I then multiplied this by 86400 seconds to calculate the total hashes for each day, and added all 7 years together to give the total of hashes calculated by the Bitcoin network.

For an explanation of hashing, see my previous article.

So, how many were there?

By the end of 2016 the Bitcoin network had cumulatively calculated around 6.27683E+25 hashes.

That’s 62,768,300,000,000,000,000,000,000 hashes.

For perspective, a group of researchers estimated the number of grains of sand in the world – every grain of every desert and beach – at 7.5E+18 grains of sand. That’s seven quintillion, five hundred quadrillion.

This means Bitcoin has already calculated 8,369,107x more hashes than there are grains of sand on planet earth and currently breezes through that amount again as little over each three seconds pass.

When people say that Bitcoin’s are “based off of nothing” they don’t understand that each Bitcoin is generated at huge computational and electrical cost. A hash of sufficient difficulty is an exceptionally scarce resource.

Bitcoin is secured by a beautiful combination of mathematics and the laws of physics: hashing cannot be cheated.

While altcoins can easily copy Bitcoin’s design, they can’t even begin to come close to its 7 years of accumulated hashes. The hashrate is what makes Bitcoin untouchably secure, as to attack the network requires sustained control over enough resources to generate 51%+ of the network’s hashrate. Even ignoring the vast hardware requirements, doing so would require an electrical supply sufficient to power a small country. The bitcoin network has long performed more PetaFLOPS than the top 500 supercomputers on the planet combined.

With the transition toward specialised mining hardware, even if an attacker managed to build a botnet of hacked laptops capable of a generous 30MH/s average hashrate, they would need to hack over 75 billion laptops to mount a 51% attack. That’s over 10x hacked laptops for every person on the planet.

Breaking it down by Bitcoin

At midnight on 31st December 2016, the total number of Bitcoins totalled 16,077,350.

That means every single Bitcoin on average, was produced by 3.9041447e+18 hashes.

That’s 3,904,144,700,000,000,000 hashes

Considering each Bitcoin is divisible into 100 million satoshis, each of the smallest unit of Bitcoin is on average a product of 39,041,447,000 hashes.

That’s 39 billion hashes per 0.00000001 of a Bitcoin.

There are estimated to be 1 billion trillion stars in the observable universe. Watch this video to get a sense of perspective, then consider that the Bitcoin network has calculated more hashes than this by a multiplier of 62,768.

That’s right, the Bitcoin network has already calculated over 67,768x more hashes than there are stars in the known universe! Just wow.

*All calculations correct to the best of my knowledge, but I wrote this article in a rush and there may be errors! Please let me know if you spot any and I will correct them.

Why I’m massively in favour of a hard fork block size increase, and also massively against one

I made some reddit posts that recently have been interpreted as my being in favour of small blocks and not raising the block size limit.

This is not my position at all. I’m making the important case that Bitcoin cannot rely on on-chain scaling alone. Satoshi mentioned Moore’s law in the white paper. These were very compelling comments, and for my first few years following Bitcoin it seemed reasonable that Bitcoin could scale on-chain indefinitely.

Unfortunately global propagation is harder than it first seemed when blocks were tiny, and on-chain scaling is not as viable as first thought. Moore’s law alone is not our scaling saviour.

That said I’m not opposed to a hard forks to increase the block size – I think they are necessary. My concern is at hard forks being seen as an easy solution to scaling.

If I seem like more of a small blocker than I am it’s because I’m trying in my mind to balance out the community by pushing the small block cause. I want people to realise that on chain scaling has real implications and is not a long term solution.

I’m incredibly sympathetic to the arguement that we need Bitcoin to be attractive, and low transactional fees are something that first attracted me to Bitcoin. However we’ve also got to be careful of precedent.

The block size debate is more than technical – it is about the politics and future direction of bitcoin.

If we head in the wrong direction and become dependent upon bigger and bigger blocks, there is a genuine risk we embark on a slippery slope and slowly erode what makes Bitcoin special.

I’m not convinced anyone is using Bitcoin at the moment to buy coffee. I’m also sympathetic that we want to make Bitcoin accessible and that lower fees helps the poorest participate, but we need to be cautious.

Bitcoin’s decentralised nature is our democracy, and good democracy requires checks and balances. It might not feel like it at times, but the passionate debate and resistance over changing the status quo is giving us exactly that.

No matter what you think of your opponents, we’re all playing an important role in Bitcoin’s governance. There has never before been anything like it. Fierce debate over monetary policy has taken place behind closed doors throughout most of history, now we all get our say.

I am not opposed to a block size increase, I am opposed to a block size increase being easy. Not because I think bigger blocks will ruin Bitcoin, but because I think lots of block size increases would ruin Bitcoin.

We need to put up a fight against anything that could change what Bitcoin currently is. That doesn’t mean we shouldn’t ever change Bitcoin, but that such changes should have stood up to immense scrutiny.

You might be massively in favour of increasing the block size, but you should also be thankful in the face of resistance. If Bitcoin ever becomes easy to change it becomes easy to break.

That’s why I’m simultaneously opposed to a block size increase while also being in favour of one.

Yes I’m a paradox, but I’m quite happy that way.

Bitcoin is under siege! We need to fight against post-Truth propaganda, and a plan B to reclaim Bitcoin if taken

We now have a completely divided community where people believe nonsense. A sizable minority have now been convinced that SegWit is dangerous and creates an insurmountable technical debt. These people generally have no development experience, and just blindly repeat misinformation despite the protests of those who do. The vitriol they have been fed is a contagion that is spreading, while others just want to block SegWit out of spite.

I recently tried to compile a list of developers who were opposed to SegWit. The exhaustive list consisted of four. That’s right… four. From the stink kicked up by the anti-SegWit brigade you’d think this number would be far higher.

If you repeat a lie often enough, people will believe it. There is a real risk that enough of the non-technical community now believes SegWit is too complicated and risky to prevent its activation. For the technical community this is a total non-debate, actual developers opposed to SegWit are the flat earth society of Bitcoin. Disagree with this? Try to list developer names and credentials opposing SegWit and you’ll soon realise how feeble the technical opposition is.

In addition to SegWit hate, the vitriol directed at Blockstream is absurd. Bitcoin is and always will be open source, and Blockstream’s business model depends entirely on the success of an open and decentralised Bitcoin. All the big names there have a proven track record of dedicating themselves to Bitcoin’s advancement. Their business model is to profit from their expertise, gained by valuable contributions to Bitcoin’s development. This is a sound and reasonable business model that has been successful on many other open source projects such as MySQL. The profit they make can be used to further advance Bitcoin – it is a win, win.

People literally believe that Blockstream is Evil Corp. I’ve seen people argue that Blockstream profits from keeping blocks small so they can charge for the lightning network. This demonstrates a shocking lack of comprehension and common sense. There are even conspiracy theories that Blockstream is a secret banking trojan horse to bring down Bitcoin from the inside. People peddling such misinformed nonsense need their heads inspecting.

Five years ago in response to scaling concerns, I used to argue that Bitcoin could scale infinitely on-chain, often citing Moore’s law. The more I learned about Bitcoin, the more I realised this isn’t viable without risking Bitcoin’s fundamental value proposition – decentralisation.

I have not been “brainwashed by Blockstream lies”, I have simply joined the consensus of those with a more informed technical understanding. With off-chain scaling we can have our decentralised, inexpensive and instant digital money cake, and eat it too. Sadly, we now live in a post truth world, and having the better argument is often trumped by those shouting the loudest.

Valid concerns can be raised about user experience, missed opportunities, and yes, Lightning Network and Sidechains aren’t ready yet and we do need solutions now. Well, guess what, we have a solution right now: SegWit will immediately ease the stress on the network, it is coded, extensively tested and ready to launch… and there is even consensus for a hard fork block size increase after its activation.

The only thing that will prevent SegWit from activating is misinformation combined with a political power grab by opportunistic miners.

There is now a movement, in the form of Bitcoin Unlimited, to hand over control of the blocksize to miners. There are many reasons why Bitcoin Unlimited is a terrible answer to the block size debate. Sadly, much of this discussion takes place in the bitcoin-dev mailing list where the brightest technical minds hang out, while the rest of the community indulges in misinformed squabbles on reddit. In short, handing over control of the block size to miners would be terribly centralising.

People arguing that the community wants a block size increase are right. I’m all for a block size increase too, however it is vitally important for the health of Bitcoin that the best technical solutions win and we do not concede to misinformation and fear. SegWit MUST be activated before a hard fork block size increase.

If the propaganda succeeds in persuading miners to fritter control of Bitcoin’s block size limits away to an implementation as poorly conceived as Bitcoin Unlimited, then that chain and those who created it must be punished by the market.

To do this, I propose Bitcoin 4Core, a hard fork response that would clearly support the scaling vision of Bitcoin Core, and hopefully recruit their talented development team.

I believe the best way to protect the network from attack and simultaneously improve decentralisation would be to introduce additional proofs of work. 4 proofs of work each with 40 minute block creation targets and respective difficulties. We could add Ethash, Scrypt and Equihash to give a mix of CPU and memory intensive methods, and improve diversity of hardware. We could also take the opportunity to introduce a 4MB maximum block size.

By using proof of work methods with existing altcoin implementations, the mining ecosystems already exist, though some altcoins would likely face severe disruption as miners fled to profit from Bitcoin. Existing Bitcoin miners also wouldn’t be shut out completely as with a change of PoW, and could reluctantly return with diminished income and influence when they a realise that the economic majority will overwhelmingly follow the technical majority when given a choice.

I don’t know if the Core developers would support a proposal like this, but I personally think it would be a great way to reclaim Bitcoin and give a clear mandate to the sound vision of the Core development team. This, however, should be a last resort, and I remain optimistic that SegWit can still activate despite all the noise.

People who argue that introducing SegWit as a soft fork is “too complicated” are concern trolling

Back in February I wrote a piece on then big block flavour of the month, Bitcoin Classic.

I was frustrated that the approach of rival implementations to Bitcoin Core was basically to lift most of the work of the core development team, make a few simple tweaks, and then try and push their implementation as the saviour of Bitcoin.

So I laid down a gauntlet, instead of being a cheap cover band, actually write some code that showcases your abilities and proves your worth. Do that, and a rival implementation could earn the respect and credibility essential to advance their agenda.

Segregated Witness (SegWit) is a clever way to almost double Bitcoin’s capacity without increasing the block size, while also solving other problems such as transaction malleability. It was widely agreed that SegWit was a win win.

Fast forward to now and SegWit has been developed, fully tested and is ready to be implemented as a soft fork.

Great news you would think, except if you go to the big blocker parts of the Internet, suddenly SegWit is considered dangerous!

The argument isn’t that SegWit is bad, it’s that it is way too complicated to be introduced as a soft fork, and should have been implemented as a hard fork. They also claim that the complexity of the code (over 500 lines), and compromises required as a soft fork will make Bitcoin really difficult to develop for in the future.

The developers at Bitcoin Core, who have delivered the solid dependability for which Bitcoin has become known, have collectively decided that SegWit was not just within their capabilities to write, but also to build upon in the future.

If any serious developer is arguing that Bitcoin is going to be too complicated for them after SegWit, they’re probably not a good enough developer that they should even be considering working on such a critical software. Anyone who isn’t a developer frankly needs to keep their concern to themselves, as they are not qualified to hold such a view.

I’d be a lot less harsh if SegWit had suddenly been announced and implemented under a shroud of secrecy. The Core developers said in December however, that SegWit would be coded as a soft fork.

If any rival team of developers disagreed with this approach they had a simple solution… write their own implementation of SegWit as a hard fork.

This would give them an opportunity to showcase their abilities, and give the community something to think about. If it was as simple and elegant as they say… they could have had the code ready months before Core, impressed us all with its elegance, and really built some momentum

What do we have instead? We have a small community determined to do everything in its power to block SegWit activation. It’s a shame that instead of sitting on the sidelines complaining, they didn’t take some initiative. They need to learn from this experience, as right now they just look like the petty children who have taken their ball and gone home because the game isn’t going their way.

photo credit: John Spooner Beware of the Troll via photopin (license)

The blocksize debate: is an end in sight for the civil war that has engulfed Bitcoin?

Depending on which parts of the Internet you inhabit, your perception of what’s happening in Bitcoin land can vary hugely.

The Bitcoin community is bitterly divided. For years now it has been split into two camps, those who think Bitcoin needs an urgent blocksize increase, and those that think other scaling approaches should be prioritised.

The “big blockers” are worried that with the current limit of mostly full 1MB blocks, there isn’t enough capacity for Bitcoin to grow. They think this will cause real harm to Bitcoin’s network effect, and that not addressing it urgently could result in Bitcoin losing its position and momentum as #1 cryptocurrency.

Whether you see merit in this view or not, it’s important to recognise that to somebody who is convinced that failing to urgently raise the blocksize could lead to Bitcoin’s downfall, the current standoff and ongoing lack of an increase would be incredibly frustrating. It is understandable that frustration and helplessness would lead to a deep seated suspicion and contempt for those they see as standing in their way.

For those of you that don’t visit the big blockers communities, it’s staggering to see the vitriol and anger directed at those “progress preventers” the Bitcoin Core developers, the team that has long served as custodians of the main Bitcoin implementation.

While big blocker communities can feel a little bit like the front line of a war, frequenting the “small blocker” parts of the Internet can feel a lot happier – you wouldn’t necessarily realise there even was war.

The thing is that everyone, big and small blockers alike, agree that Bitcoin needs to scale.

The Bitcoin Core team have identified a few interesting ideas that they believe are the best way to scale Bitcoin, primarily Segregated Witness (SegWit), and Lightning Network.

Lightning Network is not popular with big blockers. It aims to move transactions off chain, sending them directly between individuals rather than being stored by every participant on the network.

They are skeptical, arguing that it is hypothetical and unproven, and that even if it achieved everything claimed, it does nothing to address the scaling problems that Bitcoin is facing right now. Many also believe that these transactions taking place “off chain”, are undesirable and not part of Satoshi’s vision.

They contend that on chain scaling is an essential and easy fix that can be implemented immediately, and that Lightning Network is a distraction, causing Core developers to neglect more pressing issues.

I can understand these concerns, but I also see the merit in the approach taken by the Core developers. In summary, an increase in blocksize is a barrier to running a node and reduces decentralisation, a sacred and essential property of Bitcoin which, they contend, must be preserved as much as possible.

Middle ground is hard to find when the argument is so subjective. On one side, a $0.09 transaction fee is far too high and going to put off new users so Bitcoin never grows. On the other a $0.09 transaction is far too cheap to require that every full node, thousands now, possibly millions in the future, is required to store details of $2 coffee purchases for thousands of years to come – leading to a bloated chain that will suffocate under its own weight and jeopardise the highly prized property of decentralisation.

SegWit seems to be a middle ground. It works by splitting the data from transactions into two parts, half of which can be included in 1MB blocks, the other half stored separately and not contributing towards the block size limit, while improving a other areas of Bitcoin (like transaction malleability) as an added bonus.

This, the developers claim, will give an effective block size increase to around 1.7MB without requiring that everyone upgrade their software (a hard fork).

Great news, you would think, the big blockers and small blockers can both agree this is a win win for Bitcoin. Also, there’s no longer need to wait, SegWit is coded, tested and ready for implementation.

The thing is, to the surprise of those who don’t frequent the big blocker communities, the frustration and suspicion has grown so pernicious that SegWit is not trusted. They don’t believe it does enough to address Bitcoin’s urgent scaling problem, has taken too long, and will take too long to come into effect.

There is almost a sense that, in accepting SegWit, they will have “lost”, and that they still haven’t been listened to. Some even argue that introducing SegWit as a soft fork is more dangerous.

All this frustration and bad feeling has manifested itself in the rejection by the big blocker community of SegWit. They would rather block its implementation than “lose”.

You might think they’d be barmy to block something that is ready to increase Bitcoin’s capacity, but that is exactly the plan. They have lost complete confidence in Bitcoin Core and many would like to see a switch to a rival implementation, Bitcoin Unlimited, that would allow miners to decide the maximum block size instead.

There is a genuine belief that in blocking SegWit, they can force a stalemate that will enable them to push the community into choosing “their” scaling solution, and that they can still win the war.

If you’ve not passed by this community, this may sound absolutely outrageous. To everyone else, the war is almost over, but to those on the other side, battle has just commenced.

So, what happens now?

In order to be activated, SegWit requires 95% of miners to vote for its activation. Currently, mining pool ViaBTC has stated it will vote against SegWit, and since it has over 5% of hash power, it will succeed.

This leads to an interesting dynamic. To those outside the big block community, those that have most vocally demanded the network capacity increase are now the ones standing in its way. In a war of ideas, it’s hard to see that the big blockers are going to suddenly gain much new support when it looks like this.

How will the Core developers react? Well, I think they’ll patiently respect the 95% activation threshold.

It’s also interesting to note that a number of prominent Core developers signed an agreement in February about how to scale Bitcoin.

The agreement was that SegWit would be worked on as a priority, and the once finished the developers would take around 3 months to write code for a hard fork to increase the block size somewhere between 2-4MB.

They then went on to estimate that SegWit would be coded by April, and if that were the case the hard fork would be coded by July 2016. This is unfortunate, because this optimistic timescale has led to accusations that the Core developers had failed on their “promise” to code a hard fork by July.

Software often takes longer than hoped, but it is a shame this mention of July 2016 has led to some in the big block community feel like they have been betrayed and misled, when it was an estimate rather than a commitment.

If Core developers present had said SegWit would take until October 2016 instead of April 2016, it is possible that consensus may not have been agreed- and you could argue was agreed on false pretences. While I believe this was a genuine underestimation, I can understand why others already cynical would assume the worst.

So, what happens now? Well, SegWit will probably not activate, and the Core developers who signed that agreement will spend the next 3 months writing the code they promised for a hard fork – those present signed the agreement and their reputation now depends on it.

It would actually be good for the big blocker cause if the Core developers present reneged on the agreement, as they would be vindicated and would gain new support.

In the meantime, the big blockers will promote Bitcoin Unlimited, and despite their overwhelming optimism in the face of what to many looks like adversity, it will probably face the same fate as Bitcoin XT and Bitcoin Classic, similar attempts which failed before it.

Around 3 months from now we’ll possibly still be waiting for SegWit activation, but we’ll probably have code for a blocksize increase. The thing is, part of the agreement was that the code would not be implemented by Core until after SegWit had activated.

At that point, I feel the guns may fall silent, and the great Bitcoin war could finally reach its conclusion.

Angel: scaling Bitcoin through an Internet of Blockchains (IoB)

Bitcoin needs to scale and there are many contradicting ideas on how to achieve this.

Sidechains are an inevitable solution. They allow Bitcoins to be transferred from the main blockchain into external blockchains, of which there can be any number with radically different approaches.

In current thinking I have encountered, sidechains are isolated from each other. To move Bitcoin between them would involve a slow transfer back to the mainchain, and then out again to a different sidechain.

Angel is a protocol for addressable blockchains, all using a shared proof of work. It aims to be the Internet of Blockchains (IoB).

Instead of transferring Bitcoin into individual sidechains, you move them into Angel. The Angel blockchain sits at the top of of a tree of blockchains, each of which can have radically different properties, but are all able to transfer Bitcoin and data between each other using a standardised protocol.

Each blockchain has its own address, much like an IP address. The Angel blockchain acts as a registrar, a public record of every blockchain and its properties. Creating a blockchain is as simple as getting a createBlockchain transaction included in an Angel block, with details of parameters such as block creation time, block size limit, etc.

Mining in Angel uses a standardised format, creating hashes which allow all different blockchains to contribute to the same Angel proof of work. Miners must hash the address of the blockchain they are mining, and if they mine a hash of sufficient difficulty for that blockchain they are able to create a block.

Blockchains can have child blockchains, so a child of Angel might have the address aa9, and a child of aa9 might have the address aa9:e4d. The lower down the tree you go, the lower the security, but the lower the transaction fees. If a miner on a lower level produces a hash of sufficient difficulty, they can use it on any parents, up to and including the Angel blockchain, and claim fees on each.

There are so many conflicting visions for how to scale Bitcoin. Angel allows the free market to decide which approaches are successful, and for complementary blockchains with different use cases, such as privacy, or high transaction volume, to more seamlessly exist alongside each other.

I wrote this as a TLDR summary for a (still evolving) idea I had on the best approach to scale Bitcoin infinitely, for more detail please check out my previous article.

photo credit: Colonelbogey71 Angel of the North via photopin (license)