Nov 15th BCH Fork: Nakamoto Consensus will FINALLY be tested!

Nakamoto Consensus is upon us! All hail!

With the first real hash vote ever to occur in Bitcoin Cash set to occur in less than 10 days, it’s time to take a step back and really take in the enormity and the significance of this event.

We are literally seeing the FIRST practical application of a mass decentralized consensus system (aka ‘vote’) that needs no administrator, no organization, no coordination, no public debate, no polling stations, nor any face to face meetings! It is Nakamoto Consensus, as Satoshi created it. It itself is a pure system. Like the evolution of life, it needs no coordinator. Nobody tells a honey bee how to build the cells in the hive. Nobody tells each ant what to do or manages its daily work schedule. Nature just figures this out by way of naturally finding the most efficient solutions. But humans are a strange creature. We like to think. We rationalize. We are a social animal, and as such, we are predisposed to rely on social consensus systems. We create rules for ourselves, and we like to negotiate these rules amongst ourselves so that everyone concerned feels like their individual needs were considered, for a common sense of enfranchisement.

But Nakamoto Consensus doesn’t work like that. It, like mother nature, has a very simple rule: those who behave in a coordinated way that benefits the network will profit more than those that defy consensus. It’s as simple as that. The only remaining thing we need to add to that formula to make it all work is the simple assumption that people tend to want to be profitable, rather than not. With that one simple assumption, the automatic consensus system is complete, and we can rest assured that consensus will be obtained, passively, automatically, without supervision or orchestration.

Well, at least in theory. That is the idea of how it will work, but because Nakamoto Consensus is a ‘natural’ system, it is very hard to analytically work out exactly how long the consensus process will take in practice. There are just too many variables that factor into this equation to model, and much like trying to predict the market, which is the sum aggregation of millions of independent decisions being made by individuals, it is not trivial. That is what makes what will happen on Nov 15th very interesting to those of us who have been in Bitcoin for years, but have never been able to witness how well it holds up in defending against competing protocol changes via a hash vote.

As is the case for most natural phenomena which have yet to be well understood, there is no lack of theories concocted by pundits on all sides on whose votes actually count in such a hash vote. Their arguments generally fall into one of the following categories:

Individual Nodes decide

This is the belief that a majority of the nodes in the network (ones run by individuals like you or I) collectively decide what the network will accept as protocol changes. This is of course, a fallacy, because it is only in the extreme case where all nodes of the whole network were controlled by a collective power would all the nodes be able to rob the dissenting miners of the value of the rewards that they mine. This is of course an impossible situation on premise alone as the assumption is that the nodes are individually controlled. If we had a system that could coordinate the collective behavior of all the individual nodes in the network, then we would have no need for a decentralized consensus system in the first place. This misguided belief was the origin of the “UASF” movement, which was a grass-roots lobbist group which tried to convince the market that the node population (the common man) had enough power to influence network changes. They were never given a chance to be proven wrong, unfortunately, as after the NY Agreement, the supporters of big blocks conceded to split off into BCH instead of forcing the fork.

The ineffectiveness of individual nodes and their irrelevance to the network was later demonstrated when researchers confirmed that the Bitcoin network was a small world network, (one in which the number of average hops between any given 2 nodes was less than 3) and that most important connections exist between mining pool nodes. If individual nodes wish to partition themselves from the network it would not affect anyone else but themselves.

Economically Significant Nodes decide

This is the idea that nodes of exchange businesses, wallets or otherwise ‘economically significant’ players in the community have a vote in the decision. This believe isn’t too far-fetched. In reality, exchanges have some influence as the decision of whether or not to trade a split coin is in the hands of each individual exchange, and the decision to support a given upgrade fork of a blockchain is made by every wallet service provider.

The belief though that their opinions influence a hash vote, however, is less grounded in reality. In truth, although they are well within their rights to provide whatever service they wish to the public, using this support (or threat of withdrawing said support) as leverage during a hash vote is nothing but posturing. Exchanges and wallet service providers are businesses. (With exchanges having to further operate under strict regulatory regimes). If the market demands a service, someone will provide it. But as they are not miners themselves, they will have no way to provide the security support needed for a minority fork chain. Without this it would be very risky for them to provide services to their customers, but it is entirely up to them.

