The great P2PK Bitcoin heist. Millions of Bitcoins WILL be stolen, but should we even try to stop it?

First of all, do not worry, your Bitcoins are safe (unless you have certain unspent coins from 2009-2011, I’m looking at you Satoshi Nakamoto). The headline is not sensational though, unless action is taken it is inevitable that at some time in the future millions of Bitcoins will be stolen. You could argue that rather than theft, they’d be claimed as a bounty and returned to circulation, but I’ll talk more about that later.

What are P2PK Bitcoins, and why they are at risk?

Bitcoin works using asymmetric public key cryptography. Huh? Basically, every Bitcoin account is associated with a public key and a private key which are mathematically linked.

In simple terms, the public key is the destination where Bitcoins are ‘received’, and the private key is a secret password that allows only the holder to create a valid transaction signature which will spend the Bitcoin to a different public key.

As long as nobody knows the private key, they cannot steal your Bitcoin. The ECDSA signature scheme used by Bitcoin makes it impossible to calculate or reverse engineer the private key from the knowing public key, for now that is.

You see, cryptography is a constantly evolving area. The security of cryptographic algorithms typically lasts in the decades before they become vulnerable to attacks or are ‘cracked’.

Fortunately, even if it one day becomes possible to reverse engineer the private key from the public key, Bitcoin has a trick up its sleeve.

A Bitcoin address isn’t actually a public key, it is a hash of a public key. I discussed hashes in a previous article, but basically they consistently scramble the data and cannot be reverse engineered. This means that until someone creates and broadcasts a transaction to spend the Bitcoins held in an address, the public key itself is kept secret. This is brilliant since a hash is impossible to reverse, it is impossible to even attempt to crack those Bitcoins even if the encryption algorithm is broken.

Unfortunately in the very early days of Bitcoin there was period before paying to public key hashes (P2PKH) became the standard. Instead, it was common to pay to public keys (P2PK) directly. It is those P2PK Bitcoin that will one day be at risk.

Right now, ECDSA is considered rock solid, with elliptic curve cryptography first proposed in 1985 and no major vulnerabilities discovered in the decades since. There is one major known problem however: Shor’s algorithm.

Shor’s algorithm can be used to break elliptic curve cryptography on quantum computers. The good news is that we have a long time to go until quantum computers are sufficiently advanced that they reach this milestone.

The current cutting edge of quantum computing sees Google ahead at 72 qubits, followed by IBM (50 qubits) and Intel (49 qubits). Even then, these early machines are huge, require extensive cooling and are likely unstable.

For perspective, it will take a quantum computer with 2330 qubits before it even becomes viable to crack an ECDSA private key from a public one. Even then, it won’t be as simple as immediately cracking it, likely taking weeks, months or initially perhaps even years of computation. It will likely follow as with binary computing where giant expensive supercomputers costing millions of dollars gradually transitioned their way to the consumer market over a period of of decades.

I have no idea how long it will take until we have a viable quantum computer, but for perspective the $8m 1975 Cray-1 supercomputer achieved 80MHz and 136 MFLOPS. This performance wasn’t seen in the consumer market until the mid-1990s. These days you can get the latest Raspberry Pi for around £35 ($45) which has a 4x1100MHz CPU achieving over 6,000 FLOPS. Outrageously speculating a similar progression, 40 years from now could see very inexpensive quantum machines that could trivially claim any remaining P2PK Bitcoins, though they would likely have already all been claimed perhaps decades earlier!

Cray-1 Supercomputer

Even when the first machines are created that hypothetically could crack an ECDSA private key, it’s unlikely these very expensive machines will be used for this purpose unless the reward for doing so was incredibly high. Most P2PK Bitcoin accounts typically hold a 50BTC balance. If a multi million pound computer takes a month of processing to crack one of these, that’s a huge opportunity cost when it could be working on other potentially lucrative applications such as AI and curing diseases.

We already have new cryptographic algorithms available that are quantum resistant, and Bitcoin was designed with such upgrades in mind. These signatures use more data so there just isn’t any point in switching until it becomes necessary.

