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.

The Nuclear Option: BIP148 + MR POWA

This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it – just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade to SegWit. This is pure game theory.

MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.

In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.

At this stage the software would change its consensus rules (hard fork) to do two things:

  • Lower the difficulty for existing PoW method (SHA256).
  • Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.

    The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.

    This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.

    Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to ‘hold their nerve’ as they would be guaranteed a viable chain and rewarded for their early support.

Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I’m very worried about the state of miner centralisation in Bitcoin.

I always felt the centralising effects of ASIC manufacturing would resolve themselves once the first mover advantage had been exhausted and the industry had the opportunity to mature.

I had always assumed initial centralisation would be harmless since miners have no incentive to harm the network. This does not consider the risk of a single entity with sufficient power and either poor, malicious or coerced decision making. I now believe that such centralisation poses a huge risk to the security of Bitcoin and preemptive action needs to be taken to protect the network from malicious actions by any party able to exert influence over a substantial portion of SHA256 hardware.

Inspired by UASF, I believe we should implement a Malicious miner Reactive Proof of Work Additions (MR POWA).

This would be a hard fork activated in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork.

The activation would occur once a fork was detected violating protocol (likely oversize blocks) with a majority of hashpower. The threshold and duration for activation would need to be carefully considered.

I don’t think we should eliminate SHA256 as a hashing method and change POW entirely. That would be throwing the baby out with the bathwater and hurt the non-malicious miners who have invested in hardware, making it harder to gain their support.

Instead I believe we should introduce multiple new proofs of work that are already established and proven within existing altcoin implementations. As an example we could add Scrypt, Ethash and Equihash. Much of the code and mining infrastructure already exists. Diversification of hardware (a mix of CPU and memory intensive methods) would also be positive for decentralisation. Initial difficulty could simply be an estimated portion of existing infrastructure.

This example would mean 4 proofs of work with 40 minute block target difficulty for each. There could also be a rule that two different proofs of work must find a block before a method can start hashing again. This means there would only be 50% of hardware hashing at a time, and a sudden gain or drop in hashpower from a particular method does not dramatically impact the functioning of the network between difficulty adjustments. This also adds protection from attacks by the malicious SHA256 hashpower which could even be required to wait until all other methods have found a block before being allowed to hash again.

50% hashing time would mean that the cost of electricity in relation to hardware would fall by 50%, reducing some of the centralising impact of subsidised or inexpensive electricity in some regions over others.

Such a hard fork could also, counter-intuitively, introduce a block size increase since while we’re hard forking it makes sense to minimise the number of future hard forks where possible. It could also activate SegWit if it hasn’t already.

The beauty of this method is that it creates a huge risk to any malicious actor trying to abuse their position. Ideally, MR POWA would just serve as a deterrent and never activate.

If consensus were to form around a hard fork in the future nodes would be able to upgrade and MR POWA, while automatically activating on non-upgraded nodes, would be of no economic significance: a vestigial chain immediately abandoned with no miner incentive.

I think this would be a great way to help prevent malicious use of hashpower to harm the network. This is the beauty of Bitcoin: for any road block that emerges the economic majority can always find a way around.

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

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

A tragedy on our hands? What if miners would rather have higher fees than bigger blocks?

We’ve got so caught up in the whole SegWit and Bitcoin Unlimited dispute that there’s something we may all have overlooked.

For either of these changes to be activated requires miner support, of which neither side has anywhere near enough.

What if the reason we’re seeing no progress is because miners don’t want the block size to increase?

While we’re all desperate to see scaling solutions, the miners are sitting there and quietly collecting record fees.

I’ve compiled the fee data over the last 2 years and created 10 day averages of the price in USD.

Here are the results:




The above graph shows the fees miners receive on average per block.

It also shows what would have happened if the initial rate of $60 per MB had continued as the blockchain grew.

As you can see in the last two years miners have gone from earning fees of next to nothing per block ($25) to now averaging over $1000.

This rate equates to more than $52m extra per year for miners compared to two years ago, as demonstrated by the graph below:


Are the miners happy with the status quo? They sit back quietly collecting record fees while the rest of the community fights amongst itself.

The most recent rate equates to $54m in fees per year. At $1000 per BTC there is currently $657m new Bitcoins created each year. This means fees currently make up 8.2% of miner revenue and is growing exponentially.

Doubling the blocksize would not see fees halve. More likely we’d see fees fall to the rate when blocks were half full. This would see miner fee revenues falling from around $1100 per block to perhaps $70 per block – and we’re asking them to impose this upon themselves!