Developers decide

This is the biggest misconception in the industry. It is the myth that the developers that maintain the blockchain client code are the ones that control or influence the decisions to be made on the network. This is the model that most of the legacy bitcoin (BTC) developers operate under, (even though they will deny it themselves). Developers see themselves as the defacto ‘stewards’ of the system, and thus, their opinions should matter the most in guiding what the market and community should expect in terms of features or changes to the network. They use security and network integrity concerns as a basis for this claim, in which they convince the community to ‘leave it to them’ as they know what’s best for everyone. It is very much the nanny-state mentality, or a technocracy. The idea is that this does not devolve into an abusive dictatorship so long as no contentious changes can ever be approved by all developers. Unfortunately, it also ensures that needed changes or upgrades can never make it in either, as there will always be at least one developer to veto (perhaps maliciously) any change request.

Notable personalities decide

This is a slight variation on the case above, where the notable ‘luminaries’ or visionaries, are seen to hold more influence over the system direction than others. This is the model seen in Ethereum presently where Vitalik Buterin (one of the original founders of the project) is seen to have undue influence over what changes are allowed into the project. The power of such leaders was demonstrated when the DAO roll back hard fork was initiated and which produced Ethereum Classic (ETC). The dangers of this system of course is that it can easily devolve into a dictatorship, albeit a benevolent one.

Mining Pools decide

Most people make the mistake of thinking that the mining pools count in the hashpower vote, and this is an understandable mistake. That is because when people ‘see’ the miners of a blockchain, what they are actually seeing are the mining pools. The mining pools are actually just service providers. They run networks and server nodes and they maintain the ‘miner network’ that most people think of when they imagine the backbone of the blockchain. Indeed, it is between these pools that the small world network that has been much talked about actually exist. When blocks are found, they are found by the mining pools, and they are communicated the quickest among the pools. However, these companies, are not the ones that have a vote when it comes to a hashpower vote. If the power to vote belongs to ‘citizens’ of a country, then the mining pools are the companies in a country. They only provide the infrastructure of the network so that the true citizens of the Bitcoin ecosystem can participate in the network. It is true that without them, there would be no way for the network to operate, but if they were to act in a way that defraud the network’s constituents, or if they are not faithful to the wishes of the hashpower constituents, then hashpower will leave them and they would be out of business.

Hashpower decide

Hashpower is the true decider in a hashpower vote. That is to say, those that own the hashpower production assets are the only ones that have a vote in a hashpower election. They decide which mining pool to build blocks for, therefore they effectively decide which chain in a fork to build upon. They have the most skin in the game (collectively) because they are the ones that have committed 100% risk capital to the success of the blockchain and the appreciation of the coin. Data centres can be re-purposed, servers can be re-sold, coins can be dumped for others, but the only thing that becomes worthless scrap if the blockchain fails is the ASIC mining assets. They cannot be repurposed, and therefore they must be written off as losses. As it is, the industry writes down mining assets to zero after just 2 years of depreciation. If they don’t make back their value in 2 years or less, then the business may as well have thrown their money into a bonfire. That is the fundamental reason why hashpower are the only ones that you can be assured of to care the most about the long-term value proposition of the blockchain that they are mining, and the reason why they are the ones that can be trusted to make the best decisions for it. Their vote is weighted in proportion to the amount of hashpower that they own. The larger the portion, the bigger vote they have and the more influential they are. (and subsequently, the more invested they are in ensuring the maximal value be realized on the blockchain).

At present, the only (known) mining pools that own their own hashpower at present are:

Coingeek

BMG

BTC.top

The other mining pools that are listed at sites such as coin.dance are actually mostly hosting businesses and the hashpower that they host are actually their clients. Whenever you have clients, you are answerable to them.

I hope this illustrates why the fork on Nov 15th will be very interesting to watch. We already have plenty of ‘noise’ posturing by companies announcing their support for one fork or the other. At the end of the day, unless the company owns hashpower they actually don’t matter at all and they are only declaring their disregard for their clients if they promote one chain vs the other for ideological or political reasons. The only constituents that have the right to be political are hashpower owners. They paid for the right to vote. They paid for their opinions to be counted. (in proportion to their investment).