Even if ECDSA somehow became completely broken tomorrow, the use of hashed public keys means we’ve already devised methods (such as commitments) to allow us to move any P2PKH Bitcoin to a new algorithm without any risk of theft. Broken encryption is not an existential risk to Bitcoin that should create panic, the P2PK issue is just a legacy of a small oversight in the very early days of Bitcoin.

As a side note, if you reuse a Bitcoin address you have already spent from you have also revealed your public key to the world and are at risk of one day having your Bitcoin stolen. Address reuse has been warned against since Bitcoin was first created, but people still do it. Many will no doubt have their funds stolen one day, but that is their fault for ignoring the warnings, so please make sure you’re not one of them.

Who is going to lose their Bitcoin?

I’ve not checked exactly how many, but there are millions of P2PK Bitcoin that unless action is taken will be stolen. Luckily it is likely that nobody at all will lose their Bitcoins. Huh!? You see, the P2PK heyday was 2009-2010. In the days of CPU mining the original Bitcoin software would unfortunately pay the 50BTC block reward directly to P2PK, a small oversight. As soon as any of these Bitcoins were later moved, they became safe, since transactions have always been P2PKH (except for a tiny number of the quickly abandoned ‘IP transactions’ in 2009).

The beginning of the end for CPU mining was late 2010 as people started mining with GPUs requiring different software. There are millions of mined Bitcoins from those early days that have sat untouched ever since. Satoshi Nakamoto alone has around a million of them!

It’s incredibly unlikely that any unclaimed Bitcoins from back then still have owners, except perhaps those held by Nakamoto himself. In those days Bitcoins were practically worthless and it is reasonable to assume that anybody mining then who still hasn’t spent them probably threw away their hard drive a long time ago like this gentleman. Seeing their Bitcoin rendered unspendable or stolen might give these poor souls some closure rather than spend their lives desperately rummaging through landfill.

Fortunately there is a trivial fix, as anybody that does still hold P2PK Bitcoin from these early days can simply move them and they will be secured. This simple fact is the reason it is unlikely any Bitcoin the owner wants to keep will be stolen.

So, millions of ownerless Bitcoins will be stolen! How do we stop this, and should we?

I discussed the P2PK problem at the last Bitcoin meetup I was at. The idea of Satoshi Nakamoto’s early bitcoin re-entering circulation certainly caused a stir. One person argued it was part of the ‘social contract’ of Bitcoin that those coins would never be spent. It is widely believed that Nakamoto has no intention of ever doing anything with those coins even if he does still hold the private keys. There was even some support for the idea of hard forking to make these Bitcoins unspendable forever anyway, just incase he did try to move them. I personally think such a move would undermine the durability of Bitcoin and set a dangerous precedent.

That said, the question of what we do about millions of unclaimed Bitcoins being potentially stolen by quantum computing pioneers and returned to circulation is a more difficult one.

The only thing we could really do to prevent this is creating a hard fork that at some future point makes all remaining P2PK coins unspendable forever so they cannot be stolen, irreversibly shrinking the supply.

Anybody with P2PK coins would have until that date to move their coins to a new address to protect them from loss. This seems a reasonable approach, nobody is losing anything, and everybody else benefits as coins that are ownerless remain that way forever and the current status quo is maintained. The supply remains smaller and everybody else’s Bitcoin are more valuable as a consequence.

Making P2PK Bitcoins unspendable could potentially force Satoshi Nakamoto’s hand. If he is still alive and wanted to keep his coins, he would be forced into action potentially causing a huge impact on the market. Alternatively if we didn’t hard fork and he wanted to prevent his coins getting stolen he could move them to a burn address. This would make them forever unspendable anyway, minimising the impact on the market, but any activity would certainly fire up the debate around him and at least show the world he is still alive.

