If the IFP in Bitcoin Cash activates, it suggests that cryptocurrencies are doomed to centralization
There are many arguments against cryptocurrencies, and this is one of them:
How can it be decentralized when the developer with the GitHub repo can give themselves any number of coins, arbitrarily and without recourse?
The answer has always been “don’t worry, miners will reject it” and “they will just fork off from the rest of the network”.
In about a week, this theory will be tested for real in Bitcoin Cash because this is *exactly* what ABC is trying to do by diverting 8% of the blockreward to themselves. (The only difference is they use Phabricator instead of GitHub).
What harm can a coder do?
Some might say hey, the important thing is *miner decentralization*, so that transactions cannot be double-spent. Whatever code a developer introduce hardly matters, right?
But it turns out that developers can do an incredible amount of damage. If left unchecked they can for example:
Block necessary upgrades (like Bitcoin’s blocksize increase).
Censor transactions (see the aftermath of the DAO hack).
Push through poor code that can be abused to harm the network (the DAA).
Arbitrarily change the emission schedule (what ABC tried to do with Grasberg).
Assign themselves an arbitrary amount of coins (the IFP).
Or in other words, with the code they write (or don’t write) they can completely destroy everything that makes a cryptocurrency valuable, and this is why safeguards against the developers’ power are so important.
Historically, the reference client’s code is law
While I’d like to think that the community would reject Bad Code™ so far the opposite seems to be true.
Early on in Ethereum’s history people subscribed to the idea that “code is law”, and that the rules you inscribed into a smart contract made outdated things like human decision unnecessary. But this was thrown out the window after the DAO hack, when a bug in a smart contract was exploited and the Ethereum developers moved to quickly freeze the funds, effectively censoring transactions on the chain.
Preventing the DAO theft isn’t morally wrong, but why weren’t similar hacks counteracted in a similar manner? Maybe because they were too small or didn’t affect the Ethereum developers enough for them to care?
Freezing of funds is an arbitrary human decision that cryptocurrencies were created to remove. Otherwise we’ll just end up with the same problems that plague PayPal and VISA, where money of innocent people are frozen all the time. Yet in Ethereum, the community followed the reference client.
Another example is how Bitcoin Core managed to block the blocksize increase in Bitcoin, even though an increase to 2 MB had broad support by miners and the community. The reason they managed to do this was that the miners ultimately decided to be passive, and to wait for Core to implement the 2 MB increase, which of course never happened.
The third example is how in Bitcoin Cash every change has been dictated by ABC (so far at least). By threatening a fork they managed to push through their preferred changes like the DAA and CTOR, while blocking others like on-chain tokens.
This pattern where the reference client *always* dictate the rules is repeated all over in the cryptocurrency space, raising serious decentralization concerns.
(The single counterexample I could find is how Monero replaced the original developer team with a new one, which happened early in Monero’s history when it was still very small.) https://monero.stackexchange.com/questions/1011/monero-inception-how-did-bitmonero-become-monero
What if the IFP succeeds?
It seems unlikely that the IFP would activate in BCH, because all the metrics we can come up with shows a clear preference for the no-IFP / BCHN side:
More than 70% of blocks are signaling for BCHN. https://ec.loping.net/ichundes/bchnblocks.png
58.68% of all nodes are signaling for the no-IFP side. https://cash.coin.dance/nodes
86.21% of all upgraded nodes are signaling for the no-IFP side. https://cash.coin.dance/nodes
Coinex futures values BCHA/BCH at 0.0599, valuing ABC at around $15. https://www.coinex.com/exchange?currency=BCH&dest=BCHA
98.75% of coins support BCHN against ABC, and only 0.02% support ABC against BCHN. https://votes.cash/
Coinbase will run BCHN and will not give out ABC coins. https://mobile.twitter.com/CoinbaseSupport/status/1324156279489622017
Users on social media have overwhelmingly declared against IFP. https://www.reddit.com/r/btc/comments/f4qgry/lets_have_a_show_of_hands_who_supports_the_ifp/
And if the IFP still succeeds it means that all this is meaningless and that the code of the reference client trumps all. It shows that cryptocurrencies cannot break out of developer centralization, and we might just as well replace proof-of-work with proof-of-GitHub or proof-of-Phabricator.
What if the IFP fails?
But if the IFP fails this would be the first time in cryptocurrency history that a reference client of a major cryptocurrency has been kicked out in a “hash war”.
This is huge because it proves that Bitcoin Cash is resistant to rogue developers and can kick them out if they try to change the coin supply, redirect the blockreward to themselves or something else that could cause serious harm.
It shows that cryptocurrencies aren’t necessarily centralized around a developer team, and that the hope of truly decentralized peer-to-peer electronic cash is still alive.
Historical context for the Bitcoin Cash fork in November 2020
In November 15th Bitcoin Cash will have another hardfork upgrade, and there will very likely be a split between ABC and no-IFP (often referred to as the BCHN chain).
This conflict didn’t come out of nowhere but has been brewing for a long time, some might say even from the beginning when Bitcoin Cash was created. I’m sadly not too surprised that we’ll have another split as it always felt like a question of when, not if.
With this article I hope to give you some historical context and to explain why I’ve felt that another Bitcoin Cash fork was inevitable, and why we’re forking right now.
And I apologize for the long article. If I had more time I would’ve written a shorter one. You can jump to What can we learn from this history lesson? for the point I’m trying to make.
Bitcoin Cash forks from Bitcoin
A blocksize increase was desperately needed in Bitcoin for a long time before Bitcoin Cash. Many people tried to convince developers, miners and other stakeholders but they were ultimately thwarted by Blockstream and the small blocker zealots.
In hindsight maybe people were too nice and wanted everyone to get along, therefore the big block crowd tried to compromise again and again and again. From a dynamic blocksize to an ever decreasing limit of 16 MB, 8 MB, 4 MB and finally 2 MB, but nothing was ever small enough to be acceptable.
People had been trying to create a big block fork for a while, but in the end it was the fork announcement by ftrader (currently the BCHN lead developer) and deadlnix (Amaury Sechet, the lead developer of ABC) that in 2017 gathered enough momentum to later become Bitcoin Cash. They were not the only full-node client as at the time of the fork as there were several others such as Bitcoin Unlimited, Bitcoin Classic, Bitcoin XT and Bitprim. https://www.reddit.com/r/btc/comments/bvj08f/an_incomplete_history_of_the_bitcoin_cashs_origin/
The “don’t care about others, just do it” mentality was exactly what was needed at this time, but that would come back to haunt us later on.
You either die a hero, or you live long enough to see yourself become the villain.
The first difficulty adjustment upgrade
Very quickly we start saw a problem with the Emergency Difficulty Adjustment (EDA). The purpose of it was to significantly decrease the proof-of-work if no block had been found for a while in order to prevent the chain from fizzling out after forking from Bitcoin, but it did so much too aggressively and it caused periods of extreme block shortage and with extremely many blocks.
For a good article of the EDA and it’s problems, I recommend this article by Mengerian: https://medium.com/@Mengerian/bringing-stability-to-bitcoin-cash-difficulty-adjustments-eae8def0efa4
The BCH developers recognized this as a problem and were working together on a replacement, but in the middle of that process ABC suddenly announced that they had chosen the next Difficulty Adjustment Algorithm (DAA), and it would not be the one that the other developers favored. Their reasoning: https://www.bitcoinabc.org/2017-11-01-DAA/
We have the utmost respect for the all developers involved in the discussions, but only one algorithm could be chosen, and a timely decision was required.
Therefore, we decided to take a scientific approach and utilized two impartial and unconnected testing teams: Bitprim and nChain. These teams conducted their tests separately and came to the same conclusion of which algorithm was most appropriate.
In other words, they rushed the decision and let two other teams (Bitprim and nChain) decide the algorithm.
Unfortunately this was not a “scientific approach” as they never released their research methodology or research data, making it impossible for anyone to falsify their tests (a core property of the Scientific Method). The algorithm that was chosen was ABC’s own and it had known problems that caused the unreliable blocktimes we’ve now had to live with for almost three years. This is (finally) something that will be fixed in the November upgrade. https://en.wikipedia.org/wiki/Scientific_method
Permissioned tokens
OP_GROUP was a proposal from Bitcoin Unlimited that aimed to bring on-chain tokens to Bitcoin Cash, quite similar to Ethereum’s tokens. I thought it was pretty neat, but unfortunately it was shut down by ABC.
I’m not really upset about it not getting approved (well maybe a little), but what made me really upset was the arguments ABC used against it.
In short they argued that *tokens don’t have to be permissionless*, and we should therefore use Wormhole as our token solution, which only supports permissioned token transfers. (This was before SLP was invented, which has permissionless transfers.)
Maybe I was foolish to think that permissionless is a big part of why we’re here, and a requirement for tokens to be at all interesting, but what do I know?
Amaury also gave this reason: https://www.reddit.com/r/btc/comments/7yxicn/op_group_is_too_early_not_tested_outside_the/dujzbai/
OP_GROUP was made with zero feedback and contradictory claims made about it’s planned inclusion such as it has absolutely zero review at this point. When concern are raised, proponent decide to start drama on social media rather than address the concerns. This is a recipe for maximum drama and minimum results.
So he says he feels OP_GROUP was rushed. I disagree, follow the link to see a rebuttal, but let’s say that’s true. Why then has it been 2.5 years, and we’ve made no progress? https://www.reddit.com/r/btc/comments/7yxicn/op_group_is_too_early_not_tested_outside_the/dujzbai/
The answer to why we don’t have miner validated tokens on Bitcoin Cash is that ABC didn’t want them, and they’ve always given different answers as to why that is. BU recognized that it’s more important to keep the community together than to fight for this change, so they gave in and let ABC have the final word.
Amaury’s “BCash” moment
The 7th of August 2018 Amaury made a post on r/bitcoin, a subreddit with extreme hate against Bitcoin Cash, with the title: https://www.reddit.com/r/Bitcoin/comments/95bi14/hillarious_creator_of_bcash_has_been_banned_from/
Hillarious: Creator of BCash, has been banned from the BCash Slack. And then they say r/bitcoin is censored
If you’re familiar with Bitcoin Cash then you’ll know that the slur “BCash” is used by trolls to shit on Bitcoin Cash. And here Amaury, the de-facto lead developer of Bitcoin Cash, uses the same derogatory slur to belittle the project in r/bitcoin, one of the most censored and narrative-controlled subreddits there is. https://medium.com/@jonaldfyookball/why-some-people-call-bitcoin-cash-bcash-this-will-be-shocking-to-new-readers-956558da12fb
Who’s the one who starts drama on social media again?
The BSV fork
Another huge conflict in the history of Bitcoin Cash was with Craig “Faketoshi” Wright and his nChain company. I won’t rehash the events as it’s not what this article is about, but suffice to say nChain came up with different things to complain about and it ended up with a “hash war” that they lost and they split out into their own coin, BSV.
It’s good that we got rid of Faketoshi but the BSV conflict drowned out technical concerns about another feature that ABC forcefully pushed through, called CTOR.
Here ABC did what they complained that BU tried to do with OP_GROUP: they rushed through a change that wasn’t needed (and still isn’t really used to any significant degree) against the judgement of the other developers. And again ABC got their way, this time because Faketoshi was the bigger enemy and CTOR wasn’t a big enough change to split the community further.
Note that I’m not saying CTOR is necessarily bad, and it will help us scale with things like Xthinner, but there are other ways to sort transactions other than CTOR that would work just as well (or possibly better). For more info I refer to Toomim’s article: https://medium.com/@j_73307/benefits-of-ltor-in-block-entropy-encoding-or-8d5b77cc2ab0
Voting to set the blocksize cap hard limit to 10 TB
In another “maximum drama stunt” both Amaury and Micropresident joins with the BSV trolls and vote that Bitcoin Unlimited should raise the hard blocksize limit to 10 TB. This would have disastrous consequences as we cannot handle close to that size and would at best crash BU nodes and at worst cause a chainsplit. https://www.bitcoinunlimited.info/voting/render/proposal_vote_result/7eb0ded0487a6593ac3976b63422294e1a84b209be1307c46f373489922212a0
As to why they voted for it Micropresident had this to say: https://bitco.in/forum/threads/buip101-closed-set-the-default-value-of-max-blocksize-cap-hard-limit-to-10-terabyte.22424/page-2#post-81570
FWIW, I intend to vote yes on this proposal. It will be nice to give everyone a chance to see what the limit is for, in the wild, so I can quit hearing about it.
Meaning he knows it would be disastrous, but did it anyway. Maybe in an attempt to sabotage Bitcoin Unlimited, which they’ve had a conflict with since the beginning of Bitcoin Cash.
The unconfirmed transaction limit
Another important issue for Bitcoin Cash is the unconfirmed transaction limit. It means that you’re only allowed to chain 25 unconfirmed transactions in a row before a node will reject them.
This was so important for Satoshi Dice that they announced a 1,000 BCH bounty if we could get it fixed in 2019! https://www.reddit.com/r/btc/comments/clr0sj/a_request_from_satoshi_dice_to_the_bitcoin_cash/
Some developers tried to work on it, but it didn’t go anywhere because Amaury didn’t want to prioritize it: https://www.reddit.com/r/btc/comments/clr0sj/a_request_from_satoshi_dice_to_the_bitcoin_cash/evxc1ip/
Shammah says that /u/deadalnix told Shammah that there were other things that he wanted done first.
The limit is there because of poor full-node performance, which ABC backported from Bitcoin Core. ABC has stated their intent to raise the limit to 50, but the fundamental problem is unresolved.
In the meantime other implementations like Bitcoin Unlimited have made large improvements in this area, but without ABC’s support in practice this is still a problem users will face.
The 2 MB soft limit
Bitcoin Cash was created to be the big block alternative to Bitcoin, and today we have a 32 MB limit that would in theory allow BCH to process around 20 times more transactions than BTC.
But in September 2019 when an on-chain stress test was made we discovered that many miners only created 2 MB blocks even though they could create much larger blocks. This was because ABC had a default soft-limit of 2 MB and if miners didn’t change it they would only create 2 MB blocks.
That’s quite a poor display but what’s worse is that Amaury argued that *it was dangerous to raise it*: https://www.reddit.com/r/btc/comments/cye9j9/it_is_utterly_shameful_that_pools_and_miners_who/eys84w6/
Sure or we can mine large block, so we move the problem from the mempool to indexing node that fill trip over themselves bsv style as they are not optimized to handle 100x the usual demand.
In essence he’s parroting the small-blocker talking point that Bitcoin Cash can’t handle larger blocks. This is completely false and the same stress test showed that we could handle 20 MB without issue, and after some small fixes were made we can do even larger.
But there is a performance problem worth noting; ABC is the least optimized full-node client and it handles large blocks much worse than BU or Flowee for example. By only focusing on backporting changes from Bitcoin Core (which has horrible performance) this self-made problem has been deemed “too difficult and too expensive to solve”.
Avalanche: The solution to everything
ABC’s pet project is Avalanche. It will supposedly make transactions settle in mere seconds, help us scale and even protect us against the dreaded 51% attack.
Sounds too good to be true? Then it probably is.
There has been no response to the serious concerns people have raised against Avalanche, including how it overrides proof-of-work and changes the consensus algorithm of Bitcoin Cash. (They have responded by dismissing the concerns without actually addressing them.) https://read.cash/@noise/dont-roll-your-own-consensus-algorithm-and-the-dangers-with-pre-consensus-for-bitcoin-cash-73095b77
Despite us needing a ton of research into how we could safely integrate Avalanche with proof-of-work ABC still pushes ahead with Avalanche as if it’s already been decided on. Even if Avalanche can be made to work the best estimates puts it *years* away from integration, yet it’s still used to dismiss other improvements such as double-speend proofs, which is a simple way to radically increase the safety of 0-conf.
Ever heard of the vaporware called Lightning Network, and how Bitcoin developers declared that it would solve all their issues? How it was used to prevent a blocksize increase? And how that was years ago yet it’s still nowhere near ready? Avalanche for Bitcoin Cash follows the exact same pattern.
The IFP
Jiang Zhuoer of BTC.TOP was the one to present the first version of the Infrastructure Funding Plan (IFP) for Bitcoin Cash. The plan was to force all miners to send 12.5% of the coinbase to a Hong Kong corporation that would be in charge of dispersing them to full node implementations and other critical infrastructure. https://medium.com/@jiangzhuoer/infrastructure-funding-plan-for-bitcoin-cash-131fdcd2412e
This proposal wasn’t received too well by the community so Zhuoer quickly issued an updated proposal where miners would send funds directly to the projects they wanted to support, bypassing the Hong Kong corporation. It would be activated by miner vote and there would be a pilot period. To “avoid the tragedy of the commons” it was also necessary to let miners burn their funds if they wanted to. https://read.cash/@Jiang_Zhuoer_BTC.TOP_CEO/bch-miner-donation-plan-update-0cf20809
ABC, having complained often and loudly about the lack of funding, jumped on the opportunity and announced their own version of the IFP. It differed from the other proposals, the most significant change was that funds could only go to one of four projects: Bitcoin ABC, Electron Cash, BCHD and a “General Fund” (which wasn’t explained further) and it did not allow miners to burn their funds. https://www.bitcoinabc.org/2020-02-15-miner-fund/
I wasn’t a fan of the IFP and the unhealthy incentives that would lead to centralization, while failing to solve the tragedy of the commons and it also wouldn’t prevent the Blockstream takeover. Or how the proposal would only send money to Amaury and his friends, using arbitrary rules to disqualify competing projects such as Flowee or BU. https://read.cash/@noise/the-ifp-and-unhealthy-incentives-59dc5d1c https://read.cash/@noise/busting-the-myth-that-the-ifp-wouldve-prevented-the-blockstream-takeover-af955731
Neither was the community and the IFP caused a bunch of developers who had grown so tired of ABC that they launched another full-node implementation called BCHN, which would be a drop-in replacement to ABC. If the IFP was activated BCHN would also follow it, but it presented a very easy way for miners to switch away from ABC and it quickly become the biggest alternative to ABC. https://read.cash/@freetrader/bitcoin-cash-node-003b2381
The IFP was ultimately rejected by the community and all miners (only a few blocks voted for it by accident) and even Zhuoer himself vowed to vote against it. https://coinspice.io/news/author-of-the-bitcoin-cash-ifp-vows-to-vote-against-it-using-personal-hash-in-opposition/
Flipstarter
The IFP debate did raise an important issue: how would Bitcoin Cash infrastructure be funded? If not by the IFP, what then?
Enter Flipstarter. It was a non-custodial Kickstarter where projects would only get the money if it was successful. During the IFP debate the full-node campaigns of BCHD, Bitcoin Verde, BCHN and Knuth were successfully funded, showing that projects can be supported without the IFP. https://flipstarter.cash/
Notably ABC ran a Flipstarter of their own, but it failed to complete. Maybe because people didn’t think they’ve done a good job so far or because the hate against the IFP was so strong.
Grasberg
After three years of large blocktime variance, with them becoming worse as more miners started to abuse the DAA, some developers had decided that enough was enough. Their efforts culminated with Jonathan Toomim’s proposal to use ASERT as the new DAA. https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696
It was an excellent proposal and incredibly well researched. Bitcoin Cash developers all over praised the effort and were happy that we might finally be able solve the problem with blocktime variance. It was even looking like Jonathan would be able to convince ABC of the importance to fix this issue, even if he had to “talk privately” with them about it.
But out of the blue ABC announced that they were “moving forward with the Grasberg DAA”. And it was different from ASERT. The reason given was that “no concrete proposal has reached ABC at the time of this writing”, despite them being obviously aware of the work Jonathan and others had been doing. (They even copied parameters from Jonathan’s proposal.) This is the Not Invented Here Syndrome in action. https://blog.bitcoinabc.org/2020/07/23/announcing-the-grasberg-daa/ https://read.cash/@noise/the-not-invented-here-syndrome-in-bitcoin-cash-development-f22113b0
Remember how ABC shut down OP_GROUP because they said it was made with zero feedback and that it was too rushed? Notice the parallels to how ABC announced Grasberg.
Except for how the development was handled, there were other serious problems with Grasberg:
It performs worse than ASERT. https://read.cash/@jtoomim/dark-secrets-of-the-grasberg-daa-a9239fb6
It changed the blocktime to target 11.25 minute for the next 6.5 years, even after Amaury himself wrote a long article that explained why we shouldn’t change the blocktime. https://read.cash/@deadalnix/on-the-bitcoin-cash-block-time-88a6aa5e#why-is-it-harder-to-change-the-block-time-on-an-already-deployed-system
It changed the coin emission schedule which would weaken the sound money properties of Bitcoin Cash. https://read.cash/@noise/grasberg-will-weaken-the-sound-money-properties-of-bitcoin-cash-af976406
ABC forced many people to waste a lot of time to argue against Grasberg. If you want to see their arguments in video form I can recommend the Bitcoin Cash DAA Development meetings: #1, #2, #3. (If you want drama then watch how Amaury rage quits in the middle of the third meeting.) https://www.youtube.com/watch?v=nwhIEI-Ytis https://www.youtube.com/watch?v=F5b0Unf1aA0 https://www.youtube.com/watch?v=0LNw0iyfONY
If the arguments are too technical for you then just look at how Jonathan produced incredibly detailed research of ASERT, Grasberg and numerous other algorithms, but ABC produced *nothing*. The only argument was that they “had already run simulations” and that we should take their word for it (or not, because they had already decided to deploy Grasberg regardless of input). https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 https://read.cash/@jtoomim/dark-secrets-of-the-grasberg-daa-a9239fb6 https://blog.bitcoinabc.org/2020/07/23/announcing-the-grasberg-daa/
This might be good enough in kindergarten, but it’s woefully inadequate for a project that aims to provide peer-to-peer digital cash for the world.
Many different people recognized how bad Grasberg was and they issued a statement that said they would go forward with ASERT. This included all other node implementations and major infrastructure like Electron Cash, CashShuffle and SLP. https://read.cash/@GeneralProtocols/joint-statement-on-aserti3-2d-algorithm-f98f0a2c
The IFP bait-and-switch
ABC continued to spend an excruciating amount of effort to defend Grasberg despite all it’s flaws and it was really looking like this was the hill ABC wanted to die on. No matter the argument, they just wouldn’t budge.
And then they silently dropped it, never explaining why or mentioning it again.
Success! Everything is awesome! BCH can stay together and we’ll all live happily ever after! Wooo!
… Unfortunately not. ABC announced that they would implement a 8% coinbase rule that diverts miner rewards to themselves. Because the miners didn’t activate it the last time, this time it will just activate regardless of support. https://blog.bitcoinabc.org/2020/08/18/new-release-bitcoin-abc-0-22-0-is-available-to-download/
If you’ve been following ABC’s behavior then this shouldn’t be terribly surprising. NilacTheGrim even called it exactly: https://read.cash/@NilacTheGrim/calinstradamus-preditcion-12341-ifp-20-coming-in-nov-no-voting-just-mandatory-56dbc7be
ABC will do something incredibly wreckless to almost guarantee a split of BCH come Nov. 15th 2020. And the most likely thing they could possibly do is push a consensus change that pays them directly from coinbase, as they attempted to do last time, but this time it will have no BIP9 voting/activation – it will just automatically activate Nov. 15th.
This will indeed almost guarantee a split in November, and it was pushed through in an incredibly reckless manner without care for the harm done to Bitcoin Cash.
What can we learn from this history lesson?
For me these events teach us two very important things:
Amaury and ABC doesn’t collaborate well, if at all.
They present their solutions, without research to show why it’s good, and threatens a chainsplit if anyone disagrees. They also act as a blocker against other improvements, again threatening a chainsplit to get their way.
They do not have the best interest of Bitcoin Cash in mind.
If they did they wouldn’t threaten a chainsplit all the time and instead they’d recognize that splitting the community is the *worst case scenario*. They would acknowledge that something like the IFP has extreme resistance, and would back away.
This is why a split was inevitable, because it was bound to come a point when ABC would recklessly push for something that would be important enough for the community to risk a split over. The trigger could’ve been Avalanche, it could’ve been Grasberg and it ended up being the IFP, but ABC is the root cause of the split.
Where do we stand?
It’s impossible to say with 100% certainty what will happen in November, but we can try to make an educated guess. Because all metrics we can come up with show the same thing:
57.4% of all blocks the last 7 days are signaling for BCHN and 0% for ABC. https://cash.coin.dance/blocks
41.2% of all nodes are ABC, the rest are for no-IFP. https://cash.coin.dance/nodes
Coinex futures values ABC at $38 and no-IFP at $249. https://www.coinex.com/exchange?currency=BCH&dest=BCHA
98.75% of coins support BCHN against ABC, and only 0.02% support ABC against BCHN. https://votes.cash/
Users on social media have overwhelmingly declared against IFP. https://www.reddit.com/r/btc/comments/f4qgry/lets_have_a_show_of_hands_who_supports_the_ifp/
This also includes all other full node implementations (BCHN, Flowee, Verde, BCHD, Knuth, BU) and all wallets except the wallet built into ABC itself.
Therefore it’s overwhelmingly likely that ABC will receive minority hash and fork away to their own new coin.
If you read the marketing material ABC has produced you might get a sense that it’s not so clear cut. But as Josh Ellithorpe, developer of BCHD, says ABC is being dishonest: https://mobile.twitter.com/zquestz/status/1297948985550704640
Thanks. Appreciate the kind words. To be very clear if the IFP chain is the majority chain I am leaving BCH and taking down all my public infra. The SLP devs are also anti IFP. I am quite upset that ABC is trying to frame us as supporters…
They didn’t even talk to us about this article. Their current marketing and social media presence is super dishonest to make it appear the IFP has support when it doesn’t. Yet another instance of ABC losing my trust. https://blog.bitcoinabc.org/2020/08/24/supporting-bitcoin-cash-infrastructure/
In the referenced article ABC praises BCHD and SLP and that they would receive some of the IFP money, but the reality as that both BCHD and SLP have declared against the IFP. https://blog.bitcoinabc.org/2020/08/24/supporting-bitcoin-cash-infrastructure/
To infinity and beyond
After no longer having to abide by ABC’s approval suddenly loads of improvements that were paused or abandoned have started development again:
Significantly raising or removing the unconfirmed transaction limit.
On-chain tokens are being considered again.
Block propagation tech like XThinner that would allow us to raise the blocksize limit much higher.
Double-spend proofs that will improve 0-conf security.
BCHN will focus on optimizing the poor ABC performance.
Actual research into the feasibility of pre-consensus solutions.
And more.
You might be worried that Bitcoin Cash will have to suffer through yet another split, but I’m instead more bullish for Bitcoin Cash than ever, and after we replace the reference implementation in November we can show the world that the development in Bitcoin Cash is truly decentralized.
The OG Bitcoin business model works fine
I took a break from the insanity that is US politics and their sociopath president and relaxed by reading Tobias Ruck’s article on how Bitcon’s original business model is broken. In a nutshell he argues that: https://read.cash/@TobiasRuck/the-og-bitcoin-business-model-is-broken-979a132e
The OG Bitcoin business model is “Buy Bitcoin, Adopt Bitcoin, Profit”.
After 11 years we still haven’t a viable replacement for USD, and that is proof that the model is broken.
That the existence of other projects with supposedly sound business models is more proof that Bitcoin’s model is broken.
I think the article is well written, but let me try to explain why I think he’s completely wrong.
False claims of USD superiority
Tobias writes that USD is faster, cheaper and more reliable and therefore Bitcoin and it’s forks aren’t a viable replacement for USD.
I do agree that cryptocurrencies cannot replace USD easily, but I do not agree that USD is superior in the ways Tobias claims.
0-conf are just as **fast** as credit cards, PayPal and others.
You see, when a payment arrives after a credit card payment you don’t actually receive the money until later. What you get is a *payment notification*, which is exactly the same as a 0-conf payment. (And of course a credit card payment only becomes irreversible after weeks or months.)
When he writes that credit cards and PayPal are free, he means that it’s *only free for customers*.
What he fails to mention (maybe because it doesn’t support the point he’s trying to make or something?) is that businesses are charged 3 or 4% for every transaction, on top of other minor charges. That’s **4% cheaper** to accept Bitcoin or it’s forks.
This alone invalidates his central thesis that “there simply is no money to be made directly from replacing the USD with Bitcoin”, but that would make for a pretty short article and there are some other points I’d like to make.
He claims that USD is more **reliable** because it’s backed by the government… A few paragraphs after posting a graph of the insane USD inflation.
I don’t think that’s what reliable means.
He also writes “that there’s always someone you can call to get your transaction handled”.
Except that one of the big points of Bitcoin is that not everyone has access to credit cards.
11 years is not a long time
Of course not everything he writes is wrong. In particular I think he hits the nail on the head with this comment about USD:
it’s basically accepted everywhere
Which is the answer why USD is better for payments and it dwarfs any other reason. (Including price stability as if everything was priced in BCH then it wouldn’t matter if it would fluctuate against something else.)
Now where we differ is that he thinks Bitcoin no replacing USD in 11 years is a sign of failure, but I think it’s amazing how far we’ve come in *only 11 years*. Bitcoin went from $0 to +$10,000 and is accepted in tens of thousands of shops around the world in only a decade. That’s a world changing event that could be attributed to the OG Bitcoin business model.
Maybe it’s the modern generation that has an attention span of a goldfish and needs constant stimulus to not lose focus, but 11 years is a really short time to disrupt something as huge as the USD. Just look at how many decades it took for the car to become mainstream. Or the computer, electricity, the internet or the light bulb. And presenting an alternative to the USD, today’s “world currency”, would be something as big as any of these inventions.
It doesn’t matter if Bitcoin was 10x better than USD in all technical aspects, it would still take a long time to convince people to switch.
Adoption has been set back by attacks
And Bitcoin didn’t even have a normal adoption curve as it has been severely set back by large and disruptive events. (Call them attacks if you like.)
The absolutely largest is of course when small blockers successfully changed Bitcoin from a “peer-to-peer digital cash” to a “store of value” coin, causing Steam, Stripe and others to drop Bitcoin as a payment method.
Bitcoin Cash has taken up then mantle but the network effect is very difficult and time-consuming to rebuild. I’m convinced the small blockers set back cryptocurrency adoption many, many years.
Bad examples of sound business models
As proof of Bitcoin’s broken business model he lists some examples:
He uses Liquid as an example, but it wasn’t created until after the small blocker takeover. And besides, it’s a centralized shitcoin so who cares?
The treasury of Dash is referred to as a viable business model, but Dash is itself a failed project in large part of it’s poor governance structure that’s made to enrich the ones in control. (Sort of like ABC’s IFP.)
Ethereum is another project that supposedly has a viable business model, yet Ethereum is very far from the peer-to-peer electronic cash ideal because the benevolent dictator can, and has, censored transactions on the protocol. (Lookup the DAO controversy.)
BSV supposedly took good part of the “data-on-chain” people, yet their chain is completely full of nonsense transactions that only exist to create an illusion of activity.
AVAX has a coin distribution that’s extremely lopsided, putting many shitcoins to shame. This is incredibly serious in a proof-of-stake coin, which throws away any semblance of decentralization.
ABC is brought up as an example, but the fork hasn’t even happened yet and so far it seems only a very small minority will follow it (including Tobias).
I don’t know about you, but if these are supposed to prove how successful cryptocurrencies with a “sound business model” are, then consider me underwhelmed.
Instead let me give a counterexample of a successful project that uses the “OG Bitcoin business model” (other than Bitcoin Cash):
Monero follows the vision of peer-to-peer electronic cash faithfully. Monero has developed best-in-class privacy, outclassing the privacy delivered by ZCash (where 20% of the miner reward instead goes to founders, early investors and certain developers). It’s propelled forward by enthusiasts and the community funds projects via the Community Crowdfunding System, and the supposedly inevitable burnout is nowhere to be seen, as Monero is stronger than ever. https://ccs.getmonero.org/
Who cares about decentralization?
Tobias references Elinor Ostrom and her tips on how to “govern the commons” and how to manage a public good. (I’m not convinced that Bitcoin is a public good either, but let’s play along shall we?)
The only problem with her 8 principles is, as Tobias notes, that they don’t fit Bitcoin because there’s **no central party in control**. This is a core assumption of Ostrom’s work, making it not applicable to us.
Tobias concludes that to fix this we must introduce a central party. A worthy goal some might say, and a trade-off that many projects in the cryptocurrency space has made.
But.
**In the process we invalidate the whole idea of Bitcoin.**
Maybe that’s why a lot of people in the Bitcoin Cash community, including some of it’s most prominent members, oppose the Global Network Council and the IFP so hard?
Because decentralization is so important and so central to the goal of peer-to-peer electronic cash, that we absolutely cannot compromise it. It’s truly unfortunate that some in the community forget this fact as soon as there’s a possibility to get some of those juicy IFP coins.
Busting the myth that the IFP would've prevented the Blockstream takeover
This is a narrative that some people use to justify the IFP:
The lack of IFP on Bitcoin was what allowed Blockstream to derail it
But not only wouldn't the IFP have prevented the Blockstream takeover, it will turn ABC into Blockstream 2.0.
Money’s not enough
The idea people got corrupted by Blockstream because they offered money is compelling, and is probably true to some extent. If the developers already had a good salary, they would be less likely to be swayed by outside influence. Again, it makes sense.
But it wouldn't have been enough to save Bitcoin.
Firstly, to sway a greedy person all you have to do is pay more.
Why are there so many corrupt millionaires and billionaires in the world? Because they will always want *more money*. Even when they've got more money than they could ever hope to spend in several lifetimes, *they still want more*. So all Blockstream would have to do is to pay a greedy developer more, regardless if any IFP money coming their way.
Secondly, people are motivated by other things than money.
If you value money above all else this might be hard to understand, but it's nevertheless true. Some people are driven by their own morals and they they try to do The Right Thing, as they see it. This is for example why many spies betray their own country despite not getting any money for it.
I'm convinced many of the Blockstream developers, and many of the hardcore 1 MB supporters, truly believe they're doing the right thing. That they follow the anarchistic way and that they will absolutely not be convinced otherwise by the bcash scammers.
It *doesn't matter* if they're right or wrong. If you try to convince them otherwise, the more they'll believe they're right. And don't even think for a second you can buy them off, that's a sure fire way to lose them forever.
How did Blockstream derail Bitcoin?
But how did Blockstream manage to derail Bitcoin? Why are we still stuck with the 1 MB blocksize limit and how did they convince the community to wait for years for the Lightning Network and suck up large fees and delays?
It’s admittedly a complex topic, but here are some of the important reasons:
They unleashed an army of shills that poisoned the debate.
They censored important communication channels such as r/bitcoin and the bitcoin-dev mailing list.
They chased away big block supporters like Mike Hearn and Gavin Andresen.
They controlled the source of Bitcoin Core, the de-facto reference client.
But **above all** they managed to convince miners to cede to the perceived authority and that they should just do what the ~~Core developers~~ Blockstream wanted. In short the managed to convince the important stakeholders that **the reference client dictates the protocol**.
To channel my inner Frank Herbert:
He who controls the reference client controls the Bitcoin.
The IFP will make ABC the new Blockstream
In the ultimate irony the IFP will not prevent a future Blockstream, it will instead turn ABC into the very thing they say the IFP would protect against.
Because activating the IFP will cement the fact that ABC can do whatever the hell they want on the chain. They can include any rule they want and take the chain in whatever direction they want. They could even block any change they do not like and turn to ~~Lightning Network~~ Avalanche to solve all the problems.
**Exactly** like Blockstream, and there's nothing anyone can do about it.
Except of course what the rest of the Bitcoin Cash community are currently doing: We're booting ABC the fuck off our chain and if you care about BCH you should join in.
We must take ABC's misinformation campaign seriously
I'm currently reading the book Bad Blood: Secrets and Lies in a Silicon Valley Startup. It's an amazing story of how a Stanford dropout got this amazing idea to revolutionize the blood testing industry and founded a Silicon Valley startup that at one point was valued to a staggering $9 billion. https://www.goodreads.com/book/show/37976541-bad-blood
Too bad it was all fake and everything was built on lies.
The story of Theranos reminds me of how successful deceit and misinformation campaigns can be. Their blood testing devices had **absolutely zero** validation yet highly intelligent people invested hundreds of millions of dollars into the startup.
The best part? To this day, even after the magnitude of the scam has been revealed, people still defend them.
And there's one question on everyone's mind:
How could so many be so fooled?
Nothing new under the sun
If you've been following the cryptocurrency space, this story should be familiar to you. All these garbage ICOs follow the same pattern of people throwing millions at them despite tons of red flags and empty promises.
Bitcoin's so-called scaling solution is another example. The Lightning Network is still years away from reaching the same user experience that Bitcoin had five years ago, yet people *still* cling to it as the saving grace. If they haven't moved on to promote the centralized Liquid sidechain of course.
Why are people so gullible?
Propaganda works
If you tell a big enough lie and tell it frequently enough, it will be believed.
Hitler
The unfortunate answer is that misinformation and propaganda works.
It's difficult and time consuming to fact check everything you hear. Therefore we rely on heuristics such as listening to a person with perceived knowledge. This often works well, for example it's often a very good idea to listen to your doctor.
But it's of course not a perfect strategy (that's why it's called a heuristic). For example you might be inclined to listen to Adam Back because he's mentioned in the Bitcoin whitepaper, because surely that means he's a Bitcoin expert?
Sadly that's not the case as he'd recommend you to use Tabs™ instead of Bitcoin.
No, "just educate yourself" isn't the simple answer you might think it is. It can take a **lot** of time and energy to teach yourself difficult topics. We're talking years or even decades of full-time effort depending on the subject and a person's preexisting knowledge.
And of course, when you've done that for one subject (maybe medicine) then you need to do that with all the other subjects (politics, fitness and cryptocurrencies). All while working your job, taking care of your kids and being busy with living.
This is why it's our job to break down these issues into easily digestible pieces so that everyone has a chance to understand the problem and the possible solutions. This is why we, "the experts", must not stay silent when we see misinformation. Because if we do, we doom everyone else.
ABC's misleading message
Now when I've hopefully convinced you of the importance of countering misinformation, I'd like to bring your attention to the latest propaganda piece by ABC. https://blog.bitcoinabc.org/2020/09/14/preparing-businesses-for-a-successful-network-upgrade/
In it ABC argues that the safest cause of action for businesses is to use Bitcoin ABC for the Bitcoin Cash upgrade in November. And their argument sounds convincing, they say that the profits will be 100% secure, that transactions will always be final and that your business should see an increase in new customers. Sounds perfect!
Except that it's all misleading.
The biggest omission is that if you run ABC you risk **getting stuck on a minority fork without any support**.
Because if a majority of hashrate runs other software, by their own admission ABC will fork away from the chain. And that's looking pretty darn likely because currently 54.1% are signaling BCHN and **0%** are signaling ABC. If this continues then you even risk getting stuck on a chain that's not processing any transactions at all! https://cash.coin.dance/blocks
Most of the Bitcoin Cash ecosystem has already taken a stance against ABC saying they will not support their chain. This includes all other full node clients, all wallets (other than the Bitcoin ABC full node), the SLP foundation (the de-facto BCH token solution) and this very site. https://read.cash/@georgedonnelly/amaury-sechet-is-forking-bitcoin-abc-away-from-bitcoin-cash-8734adc1
"Your business should see an increase in new customers" my ass. If you go with the ABC chain your customers won't even have wallets to use.
ABC's propaganda isn't just misleading, it's outright dangerous. And we who care about the BCH community must speak up and educate our fellow men and women.
ABC are playing chicken with the Bitcoin Cash community
In the beginning there was Bitcoin. People collaborated around Satoshi's ideals and all was good.
Then people started disagreeing if Bitcoin could scale, and some forked off into Bitcon Cash to pursue on-chain scaling. While the group was smaller, things were good again.
Then Faketoshi came around and gathered a following. Some people tried to make amends, but the group still went ahead with their "hash war" and forked off to their own chain. The group grew smaller again, but things were still pretty good.
Then some people wanted to make improvements again, backed up by some juicy research, but the Benevolent Dictator said: https://www.linkedin.com/in/deadalnix
Hmm... No, we're gonna do it my way. If you don't like it ~~fuck~~ fork off.
And the group got worried that it would get smaller again, and things weren't so good anymore.
Forking is the fail-safe, but it guts the community
Forking is a wonderful thing. It's the mechanism that ensures that if a cryptocurrency is taken over by bad actors, or if it stops following your ideals, as a last resort we can always fork the chain to go our own way. We don't have to compromise if we don't want to.
But there's a big downside to forking, and it's **gigantic**.
When the chain forks, the community forks as well. A fork hurts the most important thing for any cryptocurrency, namely the **network effect**. People, projects, price and general mind share go separate ways, ensuring that both sides of the fork lose.
Just look at the history of forks. Sure we have the forks that nobody use, which does no real damage, but then we forks where a sizeable part of the community split.
When the BTC/BCH split happened, many people left BTC for BCH and took their money, their projects and their support with them. Even if you may not like him, Roger Ver has done a lot for Bitcoin adoption and he took his company and his funds to the BCH side. Or how in BCH we have several wallets and full node clients that are exclusive to BCH. Or the various places in the world that are now adopting BCH instead of BTC (I've used a few of them myself).
BTC lost something important in the BCH split.
Even if I absolutely loath Craig Wright and I'm glad I don't have him in our community anymore, other people and projects left for BSV when they split from BCH and they are valuable.
BCH lost something important in the BSV split.
While it's good that the ability to fork exists, a fork where a significant part of the community split is among the worst things that could happen to any cryptocurrency, and it should be avoided at (almost) any cost.
Chicken
The game of chicken is a game between two players. The best outcome is if one player yields, but none of them wants to because they want to win (and avoid being called a "chicken"). https://en.wikipedia.org/wiki/Chicken_%28game%29
For example a game where two people are driving a car right at each other. The one who swerves away first loses and is a chicken shit, but if none of them do then they'll crash and fucking die.
ABC plays chicken during network upgrades
Since the creation of Bitcoin Cash ABC has had an approach to network upgrades that's exactly like the game of chicken.
It boils to them announcing what features they're going include before anyone else has announced anything, and then don't budge an inch. (They rip out the steering wheel while the other player is watching.)
They say:
Follow our lead, or fork and split the community.
It's also what they've done repeteadly on issues large and small, ranging from rejecting BU's OP_GROUP proposal (support for miner verified tokens) to choosing our currently broken DAA, going against the opinions of all other developers in the community. https://bitcoinabc.org/2017-11-01-DAA/
History's repeating itself with ABC announcing that they're moving forward with the Grasberg DAA, despite **everyone else** agreeing that another algorithm is better. In the following discussions their response has been that they've already decided, and that the BCH community is not their customer. (Yes, Amaury really did say that.) https://read.cash/@deadalnix/announcing-the-grasberg-daa-88c61cee https://www.youtube.com/watch?v=EGddt-ryRDI&t=3h23m55s
ABC are again playing chicken. If they win they get to activate changes of their choice, but if they lose the BCH community will lose badly.
So far the other developer teams have always folded and have followed ABC's lead. BU dropped OP_GROUP (and later on the improved proposal GROUP), because they decided (correctly) that splitting the community over the change wasn't worth it. ABC won the game of chicken against BU.
BCHN has gotten some flack on social media by ABC supporters that they want a split, but the opposite is true. Even if IFP would've activated, BCHN would follow the IFP chain. Despite BCHN being fundamentally opposed to the IFP, they recognized that splitting the community would be worse so they went out of their way to avoid the split. ABC won the game of chicken again.
They say actions speak louder than words, and ABC's actions say that they don't put the interests of the Bitcoin Cash community first. **ABC prioritizes ABC above else**, and **don't seem to care that their actions might split the community**.
If they really did put the BCH community first, they would drop Grasberg to avoid a disastrous split.
The BCH community is in a lose-lose scenario
Now the BCH community is in a really bad position. Because if they call out ABC on their bad behaviour, there's a really high risk that there will be a split. ABC don't seem to care, so there will be two different consensus rules and therefore it's extremely probable a split will happen.
But if the community always gives in and lets ABC do whatever they want, and in effect let Amaury become the dictator of Bitcoin Cash, there will also be dire consequences.
A lot of great developers have already been chased away by ABC, which will continue happening. For example the talented developers who are working on the other full node clients, or Jonathan Toomim who wrote one of the most well researched proposals in BCH history (where he suggests a DAA algorithm for this upgrade).
We'll also start activating poor technical solutions, such as the previous DAA and Grasberg, which means we'll start to lag behind other competing cryptocurrencies on a technical level.
(See my previous article of why Grasbergs hurts the sound money properties of Bitcoin Cash.) https://read.cash/@noise/grasberg-will-weaken-the-sound-money-properties-of-bitcoin-cash-af976406
But what's **even worse** is that we'll essentially give up decentralization, the absolutely most important thing for a cryptocurrency and the one thing that differentiates it from PayPal or Libra. There's just no way we can claim that we're truly decentralized if we have a dictator who can push through any change he wants.
(Like messing with the emission schedule or redirect the blockreward to themselves. Or maybe take something from Vitalik's playbook and censor transactions.)
Then what should we do?
A split sucks and letting ABC to unilaterally dictate the protocol also sucks. Anything we do will suck in one way or another.
Maybe if we could convince most users and miners to switch away from ABC, maybe to BU or BCHN who have worked to keep the community together, then a split might suck less?
Alternatively we could just give up the idea of decentralization and declare that decentralized cryptocurrencies were just a pipe dream.
Grasberg will weaken the sound money properties of Bitcoin Cash
Recently Bitcoin ABC announced that they're moving ahead with the Grasberg DAA algorithm for Bitcoin Cash. There are many things I'd like to criticize about the proposal, including that it's not a proposal but a threat in a game of chicken, and many have done so already. https://read.cash/@deadalnix/announcing-the-grasberg-daa-88c61cee https://en.wikipedia.org/wiki/Chicken_%28game%29
Yet there's one very important thing I feel haven't gotten the attention it deserves, and that's the claim that correcting the historical drift would strengthen the sound money (or hard money) properties of Bitcoin Cash.
As I'll explain, I believe that correcting the historical drift will be detrimental for the sound money value proposition as it makes arbitrary changes to the emission schedule.
What is drift and drift correction?
In Bitcoin Cash we want the time to be around 10 minutes between blocks. We can't have it always be exactly 10 minutes, but on average this is what we'd like.
The problem is that the hashrate of Bitcoin has been rising a lot since it's invention and the algorithm couldn't correct for that, so the average time between blocks is closer to 9 min 30 sec instead of the targeted 10 min. Since new coins are created with each block this means that the predicted emission schedule has been shifted, and more new coins than initially predicted have been created.
This is "drift" and the idea of drift correction is to make the time between blocks be 10 minutes on average.
But there's a subtle, but important, detail here. Do you:
Correct the drift going forward, so starting from the upgrade date all future blocks will have an average time of 10 minutes.
Correct the historical drift, so starting from the total lifetime of Bitcoin Cash all blocks have an average time of 10 minutes.
We cannot do both so we must choose one. This is the key technical issue that's currently dividing the community.
In the last DAA dev meeting one of the reasons Amauary gave for choosing to correct the historical drift was that the new DAA algorithm had to choose a reference point, and he didn't like it to be an arbitrary block so the only choice would be the genesis block. https://www.youtube.com/watch?v=F5b0Unf1aA0
This is a completely invalid reason and it's purely an implementation detail that nobody except a developer with OCD might get annoyed over. It's like arguing for black screws over silver screws inside an engine because you find them prettier. *It does not matter.*
(There are technical reasons to choose the block before the upgrade as the reference point, which is why all other DAA proposals did just that, but I won't get into them here.)
The other claim that it would improve the sound money property demands a longer answer, but first what is sound money?
What is sound money?
If you google "properties of money" you might find this infographic:
http://money.visualcapitalist.com/tag/properties-of-money/
It says that money should be fungible, durable, portable, divisible, acceptable, uniform and limited in supply. The only thing that matters in the DAA context is that money should be **limited in supply**, which means that a relatively constant supply of money should ensure that values remain relatively constant.
It means that money should avoid the trap that fiat easily falls into, where banks print tons of money to inflate the supply. The money supply should be fairly constant and resistant to change.
This is also something that Amaury said in the dev meeting, that we must *under no circumstances* alter the emission schedule of Bitcoin Cash. This is absolutely something I agree with and a vital part of sound money is that nobody can change the money supply or the emission rate.
It's why gold has been the prototype of sound money for centuries. Despite a lot of efforts by alchemists nobody managed to create gold. The only way to get new gold is to find it in the earth and dig it up, which is naturally constrained by nature.
The gold supply is literary set in stone.
Historical drift correction is an arbitrary change to the emission schedule
It would be great if we had a time machine so we could go back and replace Satoshi's DAA, which is also the cause for most of the drift, with a better one. This is the only way we could truly fix the historical drift.
But sadly we cannot. So Grasberg does the next best thing, it tries to compensate for the drift by introducing even more drift! It *slows down blocks* by about 12.5% for five years, meaning we'll have 11 min 25 sec average blocks until 2025 and after that it goes back to 10 minute average again.
If you think that sounds arbitrary you're right. Grasberg includes **completely arbitrary** parameters, which Amaury cited as a reason to reject the other DAA proposals. The difference is that Grasberg changes the parameters of the all-important emission schedule that will affect all users of Bitcoin Cash, while the alternatives makes a choice with no consequence for any user.
Why couldn't we compensate for the drift during a 100 year period instead of 5 years? Why not 10 years? Hell, why couldn't we do it all in one year, rip the band-aid and get it over with?
No reason.
Make no mistake, while we may call it a "drift correction", a "drift reparation" or a "drift compensation" it's really an arbitrary change to the emission schedule, and this in turn has direct consequence on the supply of Bitcoin Cash.
The only non-arbitrary choice is to simply ignore the historical drift.
(The real purpose of the DAA change is to reduce the gameability of the algorithm, where miners are able to abuse the algorithm for profit and to the detriment of all users.)
How large of a drift are we talking about?
I think it's important to understand how large drift we're talking about here.
According to Jonathan Toomim in Dec 2020 there will be 1.3% more coins in circulation than a perfectly average 10 minute blocks would have produced. If we would activate ASERT (which does not compensate for historical drift) this will be lowered to 0.6% in 2025, but will in 2025 be 0% with Grasberg (and unchanged after that since none of them drift). https://www.reddit.com/r/btc/comments/i0b54f/in_dec_2020_there_will_be_13_more_coins_in/
So with Grasberg we will have 11 min 25 blocks for 5 years, to correct a 0.6% drift.
What image does changing the emission schedule present?
While Amaury wanted to send a message that Bitcoin Cash is sound money, and that we'll never change the emission schedule, what image would we really be sending?
We would be signaling that we find arbitrary changes to the emission schedule acceptable and that we're fine with changing supposedly untouchable parameters of Bitcoin Cash, for a measly 0.6%.
People will start to wonder, what will they change next? Alter the 21 million coin limit? Move Satoshi's coins? Or perhaps reassign a part of the miner reward to the benevolent dictator himself?
It seems pretty clear to me that messing with the emission schedule like this weakens our image as hard and unchangeable money.
Compensating for the historical drift has **never** been mentioned before Grasberg, despite months and years of DAA research, simply because nobody cared that the historical average time between blocks isn't exactly 10 minutes. People have realized that we cannot change the past and what's important is the time between blocks going forward.
Amaury thinks he has sound money figured out, but his proposal would hurt the sound money quality, not improve it. Nobody should be able to manipulate the supply or creation rate of sound money, yet Grasberg would do exactly this.
If you really want Bitcoin Cash to be sound money, you should reject Grasberg.
I apologize for not adding timestamps to some of the things Amaury said in the DAA meeting, I don't have time to listen to it again just to add them to my references. https://www.youtube.com/watch?v=F5b0Unf1aA0
I also must thank the ABC team for so conclusively prove that they do suffer from the Not Invented Here Syndrome with their Grasberg proposal. I did kind-of predict it in an earlier article of mine, but I didn't expect it to be so egregious. https://www.reddit.com/r/btc/comments/i0bvo7/this_is_what_not_invented_here_syndrome_sounds/ https://read.cash/@noise/the-not-invented-here-syndrome-in-bitcoin-cash-development-f22113b0
The Not Invented Here Syndrome in Bitcoin Cash development
Changing the Difficulty Adjustment Algorithm (DAA) algorithm in Bitcoin Cash has been a hot topic. To understand what this means, and why it's important, please read jtoomim's excellent article on read.cash.
I can't say I understand all the technical nuances of the issue, and certainly not how we should determine which algorithm is the best, so I've only been following the discussions from the sideline. Some might say that makes a poor developer, but I think knowing when you're out of your depth is a strength, not a weakness.
Just consider what happens when two teachers (you know, the ones in school who are supposed to know what they're talking about) are asked something they don't know. One who tries to give an answer even if they don't really know and one says they don't know, but they refer to a resource where the students might be able to find an answer.
Who is the best teacher?
It's obviously the one who can admit they don't know and that others might know better.
Yet this is hard to do and it's a mistake many developers (including me) have made. This is called the Not Invented Here Syndrome (NIH), and I think it's rearing it's ugly head in the Bitcoin Cash space again. https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 https://en.wikipedia.org/wiki/Not_invented_here
The Not Invented Here Syndrome (NIH)
Developers who suffer from NIH are biased to choose their own solutions instead of using existing solutions or accepting solutions that others suggest, even if it's worse in every way (sometimes significantly so). This isn't done out of malice, but it's a psychological trap all of us are susceptible to.
I've worked with people who took this to the extreme and wanted control over *everything*. So they created their own algorithms for graphics manipulation, database schemes, file formats and even their programming language, while rejecting any alternatives as worse as their default, and only, stance.
But I digress. The reason I started thinking of NIH was jtoomim's recent comment on reddit, in a discussion about the DAA change: https://www.reddit.com/r/btc/comments/hqt37u/this_deserves_its_own_post/fy09duk/
I was initially trying to keep discussion public and transparent, because that's how I think things should be done. But it's become clear that **this is a sensitive issue for ABC for some reason**, so I'm now trying to have a private, no-audience, off-the-record conversation about it. No, I can't tell you if I'm having any luck or trouble with that endeavor.
I think the reason is that ABC is suffering from NIH, and they find it difficult to accept a non-ABC solution.
The history of DAA and NIH
The mining difficulty in Bitcoin Cash has long been an issue. When Bitcoin Cash split it used something called the Emergency Difficulty Adjustment (EDA) that forcefully lowered the difficulty if very few blocks were found, but it allowed for miners to heavily abuse the system:
(Image from https://medium.com/@Mengerian/bringing-stability-to-bitcoin-cash-difficulty-adjustments-eae8def0efa4)
A new DAA was discussed to solve this issue, and many developers were working together to decide on a new replacement. However I, and many others, were surprised when ABC suddenly announced that they had chosen the next DAA, and it would be ABC's own proposal.
The reasoning they gave was suspect: https://bitcoinabc.org/2017-11-01-DAA/
We have the utmost respect for the all developers involved in the discussions, but only one algorithm could be chosen, and a timely decision was required.
Therefore, we decided to take a scientific approach and utilized two impartial and unconnected testing teams: Bitprim and nChain. These teams conducted their tests separately and came to the same conclusion of which algorithm was most appropriate.
Firstly it's not a scientific approach to hand off the decision to two teams, and just take their arguments as truth. Especially as they never released their research methodology and research data, making us unable to falsify their tests (a core property of the Scientific Method).
Secondly nChain, spearheaded by serial scammer and fraudster Craig Wright, is (and was) a known bad actor and has not acted in the best interest of Bitcoin Cash.
Thirdly the DAA was already known to have serious problems, problems that we're now experiencing first hand (see jtoomim's article for details).
Now I must reiterate that I don't believe ABC chose the current DAA out of malice. But I do think the bias that NIH introduces played a big part, making ABC ignore the problems and only focusing on the positives of their proposal.
(As another example micropresident, an ex-ABC dev, wrote an article where he suggests we should now change to another ABC made solution. This suggestion was shut down by jtoomim in the comments.) https://en.wikipedia.org/wiki/Scientific_method https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 https://read.cash/@micropresident/review-of-the-asert-daa-proposal-cf430228
ABC has a history of NIH
ABC's history of NIH isn't limited to the DAA and there are other examples.
Pre-consensus
Years ago ABC came out and said that Avalanche will solve pre-consensus for Bitcoin Cash (basically improving 0-conf). But in the process they're ignoring other potential solutions such as Storm and are continuing to focus purely on Avalanche as the solution, despite serious and unsolved concerns.
Token proposals
ABC has been anti tokens in Bitcoin Cash, that the focus should be on p2p digital cash and nothing else, and I agree.
But when arguing against it they promoted permissioned tokens as an alternative and they argued against (and blocked) the GROUP_BY proposal without really understanding it. (There's a video of this discussion, but I'm sorry to say I didn't manage to find it.)
The color of the logo
Perhaps a silly example, but NIH is prevalent even in the choice of Bitcoin Cash logo. While most of the community prefers the Bitcoin Cash logo to be green, ABC still clings on to the orange logo.
It's well understood in marketing that presenting a consistent image is very important, and consequently an inconsistent use of logos harms the Bitcoin Cash brand. Therefore the priority should be to make the community switch to the same type of logo, instead of holding on to your favorite just because that's what you like. Especially if it's something minor like the color of a damn logo.
If you've been following the development I'm sure you can come up with other examples, these are just some of the biggest examples.
What can we do about it?
Why do I focus so much of my attention on ABC?
Because they're the de-facto lead implementation and so far in the history of Bitcoin Cash they have dictated the development. If ABC implements a consensus rule then everyone else followed and if they opposed a feature then it got abandoned.
The leader of of BCH development, whoever that may be, must be super vigilant for the negative effects of NIH, and actively and consciously work to avoid it, otherwise we run the risk of getting stuck with problematic solutions or miss out on better solutions.
If ABC cannot do this then I think it would be better if another team would take over as the leading implementation.
What if Bitcoin Cash had an owner?
In my last article I argued that Bitcoin Cash is nobody's project, but we as a community collectively own and manage it. https://read.cash/@noise/bitcoin-cash-is-nobodys-project-a-response-to-micropresident-ce3671ba
But **what if** there was someone who owned Bitcoin Cash? And could implement any changes he'd like? What would that mean for the project?
I'll argue that it would severely undermine Bitcoin Cash and make it unsuitable as peer-to-peer digital cash for the world.
Some crucial properties of peer-to-peer digital cash
First some important properties a cryptocurrency should have:
Transactions cannot be censored.
The supply cannot be manipulated.
There are other properties, but to me these are the two most important properties that makes cryptocurrencies stand out from other alternatives.
What a dictator would mean
Now what if there was someone in control of Bitcoin Cash? Someone who could change the protocol in whatever way they wanted to? What would change?
Everything.
This person could censor transactions by implementing blacklists on the protocol level or steal coins from arbitrary addresses, making Bitcoin Cash censurable. It's the same fear some people have with most mining being located in China, as it might allow China to censor the protocol, but concentrated to a single person.
Ethereum did something similar after the DAO hack when they rerouted funds from a wallet outside their control, essentially breaking the contract of the Ethereum protocol. Most of the Ethereum community seems to be content to let Vitalik do whatever he wants with the protocol, essentially making him the dictator of Ethereum.
The supply could also be manipulated by changing the emission schedule or simply give himself a million BCH, destroying the soundness of Bitcoin Cash while doing so.
In short if Bitcoin Cash were dictated by a single person it would undermine the core properties that make up a decentralized currency.
We as a community must be active
Luckily no single person controls Bitcoin Cash so this is all preventable. Instead it's the community; the users, exchanges, payment processors, miners and other stakeholders that together control Bitcoin Cash, and they have the power to together block these changes.
**But** it requires us to be active. It requires us to be informed and above all it requires us to take action to prevent changes such as changing the supply limit or reversing transactions.
It's like a democracy. The voters have the power, but if nobody votes then we'll give that power away. And if we, the Bitcoin Cash community, truly want to be peer-to-peer digital cash for the world then we cannot allow **anyone** to assume the role of benevolent dictator over the protocol. Not Gregory Maxwell, not Amaury Séchet and not even Satoshi.
The battle for the leadership of Bitcoin Cash isn't just important, it's essential.
Bitcoin Cash is nobody's project, a response to micropresident
I read micropresident's recent post The Cryptocurrency of Theseus and wanted to share my thoughts on some things I take issue with. https://read.cash/@micropresident/the-cryptocurrency-of-theseus-what-is-our-identity-and-why-are-we-fighting-16ff0d1b
His post is pretty long, but the TLDR is that Bitcoin Cash is Amaury's project and if we disagree we can take a hike.
(While writing this small response, @mtrycz had already published one, which I am in complete agreement with.) https://read.cash/@mtrycz/a-humble-response-to-the-cryptocurrency-of-theseus-8f8c22f6
Bitcoin Cash is a protocol not a single piece of software
The main problem with the argument is that micropresident asserts that Bitcoin ABC is Amaury's project, which is hard to disagree with, but extends it to mean that Bitcoin Cash is Amaury's project. Essentially he's making the error that Bitcoin ABC **is** Bitcoin Cash.
But this isn't true.
Just think about it. What would happen if suddenly all users, exchanges and miners stopped using ABC? Would Bitcoin Cash stop being Bitcoin Cash, and a new cryptocurrency be created?
Of course not. It would continue functioning *exactly the same*. But if ABC really defined BCH, this wouldn't be true.
Who defines Bitcoin Cash then?
Micropresident himself touches on the answer:
So that is to say, Bitcoin Cash is the thing which the users agree is Bitcoin Cash and can be used as currency.
Nothing more, and nothing less.
It's tempting to try to drill deeper into the definition and to figure out exactly what users would agree to be Bitcoin Cash.
Micropresident says that thinks that Bitcoin Cash is defined by whatever data ABC produces. But that has absolutely no relevance if others don't follow the same definition. What if they would define Bitcoin Cash by whatever data Bitcoin Unlimited would produce? They've been following the same consensus rules, so what happens if they would differ in the future?
Instead we could try to find something that *most* users could agree with. For example:
Bitcoin Cash is whatever chain most exchanges assign the BCH ticker to
I don't really like this definition either, but I'll bet that it's more correct because more users would agree with this definition over micropresident's. I'll even wager that most people who buy Bitcoin Cash don't even know what Bitcoin ABC is!
There are many other definitions you might use, such as defining Bitcoin Cash as the longest chain starting from the split from Bitcoin or as whatever Faketoshi says it is.
We might even face a situation where two significant groups disagree about "the right chain", which of course was a big part of the Bitcoin/Bitcoin Cash split.
To the agitation of engineers everywhere I think it's impossible to find an objectively true and detailed definition of what defines Bitcoin Cash, because everything is subjective.
(If you'd like to learn more about economics look up the Subjective theory of value which is related to this concept.) https://wiki.mises.org/wiki/Subjective_theory_of_value
Monero fired their benevolent dictator
Micropresident argues that we **cannot** kick Amaury, as in we cannot because it's impossible.
Yet Monero did exactly this when people disagreed with the direction of the project, and a new team took control of the project while firing the old team. See this stackexchange answer for some history. https://monero.stackexchange.com/questions/1011/monero-inception-how-did-bitmonero-become-monero
Impossible? No, it's just difficult to get the community on board.
Unthoughtful and ignorant, stupid or malicious
Although the article is heavily arguing that ABC == BCH (as all ABC supporters seem to do), I do appreciate micropresident writing the article. But I do not appreciate this remark:
The people who continue to battle over who gets to be “in charge” can reasonably be assumed to be: unthoughtful and ignorant, stupid, or malicious. I will be referring to this letter in all future discussions that draw into question Amaury’s right to lead his own project. Those of us who want to move forward cannot endlessly spend time debating people who are willfully ignorant, stupid, or malicious.
Here he's essentially calling anyone who disagrees with him "unthoughtful and ignorant, stupid, or malicious". This is the same type of argumentation that BTC maximalists, flat earthers and anti-vaxxers use to dismiss anything that goes against their opinions and it should have no place in our mission for p2p digital cash.
It's something only someone who's unthoughtful, ignorant, stupid or malicious could write.
The fundamental technical challenge with Avalanche, and how it hinders on-chain scaling
Apart from how to integrate Avalanche with Bitcoin Cash's consensus mechanism, there is another difficult problem we face when integrating Avalanche. The problem boils to down to this simple question: https://read.cash/@noise/dont-roll-your-own-consensus-algorithm-and-the-dangers-with-pre-consensus-for-bitcoin-cash-70b3e83f
**Will Avalanche run directly for every transaction?**
If the answer is yes, then it will hinder our prospects to scale on-chain. But if the answer is no, then it will cripple it's effectiveness in preventing 0-conf double spends.
But I thought Avalanche would help us scale?
Yes, Avalanche will help us scale *in one aspect*. Avalanche will help miners sync their mempools, which would make blocks propagate faster making the network support larger blocks.
But scaling isn't a single monolithic thing. There are many aspects we need to consider when increasing on-chain capacity besides block propagation. With Avalanche the bandwidth usage for nodes will go up. So instead of nodes being busy sharing transactions and block information, they will also have to bounce Avalanche messages between each other, which reduces the space for transaction data.
This also opens up a large DDOS vector, where an attacker could easily flood the network to overload nodes and to crowd out crucial transaction and block propagation.
Coins with zero-fee transactions face a similar problem, and the only solutions we've seen so far have been to centralize the network or half-assed anti-spam policies that are easily worked around. It's a very difficult problem to solve in a permissionless network.
What if we only run Avalanche when we notice a double-spend?
The obvious solution is to only run Avalanche when we notice a double-spend, or to shut it down when we face a spam attack.
But this makes Avalanche pretty useless in preventing 0-conf. To see why let's examine the different types of 0-conf, which I discussed in a previous post. https://read.cash/@noise/differencing-between-different-types-of-0-conf-double-spends-852316b1
When Avalanche is run for all transactions, it does prevent 0-conf in many cases:
Fast double-spends
**Avalanche does not improve over double-spend proofs**
Delayed double-spends
**Avalanche helps**
Miner assisted double-spends
**Avalanche helps**
To see why this is so, please read the previous post. https://read.cash/@noise/differencing-between-different-types-of-0-conf-double-spends-852316b1
But if we only run it for a transaction which is double-spent, then Avalanche does not help:
Fast double-spends
**Avalanche does not improve over double-spend proofs**
Delayed double-spends
**Avalanche does nothing**
Miner assisted double-spends
**Avalanche does nothing**
The reason Avalanche does so poorly here is that it hasn't decided anything about the transaction before it's too late.
In the case of a delayed double-spend, Avalanche would only kick in after the scammer has left the store.
With a miner assisted double-spend the double-spend is only seen in the block for the first time. While in theory Avalanche could be used to orphan that block... It seems highly unlikely that it would be implemented that way as the risk-averse miners would want to accept it.
So we can conclude that Avalanche must be run directly, otherwise it's useless, but this hurts our scaling prospects. We're stuck between a rock and a hard place.
Is there an alternative?
There's no ready solution, but there are some good proposals out there. For example:
0-conf forfeits is an excellent proposal that could reduce the risk of any 0-conf double-spend, but it comes at a severe user experience cost. https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd
Storm reduces the risk for delayed double-spends and miner assisted double-spends, without a radically increasing the network's bandwidth usage and it builds on, instead of replaces, the tried and tested consensus mechanism on Bitcoin. https://github.com/awemany/storm-sim/raw/master/whitepaper/storm-wp-2019-08-30.pdf
Differencing between different types of 0-conf double-spends
I've noticed a disturbing trend in the discussion around 0-conf security, the risk of double-spending them and how pre-consensus would solve them. There's a bunch of hand-waving and people leaving out details in discussions, making us all confused. That's why I'd like to clarify some things.
There are different types of 0-conf double-spends you can attempt, with different types of risks and mitigations. In order to understand this I've categorized 0-conf double spends into three major categories:
Fast double-spends
Delayed double-spends
Miner assisted double-spends
Although variations exist, I think these covers the different types of 0-conf double-spends as they can be derived from these three categories.
Important to remember is that it's impossible to solve 0-conf completely. Even transactions with one or several confirmations can be reversed and double-spent, so the best we can do is increase 0-conf security, but never make them truly safe.
The only thing that matters is if merchants get cheated. It does us no good to try to look at the network and decide how many successful 0-conf double-spends there are. For one these statistics come from a single node that's observing the network, but what's to say that the timestamps that particular node sees are correct? It cannot.
Fast double-spends
A fast double-spend is when you pay a merchant and then very quickly, within seconds, try to double-spend that transaction. There are different ways you can do this, like setting a very low and a very high fee on the transactions or connecting directly to miners and giving them the double-spend, but the main idea is the same; show the merchant one transaction but try to make the network propagate another.
This is something that double-spend proofs help mitigate. The idea is to give the merchant a quick notification that a double-spend, and thus an attempt at fraud, has occurred.
ALERT Scam attempt detected! ALERT
With Avalanche a double-spend can be resolved in 3 seconds or so, and it might look like Avalanche would help prevent fast double-spends. But what actually happens when it does so?
If a scammer successfully double-spend a merchant, the best you can do is give the same "scam detected" alert, and hope that the merchant takes appropriate action.
If a scammer tries to double-spend, but is unsuccessful, Avalanche simply gives you the option to ignore the alert.
This is a very marginal benefit. If you catch a shoplifter, you don't send them away and wish them a good day. You call the police and charge them for shoplifting.
Why then would you you choose to ignore a failed double-spend, which is proof of a scam attempt? It doesn't make sense to me.
Therefore **Avalanche is not an improvement over double-spend proofs** in this case. Storm is also too slow for this case.
0-conf forfeits is a better solution, but it has the drawback of having to commit a larger amount as insurance, which you'd forfeit if you attempt a double-spend. https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd
Delayed double-spends
A delayed double-spend is similar, but instead of double-spending directly you wait until the purchase is completed. Maybe you'll double-spend after you walk out the store.
This is more difficult to pull off, since the risk of a miner already including the transaction in a block increases. It's also more difficult to get your double-spend propagated through the network, as nodes may reject it using the first-seen rule. Of course this depends on node settings, and they're free to ignore this as they please, which is one of the main arguments for pre-consensus.
Avalanche would indeed help here, *assuming it's run directly for every transaction*. If it's only run when a double-spend is detected, then the merchant doesn't know if the transaction he sees will be confirmed until much later, when the scammer initiates a double-spend.
Other proposals such as weak blocks, or "delta blocks" in the Storm proposal, would be fast enough (< 1 min) to mitigate this scenario. 0-conf forfeits would also be helpful.
Miner assisted double-spends
The final, and arguably most difficult, type of 0-conf double-spend is a miner assisted one. So instead of propagating the double-spend to the network, a miner holds on to the double-spend privately and includes that one in the block instead of the original payment. The scammer might be in collusion with the miner or a miner could setup a "double-spend as a service".
The success rate depends on the total hash-rate of the miner and the only risk for the miner is a slightly increased orphan risk if the miner does this with many transactions.
This is where pre-consensus truly shine.
Storm would heavily discourage miners from doing this, as weak blocks are backed by proof-of-work and use the same incentives that make Bitcoin work in the first place.
Assuming Avalanche is allowed to orphan blocks, miners would be discouraged as they wouldn't want their blocks orphaned. Here again Avalanche would have to be run for every transaction, otherwise we don't know if the transaction included in the block should be orphaned or not. (It's annoying to make these assumptions, but as there's no specification we can only make educated guesses here). https://read.cash/@noise/dont-roll-your-own-consensus-algorithm-and-the-dangers-with-pre-consensus-for-bitcoin-cash-70b3e83f
Don't roll your own consensus algorithm, and the dangers with pre-consensus for Bitcoin Cash
There's a famous saying in the world of cryptography that states that you should never roll your own crypto. It's popular because it's *extremely hard* to get it right, and you should in 99.999% of all cases use an existing algorithm or library instead of creating your own.
Writing your own cryptography should only be done in extreme circumstances, and only by experts who dedicate their lives to cryptography. And even they get it wrong and vulnerabilities in existing algorithms and implementations are found routinely.
Even Bitcoin, which I consider one of the biggest inventions in modern times, did not roll it's own cryptographic functions. It only uses plain, boring and most importantly old cryptography. It's battle-tested so we know it's solid. And if, god forbid, public-key cryptography is broken we have bigger problems, as it would break the whole internet.
But Bitcoin did contain one big innovation; the consensus algorithm. Aligning the miners' incentives with that of the network's by using proof-of-work (POW) is the true genius of Bitcoin, and is to me the important property that must not be compromised. Therefore I'd like to adapt the saying for us in the cryptocurrency space:
**Don't roll your own consensus algorithm**
There is nothing better than POW
There have been many attempts at improving POW, such as proof-of-stake (POS), delegated proof-of-stake (dPOS), proof-of-capacity (PoC) and more. They've all promised impressive improvements over POW, like massive scaling or fee-less transactions, but to this day they all suffer from serious unsolved flaws. With POW for example you have to continually invest to stay relevant, both in energy cost and new mining equipment, but with POS you do nothing but sit on your coins. Once you capture a majority in a POS system, you'll be able to keep it for a long time, and there's not a whole lot people can do about it.
I understand the want to solve the problems with POW, such as the large waste of energy, but it seems it's just *really hard* to come up with anything as good as POW, and I don't think people have fully grokked this yet.
Take Avalanche for example. It's a very cool idea that in theory can confirm transactions in just a few seconds. That's an amazing upgrade over Bitcoin where it's expected to take around 10 minutes for a confirmation. But the flaw is that Avalanche doesn't actually work by itself, for the system to work it needs to be augmented with a mechanism for sybil resistance, such as POW or POS.
The dangers with pre-consensus
Given the very nice benefits Avalanche could give us, it's attractive to try to leverage it for Bitcoin Cash. Perhaps as a form of pre-consensus, which would help make 0-conf much more secure and help miners synchronize their mempools, making blocks propagate faster and increase our scaling potential.
Amazing!
But hold on, first there's a big decision we need to make:
**Should Avalanche be allowed to orphan blocks?**
If the answer is no, there's no issue here. It may cause Avalanche to lose effectiveness, but there's no real danger with using it for Bitcoin Cash.
But if the answer is yes, then our Spidey Sense should tingle. What we're really saying is that Avalanche consensus can cause miners to ignore the longest chain rule and say that a shorter chain is the one we should mine on. This introduces more *weak subjectivity* that subverts Bitcoin's consensus algorithm, and substitutes it with rules that you can only follow if you're online and record the actions on the network.
This means that when you bring a node online, the longest chain is not necessarily the one you should follow! It's not like the Bitcoin and Bitcoin Cash split where each chain have different rules and your client can tell that one is invalid. Here *both* chains are valid, it's just that one is wrong for reasons you cannot identify. This is why the longest chain rule is so important, otherwise poor users such as you and me are completely lost.
As an aside ABC (and also BCHN) already subverts the longest chain rule by finalizing the chain after 10 blocks, which could in theory lead to a chain split. The difference with the Avalanche case is that a 10 blocks advantage is quite unlikely to happen, but with Avalanche the difference would be immediate from block #1.
If we do want Avalanche to orphan blocks, we still need to answer two questions:
**How should Avalanche sybil resistance be decided?**
Should it use the latest 100 blocks and rely on POW? Or should we use some version of POS?
**When should miners following a shorter chain switch back to the longer?**
If a block that's rejected by Avalanche still manage to be part of the longer chain, when should miners switch over?
Should it do so after a difference of 2 blocks? 6 blocks? 10 blocks? *Never?*
(Note that these important questions are as of yet unanswered. Almost feels similar to how the routing problem with LN weren't addressed before it was being pushed as the solution to world peace.)
This comes very close to rolling our own consensus algorithm, which might have dangerous and unintended consequences.
For instance we run the risk of introducing the drawbacks with POS into the system, where large coin holders such as shady exchanges could capture the consensus and gain a large power over the network.
Or if Avalanche should use coin-days as sybil resistance, we run the risk of a miner with a very large amount of BCH be given dangerous power over other miners. (A while ago it was said Bitmain had over 1 million BCH.) If the miner could gain control over Avalanche consensus, they might for example be able orphan the blocks of competing miners. The miners could of course start mining empty blocks, but as the block reward moves to zero, this is in practice the same as forcing them out of business.
What if Avalanche designates a transaction as a double-spend, but a miner thinks it has a too low fee and includes so it includes it's double-spending transaction, should the miner be punished for it? Who should decide what fee is just right?
And if we say that Avalanche should always overrule the longest chain, we've essentially replaced POW with something else. We then run on Avalanche consensus, and we might as well scrap POW altogether.
If your defense then is that miners can always manually switch to whatever chain the want... Then I say we've replaced POW with proof-of-human.
Is Avalanche the future for Bitcoin Cash? Maybe. But one thing's for sure, messing with the consensus algorithm should not be done lightly.
The IFP and unhealthy incentives
Recently Flipstarter has been a big success, funding the development of 4 out of 5 Bitcoin Cash full nodes, with only the ABC not reaching its goal. But despite this and the large opposition against the IFP, there are still those who claim that the IFP is better or even that it's the "only sustainable option".
The gist of the claim is that by forcing all miners to donate, it'll be the most fair and also force Bitcoin miners to fund Bitcoin Cash development. The miners must be forced to donate to "avoid a tragedy of the commons", which happens when miners who don't donate profit more and can outgrow those that donate. https://medium.com/@jiangzhuoer/infrastructure-funding-plan-for-bitcoin-cash-131fdcd2412e
Sounds good in theory, but there's a fatal flaw here that I don't think has been given the attention it deserves. So let's have a look at some incentives of the IFP, and why the IFP isn't a solution to the tragedy of the commons.
ABC is incentivized to push through no matter the cost
ABC is one of the main beneficiaries of the IFP, and is undoubtedly the ones who would benefit the most as it's the much preferred mining client. A successful activation of the IFP could mean millions of dollars in funding for them.
If you know you history then you know money is one of the prime motivators for people to do things; things they wouldn't normally do. Everything from shoplifting or insurance fraud to kidnapping and torture. Then it wouldn't be a stretch to say that even though the very concept of the IFP risks to split the community, ABC will still push forward. Not because of pure malice, but because they're incentivized to do so and it would be the rational thing to do.
This is how they manage to convince themselves that it's fine to merge highly controversial code Feb 15, with reviews happening right up to the merge, *exactly* three months before May 15, the planned fork day. https://reviews.bitcoinabc.org/D5282
You see because there's an agreement that no feature changes can be merged three months prior to an upgrade, it's fine if you do it just before the deadline! They also updated the specification two weeks later, renaming it to a "draft" and leaving this note: https://github.com/bitcoincashorg/bitcoincash.org/commit/cc21f831bd5f6be323723d82fd5d0998763a2703
**Important: This document is an in-progress draft, and may change prior to the 2020-05-15 upgrade**
I understand, because I've seen this play out many times in my professional career. People who are working on a feature, but it's only half-finished, so they push it through on the weekend right before the lockdown on Monday, without telling anyone. Because they can "fix it" before release, and it would "be dangerous" to remove it after feature freeze.
That it was discovered a week later and we spent years living with the aftermath is another story.
Even after the code has been merged, and after the opposition against the IFP has been cleared, ABC didn't back down. Instead they hired a PR guy (excuse me, "Business Development Manager") to better the perception of ABC and the IFP. Amaury still holds firm with the IFP and they're quick to dismiss any critique as "social media noise on r/btc", even though no other development team implemented the IFP and basically no miners have voted for it.
But it's all to be expected, and I predict ABC to try to forcefully push through IFP 2 the next hardfork. Because as other development teams gets community funding, they alone are left out. (Geez, I wonder if giving the community the middle finger has anything to do with it?)
Miners can earn more by kickbacks
On to the miners then. The fatal flaw with the IFP, or any forced donation scheme, is that miners can introduce imbalance by kickbacks. While miners are indeed forced to send a portion of their reward to a predetermined address, that doesn't mean the money will go to actual development.
For example if I'm a miner I could contact one of the holders of the addresses and give them a very enticing offer:
Hey developer! If I always choose your donation address, could you send back them to me? You're allowed to keep 25% of them. It's a win-win!
This is called a kickback and it would give them an edge against other miners. This is why the IFP doesn't actually solve the tragedy of the commons, as now the honest miners (or those who couldn't convince the devs) will pay for the development while the shady miners get more profit and are able to increase their mining share.
To make matters worse in the IFP there's a donation address that's already controlled by miners in the IFP code! (Well, that's what we can assume if we trust ABC as we *don't actually know who holds it!*) Those miners (or pools) don't even have to do any kickbacks, they can just pocket the rewards directly.
Now you might counter this by saying the address is held by a consortium of miners, that they'll ensure to keep each other in check.
Well, they could... Or they could come to an agreement that they all share the profits. Or they might create a "MoneyStream development team" who will solve all the major problems with Bitcoin Cash, but it's only purpose is the funnel funds to themselves.
Honest miners work for profit
Bitcoin works because of the premise that 51% of miners are honest. And *honest* doesn't mean they're kind or friendly, it means that they'll work for their own financial interest. This is the brilliance of Bitcoin; it aligned the incentives of the network with that of the miners, ensuring protection against double-spends.
Believing that the IFP will work is to believe that miners will act against their short-term financial interest, that they will be gentlemen (and gentlewomen) and *not* try to funnel money back to themselves. That's the same as conceding that Bitcoin's core assumption of honest miners doesn't hold, and if we believe that what are we even doing here?
A developer's thoughts about Bitcoin Cash development
You don't know me. I've been a Bitcoin supporter for many years, way before Bitcoin Cash was created and before the big scaling debate, but I've never taken an active roll. I've only ever been a lurker, watching from afar, even though I've been a professional software developer for more than a decade. In this post I'll try to explain why.
Money
I'm sure you haven't missed the talk about the miner tax?
And yes, according to dictionary it's a tax: https://www.dictionary.com/browse/tax
a burdensome charge, obligation, duty, or demand
Well one of the arguments is that it's absolutely needed because otherwise we wouldn't have any developers, and that would surely be the death of BCH.
Of course, I agree that we need to pay developers. I, like all humans I know, need to eat and I have a family to feed too, therefore I don't work for free.
While it's true that I would need to get pay if I would work on BCH full time, but it's not the biggest reason I haven't contributed. In fact I would've done it for free, because it would be interesting and because it would support the ecosystem, if it wasn't for the other issues.
Toxicity
When I was finally about to get off my lazy ass and contribute, the scaling debate happened. This brought forward a *ton* of toxicity, where people got censored, abused and even driven away from the development. I thought to myself that life's to short for this shit, so I distanced myself.
Unfortunately the toxicity didn't stop there. Even after Bitcoin Cash split off from Bitcoin it continued. Developers fought between themselves, and the de-facto reference client suffering from a severe Not Invented Here syndrome and they used a "our way or the highway" approach to development.
The so called "lead developer" of Bitcoin Cash even made a post in the censored cesspool r/bitcoin shitting on "BCash" (which is of course the word other toxic people have used to shit on Bitcoin Cash). https://www.reddit.com/r/Bitcoin/comments/95bi14/hillarious_creator_of_bcash_has_been_banned_from/
Now the toxicity and shitting on others have become popular again, with Bitcoin Cash developers resorting to rewriting history:
The same Bitcoin Unlimited who have supported big block scaling since before Bitcoin Cash, yet now Jonald says they never really supported Bitcoin Cash.
I think it's rich to say Peter is manipulative, when deadalnix himself voted for increasing the blocksize in Bitcoin Unlimited to 10TB, which he knows would be disastrous. And he has the gall to call someone else manipulative? https://www.bitcoinunlimited.info/voting/render/proposal_vote_result/7eb0ded0487a6593ac3976b63422294e1a84b209be1307c46f373489922212a0
Who the fuck puts up with this shit?
Apparently ftrader, who together with deadalnix created the first Bitcoin ABC client, have also had enough. https://www.reddit.com/r/BitcoinABC/comments/f2828g/im_resigning_as_a_moderator_of_rbitcoinabc/
And by the way, I would also call deadalnix incompetent. You see, this image that great developers are supposed to be socially incompetent is just a stupid myth. Because the reality of software development is that it's a social activity and being able collaborate with people who you don't like is included in the job description. This is *especially* true if you're a lead developer. If you can't do that then you're incompetent, even if you're somehow a programming god.
(I've also read the code that deadalnix has written, and he's not a programming god. Extremely few of us are.)
This is the reason I haven't contributed to Bitcoin or Bitcoin Cash. I've had enough toxicity from bosses, coworkers and clients to last a lifetime without engaging with these toxic-as-fuck developers prowling the cryptocurrency space.
The miner fund proposal
Moving on to the proposal. https://www.bitcoinabc.org/2020-02-15-miner-fund/
I've been looking at ZCash since it was launched and one of the big reasons I've never supported it (apart from the trusted setup) is that the development team takes a big chunk of the miner profit. In my mind this is so far from what Satoshi envisioned with Bitcoin and it's only what shitcoins who wanted to extract as much profit they can would do.
Well, now some people want to do the same with Bitcoin Cash. And what's more, they want to keep the funds to themselves and their close friends. Don't believe me? Then I invite you to play Sherlock Holmes with me for a bit.
The proposal will use a whitelist of approved projects:
By applying these selection criteria, a whitelist was arrived at consisting of addresses for a General Fund, Bitcoin ABC, Electron Cash, and BCHD.
Notice anything strange?
Let's back up a bit and see their criteria:
The whitelist of possible projects was selected according to the following criteria:
Must be common infrastructure, things that different products build on top of.
The project must provide a “Public Good”.
The project must use open source software licenses compatible with other projects in the Bitcoin Cash ecosystem.
The plan should prioritize projects that are in need of money.
The first words we're looking at is **was selected**. Who exactly selected these?
And their criteria seems oddly specific to me.
Must be common infrastructure, things that different products build on top of.
Electron Cash is a great project, but you might wonder why it's the only wallet implementation included. This line could serve as motivation to include Electron Cash while disqualifying others.
The project must provide a “Public Good”.
This is beautifully phrased as it allows them to disqualify any project they want, because it's so broad and can be interpreted anyway they like.
Maybe this is how the disqualified Bitcoin Verde? Or they just forgot about such a minor client implementation? (Who cares about the minority, am I right?)
The project must use open source software licenses compatible with other projects in the Bitcoin Cash ecosystem.
This was certainly selected to disqualify Flowee. Maybe they included this because Amaury hates Thomas who's developing Flowee?
(And I even think MIT is a better license, but that's entirely besides the point. It's still wrong to disqualify GPL based projects like this.)
The plan should prioritize projects that are in need of money.
And this is how they justify not having Bitcoin Unlimited on the list, whom also have come out against the proposal quite hard.
Another thing we can note is that all projects in the whitelist came out early in support of the proposal, and no project that's against the proposal was included...
Alright, that should be enough for us to conclude that ABC basically wants to reroute mining rewards to Amaury and his friends. And this is how Amaury justifies it:
If toxicity isn't enough, he's also got hubris as he's equating the entire success of Bitcoin Cash to Bitcoin ABC, and therefore he's got the right to the entire fund.
This isn't how decentralized development looks like and it's not a development landscape I would ever take part in.
To wrap it up
The problem of funding developers is very real, but BCH won't die of developer shortage if ABC fails to impose an on-chain tax. As an alternative Monero's Community Crowdfunding System is far superior, and is in line with Bitcoin's voluntary philosophy and it doesn't discriminate against minority projects. https://ccs.getmonero.org/
But the important point is that it's not the lack of funding that's scaring away developers such as myself, it's the unprofessionalism and toxicity of other developers that's the real problem. And it's time we as a community wakes up to this fact.
@noise