So on ‘election day’ on Nov 15th, we will see the actual constituents of Bitcoinland speak, and speak with their investments. Make no mistake, if you don’t own hashpower, you don’t get a vote in this election. Some folks may tell you that you do. Some folks may say that the market decides, by way of resulting price of the coins (subject to manipulation) and they will offer you the option of participating by way of buying one fork coin while shorting the other. Do not be fooled, these are only derivatives, and carry with them all the risks that derivatives do. If an exchange offers you claims on the forked chain coins BEFORE the hash vote has determined the majority winning chain, then they are offering you a HIGHLY leveraged bet, as ANY balances in a minority chain may be unpayble if the majority chain eliminates the minority chain (when most hashpower stops mining the minority chain). All minority chain balances disappear as fast as they were created.

The right thing for exchanges to do is to withhold trading in BCH until the majority chain is determined, and then switch to that chain. As an exchange that values the integrity of their customers deposits, they should not be favoring one chain over another, and certainly not encouraging rampant speculation on assets that may not even exist by supporting one chain as a matter of principle. The only right chain, is the longest PoW chain.

In summary, unless you own hashing power, you don’t have a vote. You may think you do, you may want it to seem like you do in order to influence others, but at the end of the day, the only party that answers to nobody is those that own hashpower. Everything that everyone may say or do or proselytize about, is nothing but political posturing, amounting to nothing more than campaign commercials. In the end, only the hashpower is counted, and the hashpower should be highly incentivized to come to consensus on a majority chain, and let the remaining one expire. Than is Nakamoto Consensus.

We don’t need anything else.

Time to start a new Chapter…

… in the Book of Bitcoin.  There comes a time in every story when the characters develop, evolve, die, or are reborn.  Such is one of those times in the grand adventure which we all started off on 8 years ago.  The Bitcoin Cash fork having successfully executed is now free from the oppressive roadmap which was being driven by Blockstream and Core, which would see most of Bitcoin transactions turned into just channel opening/closing tasks for untested 2nd Layer networks better suited for micropayments.

So in that vein, I would like to show everyone that micropayment payment channel applications don’t need to wait for Lightning Networks!  Yours.org is a homegrown, build by Bitcoiners, for Bitcoiners, paywall content platform that started off writing their own version of payment channels because LN wasn’t (still isn’t!) ready, then moved onto Litecoin because Bitcoin transactions got too expensive, but now thanks to the low fees on Bitcoin Cash, has moved onto BCC.  As such, I would like to support them by moving my blog onto Yours.org on a sort of a trial run.  Therefore, this month’s blog will be published there.  Yes, you will have to fund a BCC/BCH wallet in order to read the whole article. Yes, it doesn’t seem to support embedding media such as pictures inline yet.  But I hope that Ryan X. and team will be able to slowly improve their platform to the level of Medium or WordPress sometime, and it isn’t terribly hard to get your hands on $5 worth of BCC and funding the Yours.org wallet is dead simple.  Send BCC and it is instantly credited (no need to wait for confirms).

So without further adieu, I leave you enjoy reading about (and using!) Bitcoin Cash:

Bitcoin is Dead, Long Live Bitcoin! (cash)

If we are going to grow this community, we are going to have to start supporting its own economy, eat our own dogfood, so to speak.

 

 

Fork Wars Episode I – The Phantom Futures

If you haven’t been living under a rock for the last couple of weeks then you know that the whole block size debate is boiling to a close.  Segwit2x arose to be a compromise solution, lead by ex-core developer Jeff Garzik, brokered and agreement in New York after the Consensus 2017 conference which had over 90% of the miners and ecosystem in agreement.  Since then BIP91 has locked in, which is an effective lowering of the much exalted soft fork consensus threshold of 95%, by which half of the inner circle of core devs felt was deficient. Regardless of how this was on the surface seen to be a ‘lowering of the standards’ it was done anyway and conveniently so, as segwit was not looking like it would ever pass the 95% bar anyhow (ahem. “I TOLD YOU SO” to all the neckbeards out there, and u/jonny1000!).  Now that segwit2x/segwit is going to be ‘forced’ by way of 90% of the miners starting to reject non-segwit signaling blocks, this ensures that segwit’s threshold of 95% of last 1000 blocks will be met sometime in mid-August.  (yes, you read correct, BIP91 was an 80% majority agreement to come to a 95% agreement by forcing the 20% to agree with you or be orphaned — by force!).