There is another perspective. Claiming quantum vulnerable P2PK Bitcoin will be a similar process to mining. It will require an outlay on hardware, and much like hashing will consume time and electricity. Bitcoin will be earned as reward for their efforts based on how much computation they have contributed to the process. At some point this ‘quantum sweeping’ will become a profitable endeavour. Unlike mining, the difficulty won’t change, it will only get easier and cheaper until all P2PK Bitcoin have been claimed.

There are so many variables in establishing when and over what period this heist might take place, and who would benefit. The quantum computing pioneers in IBM, Intel and Google would certainly have a massive head start. And since they are contributing billions of dollars to developing technology that could benefit all of humanity, don’t they deserve to be rewarded for their efforts by claiming the bounty accidentally left on the Bitcoin blockchain? It’s not inconceivable that if the value of bitcoin was sufficiently high, all the worlds early quantum computers could be dedicated to claiming the P2PK bounty.

What we should do is not a question I have the answer to, the Bitcoin community will have to form its own consensus in the future. Either way, it’s going to be an exciting debate to have.

Follow up: Bitcoin Cash has 51% attack vulnerability double jeopardy

Yesterday I wrote about how Bitcoin Cash (also bcash/BCH) has a major vulnerability that because it is running far ahead of the bitcoin blockchain, it is going to have a window at the next halvening where it is susceptible to a heavily discounted 51% attack, the mere threat of which could end up being self fulfilling.

After reading my article, some people speculated that Bitcoin Cash has a new difficulty adjustment algorithm (DAA) that is targeted to ‘just over 10 minute blocks’, slightly slower than Bitcoin, meaning that it will have caught up by 2020.

Those people are wrong. Both Bitcoin and BCH have the same 10 minute target difficulty.

They are right that BCH has been producing blocks more slowly, but the reason for this is because it has been losing mineing hashpower to Bitcoin, coinciding with a relative fall in its value.

At the time of the new DAA on 13 November 2017, BCH was trading at around 0.2 BTC. Since then, with a couple of suspiciously brief pumps along the way, that figure has gradually halved and BCH is now trading at under 0.1 BTC.

That means the only way BCH can avoid being vulnerable to a period of heavily discounted 51% attack (other than through yet another hard fork), is by hoping its value continues to fall in relation to Bitcoin, so miners continue to switch away and the network continues producing blocks at a slightly slower speed.

The DAA hard fork on the BCH chain took place at block #504031, while the next Bitcoin block to be found was #494238, a difference of 9,793 blocks.

As of yesterday, that gap had fallen to 6,844 blocks, those pointing out BCH has been catching up were correct, they’ll just be disappointed by the reason why. That difference means in the last 8.5 months (259 days), it has gained back 2,949 blocks while its relative market value has roughly halved.

I’m not quite sure or whether it’s even possible to sufficiently correlate or calculate the fall in price required to catch up, since there is so much variance, but if we use incredibly rough figures that BCH gaining 2,949 blocks requires roughly losing half its value to BTC, the value needs to halve another 2.3x, taking the value of BCH to somewhere around 0.02, or 2% the value of BTC, by which point it would have long been vulnerable to 51% attacks anyway.

The worst case scenario for Bitcoin Cash would be that it’s value continues to slide, but just not quite enough for the Bitcoin blockchain to catch up, since a successful and damaging attack could take place with a window of just hours, far less than the current rough 48 day estimate.

Actually, I guess the other and more likely worst case scenario is that just continues its slide into irrelevant obscurity, but only time will tell. My previous post on this vulnerability was downvoted to oblivion on the /r/btc subreddit, the echo chamber would prefer to bury its head in the sand so I’m sceptical any solution will be forthcoming. I kind of hope it does remain unfixed, it would create a fascinating opportunity for miners as an observer, a potentially magnificent demonstration of game theory in action.

Bitcoin rival has a major vulnerability which could help Bitcoin miners to destroy it in 2020

TLDR: Due to a flawed emergency difficulty adjustment at its creation, Bitcoin Cash is now running ahead of the Bitcoin blockchain. Since future supply ‘halvenings’ should occur around 48 days before the Bitcoin network, it creates a window where it is ‘half price’ to 51% attack the network. The mere threat could cause the value to fall in anticipation, creating a feedback loop that makes such an attack increasingly inevitable and its outcome even more devastating.

