The Bangkok Summit: The failed last attempt to prevent the BCH Split

So the BCH fork is over.  And one party sort of cheated by bringing in their mercenaries to fight the war, and to usurp their BCH chain for themselves, which was not miners who have been mining the chain for the since BCH’s birth.

But leaving all that politics behind, I would like to leave the official record of the Bangkok meeting which took place in Aug 30th 2018, in which the ABC and the nChain group and chinese miners tried to keep BCH together as one blockchain.  I leave the whole record here for you to do your own research, as nobody has since had the time to create a transcript of the record, but I will give you some very important timestamps so you don’t have to listen to the whole 3 hours…

The infamous Bangkok Summit.  The last time the BCH community was in one room… and also the inside story of the fork split that crashed the whole crypto market.

Bangkok BCH Miners and Developer Summit Aug 30th, 2018

To save you from having to listen to the whole 3 hours (it has yet to be properly transcripted), I will give you the timestamps of some of the highlights.  But I encourage those who are true truth seekers to listen to the whole thing.  Don’t take my word for it.

I’ll skip the initial 3 or so presentations, which was just the hosts welcome, BU’s chat, ABC’s presentation, and nChain’s plea for quicker scaling.  Jumping straight into the panel discussion with Amaury (head ABC dev and self declared ruler of BCH), Shammah, (2nd in command ABC dev), Steve Shadders (nChain head dev), and John Fletcher (nChain head researcher).  This was the infamous panel where CSW, “called bullshit and left the room”.

Panel Discussion with the nChain and ABC devs (timestamps by VLC player)

Apologies, I was made aware that the timestamps may differ a bit depending on your player. I used VLC.

1:12:04 is when ABC Jason Cox and Shammah starts giving reasons why the block size cannot be lifted at this time.

1:13:35 is when Amaury starts talking about how the block size cannot be increased because there is an attack where an attacker can send an SPV node an endless stream of txns and they cannot know they are invalid txns until they stop and they can actually verify it with the MERKLE root.  This is the flat lie, (or it shows how Amaury is already assuming that Bitcoin uses his proposed MERKLIX tree idea (currently in the roadmap for BCHABC) because using that data structure it is INDEED true that you could attack a SPV node this way.  But why CSW left in disgust (unknown to many at the time because people didn’t recognize Amaury’s lie) was that MERKLE trees have a certain depth, and all txns are at that same depth. That means once you get ONE txn, you can hash it up to the merkle root and you know the depth of the tree, and thus the total max number of txns that you should be expected to receive in the block.  To understand this, all you need to know is simple geometry. A merkle tree is a tree structure in the shape of an equilateral triangle. (with the exception of the last row, which may be incomplete), that means, once you know the height of the triangle, and span of the base of the triangle, you know the area of the triangle. (it’s a close enough analogy).  Thus, CSW was right, and Amaury was either being deliberately deceitful, or just forgetting how Bitcoin works, and maybe thinking more about how his version of BCH would work after CTOR and merklix trie implementation. (where it no longer has a triangular shape, so the depth of any given txn would not give you any information about what the maximum number of txns in the block would be.

1:40:18 Andreas Suisani (BU dev) talks about how blocks aren’t full yet, so it’s not a priority.

1:41:18 I speak about the need for blocks to be bigger than the actual use patterns observed, because businesses need to see the block space being available BEFORE we even fund any projects that will use the space.

Discussion about what the current problems that need to be voted on:

2:59:30 —  The question of block cap size raising starts to get discussed.  The discussion gets bounced around back and forth on the issue of whether or not the block cap should be increased before the businesses start using it or after it starts to be obvious that it is needed.  Many people chime in on this including Emil from Bitcoin.com, Roger, Jason Cox, Shammah from ABC, and frankly the main question is just avoided and dodged for the next 7 minutes.

3:14:25 I pull the meandering discussion back to the MAIN issues that needs to be resolved here at this summit, namely, the question of whether or not these CTOR and block limits issues are important enough to split the fork over.

3:19:05 Amaury starts whining about how CTOR was agreed but nChain later disagreed and left and then wasted everyone’s time by leaving the dev discussions. (those discussions were done in Chatam house rules and no transcripts were kept.)  His argument that CTOR was agreed by the devs who attended those private dev meetings is his only real defence of why CTOR should be included in the Nov 15th fork NO MATTER WHAT nChain (with Coingeek, the largest mining group) says.  Pretty much the devs are the ones that make the call.  Miners shouldn’t need to care, just need to agree with them.

BIP135 was mentioned by Dagur and Andreas as a way to resolve the dispute by the miners, but none of the chinese miners seem to be supportive of it.

The rest of the discussion (if you really want to bear through listening to it all) is ABC devs consistently focusing on the need to improve communications with miners (basically how to educate miners about the things that the devs have already decided in their private dev meetings of which they kicked nChain out of)

3:24:45 I summarize the whole day and the ideological question that is posed to all the BCH community.  I called out the ideological differences in the scaling strategies.  The answer to my question was when I realized that BCH was dead.

This was the last time the BCH devs, miners and community was all in one room. It was apparent that after this meeting, the existing BCH community was already fractured.  There were the anarchists that want to push the agenda of a grey market platform, to compete with DASH or Ethereum using Wormhole and ICOs, or whether or not we should just focus on scaling via the original Bitcoin model and let all the businesses build the ecosystem.

This is why we now have BSV and BCHABC aka BAB.

There was no way that the people at this summit was going to agree on these fundamental differences.

There was just too much individual agendas at play, and too much difference of opinion on what was important for the ecosystem, and what the developers roles to play vis-a-vis miners were.

I went to this meeting to try to find some common ground to prevent a BCH chain split.  What I found out was that one side (ABC) was already determined to split no matter what.

Now you all can decide with your money.  Each chain is separate, and only one is maintaining the original goal and roadmap of Bitcoin.

/EOL

 

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