This has set the stage for the drama to follow.  For one there is already a growing group of big blockers who have mobilized to fork off the current Segwit2x/Segwit Bitcoin (let’s call this SegwitCoin) who have identified themselves as BitcoinCash.  They are a fork of BitcoinCore 0.14.x with Segwit and RBF components disabled, and a 8mb Hard Fork coded to engage at Aug 1, 12:20 UTC time.  This guarantees that there will be a ‘big block’ Bitcoin regardless of what happens with the SegwitCoin and the expected in-fighting among the new ‘stewards’ of the main chain (Jeff Garzik and his btc1 team) vs. the old guard which have been deposed (Bitcoin Core, Blockstream). Continue reading

Keep the Change! — Replay protection is a Red Herring

Much about the current Bitcoin splitting debate has revolved around the notion of a hard fork splitting of the network being dangerous. So dangerous, in fact, that core developers have constantly stuck to the argument that the community should trust in their (exclusive) council in order to ensure that we don’t engage in anything that may be unsafe for ourselves. Trust them, they know what is good for us. When libertarians and skeptics around the world hear that they are immediately put on alert.

Most recently an exchange between ex-Bitcoin lead maintainer Gavin Andresen with Core contributor Matt Corallo was especially interesting.  Besides the run-of-the-mill talking past each other where Matt seems to ignore points that Gavin clearly addressed (regarding n**2 sighash issues, solved by capping txn sizes to 1mb) the core theme (pun intended) repeated again by Matt was that Hard Forks have no community support (by his own judgement) which is clearly shown by the fact that nobody seems to be giving much attention to the HF proposals in his (exclusive core dev curated) proposal list.  Not much surprise here, the standard echo-chamber reality distortion field stuff.  What was interesting, was that he once again mentioned the need, nay, the necessity of ‘replay protection’ in ANY hard fork proposal.  This is very important point in the core dev platform, as it serves a dual purpose.  One which on the surface is ostensibly for the public good, the other may be much more shadowy.  Let’s examine what replay protection is, and why we really don’t need it.

Continue reading

Core Segwit – Thinking of upgrading? You need to read this!

So, voting on core’s implementation of Segwit is now enabled, and all 3 of the miners that support core have already cast their vote (2 pools and 1 cloud mining MLM), totalling about 23% of the network.  Adoption seems to have stalled (as of 4Dec16) as the rest of the undecided vote remain undecided.  Perfect time for an analysis breakdown of segwit, the good, the bad, and the ugly.

Segwit, the [un?]controversial softfork

Segwit, the [un?]controversial softfork

Segwit has been called a ‘much needed upgrade’ to the network by core proponents, which has a somewhat jury-rigged way of expanding the effective block size of a block. (to 1.7mb)

Let’s first cut through all the marketing jazz and spin that people supporting Blockstream want to put on it and evaluate it on its technical merits alone, addressing its first its pros, then its cons.

Continue reading

Hard Fork Risk Analysis: If the worse happens, how bad can it be?

This post is a culmination of about a year’s worth of thoughts and research that I have been informally gathering, which started with a simple question that started last year when I first read a piece which was written in the middle of the Bitcoin XT heyday describing what would be so bad about having 2 persistent forks by core developer, Meni Rosenfeld.

Forks are not scary, they are upgrades!

Forks are not scary, they are upgrades!

The post described the general understanding of forks at the time, and it was in this context that I wrote my original piece which was very much a pro-Core stance on the dangers of hard forks.  I was wrong on some of my assumptions when I wrote that, which I have over the course of the year corrected, but nevertheless that original piece earned me many twitter RTs and ‘follows’ by core devs and supporters at the time (who have mostly now, funny enough, all banned me).

Continue reading