Bitcoin vulnerabilities, such as the dreaded 51% attack, have long been known and theorized about. However, it was always believed should someone attempt exploit the defensive reaction of an angry, giant, economic freedom-loving community would be swift and fierce rendering any attack impotent. This rationale allowed Bitcoin advocates to sleep peacefully, considering such vulnerabilities a small annoyance at worst. The goal of strengthening and improving network functionality remained top priority.
Much has changed since the early days of adoption, when it was cautioned Bitcoin was an experiment. Several years on, indeed, the landscape looks completely different than anyone might have imagined. Far from a unified, productive community, we see a giant field of interests of varying skill, integrity and size, making up a hugely diverse sector loosely falling under the umbrella term "cryptocurrency". Many failed to appreciate the difficulty of moving forward together on a decentralized project. As such the anticipated solution to exploited vulnerabilities has become watered down. An unforeseen, minor spin-off crypto community under the moniker "Bitcoin Cash" is now being tested, alone, against formidable attack scenarios, which at worst could mean a forced re-evaluation of the entire notion of a decentralized cryptocurrency, not to mention the inability of passionate crypto advocates to assemble and work peacefully on a valuable offering. This wouldn't be due to weakness or lack of resource of honest principals, nor the cleverness or strength of an attacker, but rather the flawed, vulnerability inherent concept of using the longest valid chain as sole arbiter for official transaction history.
In this article I'll propose a fix for this flaw, which will coincidentally fix another potentially catastrophic non-attack scenario: unintentional chain splits.
Before going into the proposal it's helpful to review the necessity of the "longest valid chain" rule.

Bitcoin's Super Power

A touted strength of Bitcoin is its resilience. Early adopters often said the only way to stop Bitcoin was to shut down the internet and keep it off. How could a decentralized application still function? It was possible due to pre-agreement on the longest chain consensus rule. If the internet went down, say due to war, and sections came sporadically online it would still be possible to regain consensus since everyone would honor the longest valid chain. The network might be fractured short-term, but people would be wary of chains not sufficiently connected to the wider world as they might be superseded resulting in coins disappearing.
It's easy to under appreciate the value in consensus as a synergistic function; synergy describing a whole being greater than the sum of parts, just as a teacup is more functional than its fractured parts grouped together in any way other than its full synergistic form. Another comparable example is mass shootings which often result in at least ten people dying even from a lone gunman. If the location involved adults that count might always be reduced, perhaps to zero (since being shot doesn't always equal death), if only there was pre-agreement to simultaneously rush such an attacker. There wouldn't be time to fire more than a few rounds before being interrupted from all directions and likely overpowered.
In this way pre-agreement makes valuable functionality available by adding nothing new other than the agreement. For this reason we've tolerated worry over 51% attacks for going on ten years since Bitcoin launched.
I believe there is a better pre-agreement a crypto community can make to be so empowered. We gain it by introducing cheating. Tolerable cheating is an industry concept found in movie making. When filming it's often necessary to "cheat" by for example shifting furniture in a room to accommodate crew and equipment but which is never noticed in the finished movie because of the limitation on view for a shot.
We've always been guilty of cheating on decentralization. A new Bitcoin node starts by using a "DNS seed" hardcoded by developers telling it where to look to find the network. This involves trust. Developers sought better ways to bootstrap but nothing was obvious. We accept this cheat while nobody really complains. What I propose works similarly.

Consensus Reference Nodes

I propose creating what I call Consensus Reference Nodes (CRNs) which work something like name servers. Such nodes do very little, returning two pieces of information (block hash and block height). They allow a network to arrive easily at consensus or fail gracefully (waiting for human input). A CRN uses a Bitcoin node to catch up to the blockchain tip then puts itself into service after first arriving at consensus about block height. For status requests it returns the hash of what it considers the latest valid block, its block height. It's the responsibility of a CRN to make a judgment call about the best candidate chain of all it hears about. Node operators might work with a cryptocurrency's leading developers for abnormal situations such as unintentional network splits or attacks.
Operators perform a public service and likely rely on donations to keep nodes operational, but costs should be negligible. Basic hosting with free DDOS services from Cloudflare might be sufficient to serve several thousand nodes, where at present the Bitcoin BTC network has around 10,000 full nodes (being queried every ten minutes per node). Any entity or individual believed to be competent, reliable and a good actor makes a good operator. The minimum network requirement is any odd number of CRNs with at least three. Seven may be sufficient to start. Note CRNs process no transactions beyond normal full nodes so no added legal obligation should apply.
Full node software compatible with CRNs contains the list of CRN URLs which compatible implementations should mirror. The list can be made a consensus rule by for example making it part of a checkpoint hash used at initial startup. The node accepts a consensus confirmation as indicative of the next block on the official ledger. This occurs when a majority of CRNs return the same new candidate block. Nodes ignore new chains longer than one block in length. Failure to reach sufficient tally results in pause in operations and alert messaging for manual input.
Full node software configured as a CRN behaves similarly but works toward majority consensus also known as "consensus confirmation". A CRN chooses the highest priority score (described below) of candidate blocks and queries other CRNs for comparison. If a majority can't be assessed the CRN checks for newly valid blocks, reaffirms priority, and requeries other CRNs. Failure to reach sufficient tally results in pause in operations and alert messaging for manual input, while returning 'undefined' for client requests. This situation should only arise from unintentional chain split bugs. Nodes ignore new chains longer than one block in length. Only when a majority has been assessed will a CRN evaluate new candidate blocks.