A real tragedy of the commons may be upon us. It doesn’t matter what scaling option you support if the miners won’t implement any of them, instead opting to accumulate as many Bitcoins as possible until other scaling solutions they cannot impede emerge.

I have my suspicions that on the whole miners currently favour Core, but are happy to exploit the community disharmony and delay on-chain scaling for as long as physically possible. Their actions only heighten the tension and inflicts real damage.

Instead of being divided, let’s unite in putting pressure on the miners. Until we know we can even overcome this obstacle the rest of our debate may be a futile waste of energy.

Nothing unites humans like a common enemy.

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.

Proof of Nodework (PoNW) – trustlessly rewarding nodes for storing and verifying the blockchain

Proof of Nodework (PoNW) is a way to reward individual nodes for keeping a full copy of and verifying the blockchain.

Hopefully they also do useful ‘traditional’ node activities too like relay transactions and blocks, but there isn’t really any way I can think of to trustlessly verify this.

PoNW would require a new separate area of block space, a nodeblock, purely concerned with administering the system. A nodeblock is committed to a block as with SegWit. A recent history of nodeblocks needs to be stored by nodes, however the data eventually becomes obsolete and so does not need to be retained forever.

In order to prevent Sybil, a node must register a Bitcoin address by submitting an addNode transaction – along with a security deposit to prevent cheating.

This transaction will be stored in the nodeblock. Once a node can see that its addNode transaction has been added it can begin the PoNW process. The node’s registered address will be hashed with the block header of the block it wants to work on. This will determine exactly where within the blockchain to begin the PoNW.

The PoNW method could be as simple as creating a Merkle tree from the randomly generated point on the blockchain, though a method that is CPU/Memory heavy and less likely to be outsourced to dedicated hardware like ASICs would be better. This process could not begin until the most recent block has been fully verified, and while being carried out should still enable normal relay activities to proceed as normal, since it shouldn’t tie up network at all. The data processed should also be mixed with data from the latest block so that it cannot be computed in advance.

A node can do as much PoNW for a block as it likes. Once finished it will then create a nodeWorkComplete transaction for that block with its final proof value, add how much ‘work’ it did – and create a couple of assertions about what it processed (such as there were x number of pieces of data matching a particular value during calculating). These assertions can be accurate or inaccurate.

The system will run in epochs. During each epoch of say 2016 blocks, there will be an extended window for PoNW transactions to be added to nodeblocks to limit minor censorship.

The random hash generated from a node’s address and blockhash will also be used to determine nodeWorkComplete transactions from a previous block that the node must also verify, and correctly calculate whether the assertions it made were true or false. The average PoNW that a node performed in its previous x nodeblocks will be used to determine the target PoNW for the node to verify – and this will randomly be a large number of smaller PoNW transactions, or a smaller number of large PoNW. This process will be deterministic based on that block and address hash. All the data will be put together in a transaction and then signed by the node addresses private key.

If a nodeWorkComplete transaction contains any incorrect information in an attempt to cheat the validation process a challenge transaction can be created. This begins a refereeing process where other nodes check the challenge and vote whether it is to be upheld or not. The losing node is punished by losing their accrued PoNW for that epoch and a percentage of their security deposit.

Nodes will also be punished if they broadcast more than one signed transaction per block.

In order to prevent nodes from having multiple keys registered – which would enable them choose to perform PoNW on a subset of the data that they hold – the share of reward that the node gets will be multiplied based on the number of blocks within an epoch that the node performs PoNW on. The share of reward is limited based on how much security deposit has been staked. The higher the PoNW the higher the deposit needed in order to claim their full allocation of any reward.

The amount of work a node has to verify from previous blocks should be random and hugely variable. This means that nodes are discouraged from doing “too much” PoNW on average as occasionally they will have to verify a lot of extra work for which they should leave a large buffer of capacity. Node reward will be penalised for skipping large verifications. This prevents the nodes being constantly tied up doing work and frees resources for traditional node functions.

At the end of an epoch, with a wait period for any delayed or censored transactions or challenges to be included and settled up, the process of calculating the reward each node is due can begin. This will then be then paid in a regular block, and means for all the data involved in PoNW, the only permanent mark it makes on the main blockchain is for a transaction that pays all addresses their share of the reward at the end of epoch. Any miner who creates a block without correctly calculating and paying the due reward will have mined an invalid block and be orphaned.

The question of where and how much the reward comes from is a different one. It could come from the existing miner reward, or a special new tx donation fee for nodes. If there was some way for users to ‘donate’ to the reward pool for nodes this would increase the incentive for additional nodes to participate on the network in the event of centralisation.

This is a relatively effective way to create a reward for all nodes participating on a network. I’d be keen to field any questions or critiques.