Supporters of Bitcoin Cash (also called BCH and bcash) love to talk about a hypothetical “flippening”, a scenario in which a rise in the value of BCH would see miners switch away from the main Bitcoin blockchain causing the block production speed there to slow. They believe that with the Bitcoin blockchain operating at capacity, the network performance would suffer thus further reducing the value of Bitcoin and increasing the value of BCH which has a higher onchain capacity.

This, they speculate, would create a feedback loop, ultimately resulting in the Bitcoin blockchain completely grinding to a halt as miners jump ship for the more profitable BCH chain which would rise triumphant and replace Bitcoin as #1 cryptocurrency.

This is all pie in the sky fantasy, completely misunderstanding the complex and mature ecosystem that has formed and the incentives of those who operate within it. It simply will not happen. I am simultaneously amused by and feel bad for those who invest heavily in altcoins in the naive hope a flippening in value will occur.

However, there is a flippening of sorts looming for BCH that I have not yet noticed any consideration given towards.

One of the rules of the Bitcoin network, that BCH also inherited, is that every 210,000 blocks (approx 4 years) the supply of new coins created with each block is halved, in a much celebrated event known as “the halvening”. This also causes the profitability of mining to halve since in 2020 the supply of new coins created will fall from 12.5 to 6.25 per block.

To uncover why this may create a problem for BCH we must look back to its creation. In order to deviate from the Bitcoin network and create a new version, it underwent a process known as a hard fork.

The main rule change was to increase the block size, however as the BCH developers knew there would likely not be much support for their fork they also added a bit of code called an emergency difficulty adjustment (EDA). This is because the difficulty determines how frequently new blocks are created. If you reduce the volume of miners without reducing the difficulty, block creation can take a much longer time. Losing 80% of the mining hashrate would result in blocks only being created every 50 minutes instead of 10, and consequently the mechanism to readjust difficulty every 2016 blocks could take as long as 10 weeks instead of the usual 2. The EDA meant that instead of adjusting the difficulty every 2016 blocks it could readjust down based on just the last 6 blocks.

As with many ‘simple’ changes, this had major unintended consequences as it created an incentive for miners to collectively hold off on mining until the difficulty was really low, and then suddenly start mining blocks again really quickly at high profitability. This caused huge fluctuations in difficulty and at times made the BCH network grind to a halt while no blocks were being created, while at other times they were being churned out in seconds.

The BCH network had no choice but to introduce yet another hard fork to fix the difficulty adjustment algorithm. Hard forks require that every single participant on the network upgrades their software or gets kicked off, so handing them out like Oprah gives away cars is not ideal.

Oprah hard fork giveaway

By the time the problem was resolved, the BCH block count had rocketed ahead of the main Bitcoin blockchain.

At the time of writing, BCH is on block #541236 while Bitcoin is on block #534392, a difference of 6,844 which at 10 minutes on average means that the BCH halvening is currently expected to occur approximately 48 days before it does on the Bitcoin blockchain.

At that point, the reward for creating a new BCH block will fall to 6.25, while on the Bitcoin blockchain it will remain at 12.5 (plus higher fees).

The market currently values BTH at around 10% the value of a Bitcoin and the hashrate roughly correlates with the price.

That would mean, at current prices, to mount a 51% attack on BCH would require just over 11% of the Bitcoin hashrate switching over to make that attack.

For a 48 day window in 2020 (and then every 4 years) that dynamic will change, and the cost to attack the network will suddenly halve. Suddenly just 6% of the Bitcoin hashrate would be sufficient to mount a 51% attack against BCH, well within the capabilities of a number of mining pools.

There are a number of ways to ‘short’ cryptocurrencies. Shorting is basically betting that a value will fall, and profiting if it does. Anyone mounting a 51% attack successfully would cause the value of that cryptocurrency to fall, with shorting creating an easy opportunity for them to profit.