Preventing DOS Attacks

An attacker with overwhelming hashpower can attempt to block legitimate transactions by mining empty blocks or filling blocks with their transactions. A solution to this was posted by Gavin Andresen in 2012. I propose a similar "priority score" be used with CRNs. Briefly, the score makes use of coin priority as derived from age. Generally the older the coin the higher its priority. Any attacker transacting his own coins would eventually run out of aged coins and be forced to include others.
The priorities of new candidate blocks in pseudo code:
if(input_age > 5 years){
priority = sum(input_value_in_base_units * 6 months)/size_in_bytes
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
This creates a sliding window of aging coins gaining higher priority while discounting threats from anyone who might have amassed lots of coins in the early days of Bitcoin adoption, or attempt to hoard them for future attacks. Since CRNs prioritize block candidates with the highest priorities an attacker risks having found blocks discarded in favor of ones with more priority transactions.

Benefits and Drawbacks

This model eliminates the threat of double spends or unwinding transactions from attackers with any amount of hashpower because the longest chain is irrelevant. The official chain is determined by and more likely to include blocks with large numbers of high priority transactions. There are no chain reorganizations. A transaction with a single consensus confirmation (in about 10-15 minutes) has the same degree of settlement finality as one with six confirmations in the traditional model.
Sustained DDOS attacks are less than 100% effective for an attacker having up to 90% of network hashpower. As long as there is some competition contesting low priority blocks legitimate transactions will go through. Large block sizes and a minumum fee threshold used in concert should render the worst attacks tolerable.
Chain splits repair themselves automatically in many cases, and can be better managed by developers in real time. In the worst case nodes pause operation awaiting human input so funds don't going missing and miners don't waste hashes. A network supporting an economy measured in billions of dollars is expected to handle software bugs gracefully.
Another benefit is reduced dependence on hashpower for security. Since ledger alteration ability is shifted into a different model security is no longer directly correlated with hashpower; the age old question of how to secure the network when block rewards run out can be answered. This doesn't mean mining is automatically made obsolete. It still remains a great free market way to create coins and bring them into circulation. As financial incentive to mine trends lower, however, the network need not be any less secure.
A drawback of this approach is of course the move toward centralization. Smooth network operation requires some recognition of development authority as CRN lists must be authored and updated over time. Additionally, CRNs themselves might be subject to social engineering attacks, corruption or other problematic issues. However, such concerns are likely easier to address than undefined dangers always looming in the form of 51% attack threats because power remains well distributed overall. Varying roles have controlling influence over narrow slices of the complete system. No system will be perfect nor purely decentralized as proven. Increasing CRN count can adds fault tolerance and decentralization back in as well, using 999 for example.
There doesn't appear to be severe attack vectors of note. Although some may crop up given enough time they should be more easily defended against under this model, because there is a greater degree of control over the system.


A rule targeting the longest valid chain or so-called "Nakamoto consensus" is a nice idea on paper, but in practice when considering specialty machines, human nature and a myriad of problem scenarios it doesn't work well for something as important as financial settlement.
Bitcoin is still going strong after years of proving naysayers wrong, but its debut technology is antiquated. To meet the needs an intrigued public is sure to place on it in the coming years it must be more reliable, confidence-inspiring and predictable. It's time for an upgrade.



No one has reviewed this piece of content yet
  earned 0.0¢
It opens up several Sybil attack vectors, and creates a centralised repository of information... no ideal, my friend. Is it not a bit like how Dash works?
   8mo ago