A 51% attack itself provides other opportunities for an attacker to profit, most notably through a double spend attack. This could be achieved by depositing a large quantity of BCH onto an exchange, converting and withdrawing them as something else, and then reversing the original transaction so the exchange is out of pocket and the attacker keeps their original BCH.

However an attacker chooses to profit from a 51% attack, the outcome will almost always be a fall in value of the cryptocurrency as people lose both trust in its security and their money.

These rough figures are based on a BCH/BTC rate of 0.1 and ignore the even higher fees available on the Bitcoin network. Since the value of BCH has already been falling for some time it could easily be much lower by 2020. This means an attack would become even cheaper and even more likely.

The increased risk of a 51% attack during period is likely to decrease the price in anticipation of it. This could create a feedback loop where the increased risk caused by the price falling causes the price to fall even further. Miners could engage in all kinds of game theory here: merely hinting they are considering attacking the network would likely cause a downward pressure on price making the cost of an attack even lower.

In summary, hard forks are risky and can introduce a whole host of unintended consequences. While the BCH community may now think their difficulty adjustment woes are behind them, there may be other nasty surprises lurking ahead.

A quick reminder on why we can’t depend on the block reward until 2140

I used to argue that we shouldn’t worry about a lack of fees because blocks were subsidised ‘until 2140’. I thought it would be a problem ‘for the future to worry about’. I figured the world would have changed so much by then that there was no point limiting ourselves now, and that they’d be able to ‘figure it out’.

Then I realised that I was wrong – 2140 isn’t the year to worry about.

We are now closer to 2024 than we are to 2009 when Bitcoin began. In 2024 the block reward will fall to just 3.1BTC.

In 2028 it will be 1.6BTC, and in 2032 we’ll be at less than 0.8BTC. This reward will continue falling for another 108 years until block subsidies end in 2140 – the year I naively perceived as the time the lack of block reward would become ‘a problem’.

A simple look at the numbers tells us this is something we need to consider a lot sooner.

In February I analysed how much the fees had increased. On 6th March 2015 the average cost over 10 days for 1MB of transactions was $67.

On 6th March 2017, that number has increased to $1912.

This is supply and demand in action, literally how free markets work. When there is an abundance of something it becomes extremely cheap. When in short supply it becomes expensive.

People argue that if we made the blocks bigger so they weren’t full, the miners would be able to include more transactions so they could receive more reward.

Let’s take an objective look at the facts. The numbers show us that when blocks aren’t full miners have, even in recent years with high Bitcoin value, accepted less than $67 per MB.

Only when the blocks have become full has the pressure on fee prices skyrocketed to $1912 per MB.

This means that at $67 per MB to earn the same fees miners would right now need to be mining 29MB blocks.

Even if this didn’t have centralisation issues, the transaction volume just isn’t there yet to achieve it.

Another argument can be made that the current 12.5BTC reward means this is less of an issue right now – and that is a very valid point. We do have room to increase the block capacity without a short term fear over mining incentive, and we should if the miners will let us.

The concern is that in 7 years time we’re going to be mining blocks with just 3.1BTC of reward. The simple and indisputable fact is that the less reward there is for mining a block the less secure the network is, and this is a problem we’re going to face a lot sooner than 2140.

If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

How user activated soft forks (UASF) work and why they might solve the blocksize debate too

For a soft fork to activate miners currently are required to signal their support. For SegWit that requires 95% of blocks over a 2016 block window signalling in favour.

Currently the Bitcoin network has around 6,000 nodes. ~5,000 of those are running Bitcoin Core, and ~3,000 nodes are running Bitcoin Core versions that fully support SegWit (>=0.13.1).

Those 3,000 nodes, despite being SegWit ready, can currently do nothing more than wait for miners to activate it. This just isn’t happening, and they are being denied all the benefits that come along with it.

UASF would mean there is no signalling by miners for activation. Instead a new version of the Bitcoin software is released and installed on nodes which has an agreed activation point in the future.

At the time of writing we’re at block #455855. If we wanted to activate SegWit in 90 days time (approximately 12,960 blocks), the new version of the software could say “from block #468,815 only accept blocks that support SegWit”.

Let’s imagine that by block #468815, 60% of nodes have upgraded to this new version of the software. In addition a number of large exchanges and Bitcoin businesses have also publicly announced their support and upgraded.

This gives miners a conundrum. If they don’t create SegWit compatible blocks from that point all those nodes and businesses will completely ignore the blocks they create. This would prove very expensive.

SegWit blocks will be backwards compatible, as nodes that haven’t upgraded their software will still recognise them as valid.

This means that the odds of SegWit activation succeeding are massively stacked in its favour, as the miners are the only ones who incur an economic cost if they make an incorrect decision about activating. By far the safest option is to mine blocks compatible with SegWit as these will be accepted by 100% of nodes, rather than the 40% of non-upgraded nodes and economic minority.

So that’s the basics. The nodes basically tell the miners that if they don’t play ball they will be ignored. It would take an incredible amount of nerve (or stupidity) for a miner to refuse to mine SegWit compatible blocks when such a huge part of the network will suddenly start invalidating their work.

If just 51% of miners update then SegWit would activate without any issues.

I don’t believe SegWit would struggle to gain miner consensus, but in the unlikely event that over 51% of miner hashrate refused to switch this would create a fork in the network with non-upgraded nodes seeing one version of the blockchain, and upgraded nodes seeing another.

I believe a more likely outcome is that a rival implementation of the bitcoin software would use the activation point as a catalyst and attempt to rally support for and introduce a change of their own.

This wouldn’t be a property of UASF itself, but an activation point creates a natural window of opportunity to force the community to make a choice between rival visions.

Instead of a soft fork, a rival implementation could activate a hard fork block size increase. In addition they would likely need to change how quickly the difficulty is adjusted and hopefully add replay protection.

This would lead to all nodes and miners having a clear choice between two directions for Bitcoin. The likely reason a rival implementation wouldn’t attempt this is because they feared humiliation, but a set activation point would present a perfect opportunity to also force a referendum on the block size debate to those with the conviction to back their belief.

There would likely be just one winner, with an economically insignificant altcoin created on the other side. The block size debate would finally be settled once and for all.

If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

SegWit facts – Not ‘anyone can spend’ so stop saying they can

Anybody who argues against SegWit because it uses “anyone can spend” transactions is either being disingenuous does not understand what they are talking about.

“Anyone can spend” is just words to describe a transaction which has no conditions attached to how its output can be spent. This has been part of the Bitcoin protocol since… forever.

To prevent old nodes from being excluded from the network, as in the case of a hard fork, SegWit uses a clever trick that enables old nodes to see SegWit transactions by making them appear as ‘anyone-can-spend’.

The fear of the misinformed is basically that the new transactions created by SegWit will be insecure because “it says ‘anyone-can-spend’, duh.”

The problem is, this is just plain false. Segwit is a softfork which means miners introduce new rules. The new rules mean that although SegWit transactions superficially appear to old nodes as ‘anybody-can-spend’ – the rules dictate that these transactions cannot be spent without a valid signature.

The ‘worst case scenario’ is that miners could mine a block that breaks these rules and old nodes would still recognise it as valid. It is foolish to consider this a genuine risk.

The miner would be wasting all their resources mining an invalid block, and for what, to make a few remaining old nodes think some SegWit transactions had a different owner? What would they accomplish?

The answer is nothing at all. Their block would be orphaned almost immediately. Nobody would be affected except the miner.

Anybody who persists in making this argument is lying or dim. By exposing themselves as either of these things they completely undermine their cause and can be safely dismissed.

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 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:

  1. Assuming the price continues to fall by 23% each year
  2. 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

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

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:

  1. How much space they use
  2. What fees they generate

This shows how the fees generated and capacity used were distributed:Distribution of Satoshis per byte

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.

Manipulated Distribution of Satoshis per byte

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!

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.


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.

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)