How (not) to run a Bitcoin subreddit
Background
I wanted to reflect on the events of yesterday, March 22nd 2024 on /r/btc . It started out with u/althornton2462 returning from a longer hiatus and presumably being upset about seeing that George Donelly was banned from the subreddit. https://www.reddit.com/r/btc/ https://www.reddit.com/u/althornton2462
For context, the decision to ban him was, according to the mod team, originally made after a longer discussion and after the troubled history a George stirring up trouble in the community. Those who were there will remember that George almost tore us apart. Since the subreddit is traditionally very open even to dissenting opinions, the decision to ban him was surely not easily made, but making it as a group was certainly the right way to go.
In contrast, althornton2462 decided unilaterally to unban George without any prior discussion with the other mods. That alone should be ground for removal, which **u/ThomasZander** thankfully swiftly did. https://www.reddit.com/u/ThomasZander
After then failing to attempt to hijack /r/bitcoincash, althornton2462 used the resulting moderation changes and his removal as moderator of that subreddit as an argument that "full censorship" was happening in both subreddits. That is a pretty wild accusation in my mind, because we frequently observe posts about all kinds of Bitcoin variants without much drama, I can only think of George being a prominent banned person (for very good reasons). https://www.reddit.com/r/bitcoincash/ https://github.com/ShadowOfHarbringer/specimen0037_evidence
Apparently the censorship complaints found the ear of Roger Ver, who then decided to remove all moderators of /r/btc and to give althornton2462 moderation rights. I believe this was not done out of malice but because he is a strong advocate for freedom of speech. However it lead to the result that althornton2462 immediately using the newly given permissions to in turn add George as an additional moderator to /r/btc, again without any discussions or prior notice. This understandably caused an additional massive uproar after all the drama that had already happened beforehand. Luckily, George has since been removed as a moderator again and a poll was created requestion the removal of althornton2462 as a moderator. Please participate in it although it has no formal meaning yet. https://www.reddit.com/r/btc/ https://imgur.com/gHO4igM https://www.reddit.com/r/btc/comments/1bl0f9b/poll_should_ualthornton2462_step_downbe_removed/
Why althornton2462 has become unacceptable as a moderator https://www.reddit.com/u/althornton2462
I would argue that the original attempt to unban George in itself would be a forgivable mistake. Just like Roger acted out of the strong support of the freedom of speech value, we could give althornton2462 the benefit of the doubt that he did the same. Dissenting opinions can also strengthen a community and it seems like althornton2462 was not part of the original discussion about the ban of George. He might not have even been aware that this discussion occurred. He alluded to that being the case in his apology. https://old.reddit.com/r/btc/comments/1bkyu3f/adding_a_little_more_context_to_whats_going_on/
What is however irredeemable is making George a moderator. He is well known for being misleading, divisive and toxic in multiple of the communities he entered. A person with such a character should never be in any kind of leadership position. https://twitter.com/GeorgeDonnelly/status/1769432346363605320 https://dyor-crypto.fandom.com/wiki/Dash_(DASH)#Dash_Latam
Anyone who was here as long back as althornton2462 must have known that making George moderator is absolutely unacceptable for the BCH community. This also becomes clear because he dodged the question on who made George moderator despite being otherwise very active in that thread. Therefore the only reasonable explanation is that George and althornton2462 conspired to take over the subreddit(s) against the will of the community. https://www.reddit.com/r/btc/comments/1bl3ueo/all_of_the_old_mods_have_been_now_invited_back_to/kw2t9lk/
What should be done now
First, **althornton2462 should be removed from his moderator position in any BCH related subreddit**. Someone who acts this impulsively, unilaterally and against the clear wishes of his community, is unfit to be a moderator, even if no conspiracy had happened.
Then, **rules determining the tasks and responsibilities** for the moderators should be negotiated and agreed upon between the remaining moderators and Roger as the owner of the subreddit.
One of these rules should be a **voting system on critical decisions** like the banning of high profile people (as opposed to e.g. crypto scam advertisements) or adding and removing moderators. There should also be defined consequences if these rules are ignored, e.g. by someone unilaterally making changes to the moderator list.
There also should be a more **transparent way to document these decisions** so that Roger, who apparently is not very active these days, can follow the reasoning of the moderators. Freedom of speech is a good value to uphold but there should also be respect for the decisions by the people who spend every day with moderating the subreddit.
Finally, let's not forget that most of us share a common goal here: making BCH and crypto in general more popular and useable in the world.
Update 1:
Since posting this, althornton2462 has banned an outspoken dissenting user, Ill-Veterinarian599, under the guise of breaking Reddit TOS. Quite ironic for someone being so concerned about censorship. https://www.reddit.com/r/Bitcoincash/comments/1blci9w/ive_been_banned_from_rbtc_by_althornton2462/
Update 2:
Roger has reacted to the latest events and removed althornton2462 as a moderator. While this is good news, Roger's reply shows that making rash decisions to change an established system is a recipe for chaos, no matter how good the intentions are. https://old.reddit.com/r/btc/comments/1blgr0q/cant_you_guys_just_all_agree_to_allow_each_other/
The history of eCash and why it is a risky coin
I am writing this article to inform those who are investing into eCash with little to no knowledge about the background of eCash. Given the history, it is hard for me to be unbiased but I will nevertheless try to present the situation as neutral as possible.
How and why eCash was created
eCash is a fork from Bitcoin Cash today created by Amaury Séchet, one of the original Bitcoin Cash founders/developers. Forks happen if there is contention about important issues that cause the community to split.
While Amaury had been known to be stubborn and hard to work with in the past, the tipping point for the split was his unilateral attempt to implement a very unpopular feature into Bitcoin Cash without community or miner concensus: compulsory sharing of a part of the block reward with his company Bitcoin ABC.
This was controversial for multiple reasons
It encourages building of cartels between miners and development teams (e.g. kickbacks from the development team to the miners)
It encourages centralization because the proposal did not have an open mechanism to fund other Bitcoin Cash implementations
the money would go to an undefined legal entity with zero oversight, presumably completely in the hands of Amaury Séchet
it exposes the legal entity collecting and sharing these fees to governmental control, making it a single point of failure / coercion
In my article history, you will find more information about this from a time where we were still hoping to mend the bridges burned down by Amaury, for example:
https://read.cash/@ZakMcRofl/bringing-the-community-and-bitcoin-abc-back-together-d474f10c
Once it became obvious that Amaury would not back down, all other node development teams rejected the self-funding code changes he had made.
Bitcoin ABC (aka eCash) and community reaction after the chain split
As it became clear that Bitcoin ABC / eCash has no majority with the miners, they did minimal steps to avoid the ensuing chaos. No replay protection was added, causing transactions on the BCH network to be valid on the Bitcoin ABC chain we now know as eCash (to my knowledge this is still the case today). However, to their credit, they gave up the ticker BCH in favor of BCHA (now XEC) which at least prevented confusion on exchanges.
Today, almost all Bitcoin Cash developers, marketeers, users and supporters gave up on Bitcoin ABC/eCash side and remained with the BCH ticket and its decentralized method of development. Only a handful of developers is developing code supported by both blockchains because they are currently still fairly compatible on a code level, I would estimate that 99% of the community gave up on Bitcoin ABC/eCash.
Meanwhile, Bitcoin ABC took took almost 8 months to do a rebranding
Why you should be careful investing in eCash
In the last weeks, eCash has seen a major price increase. To be honest, the rise did not seem very organic because there were no major events like a new software feature or annoucement, nor was there any adoption. To my knowledge, not a single web shop accepts eCash. On reddit it was observed that there was a sudden increase of influencer posts about eCash shortly before the price boom: https://np.reddit.com/r/btc/comments/pily66/the_window_of_opportunity_to_still_get_04_bch_for/ https://www.reddit.com/r/btc/comments/pily66/the_window_of_opportunity_to_still_get_04_bch_for/
One could argue that a coin having a good marketing, even if it means buying positive messages from influencers, is not a reason against investing in a coin. Nevertheless you should be aware that an artifical rise in demand can very quickly turn into a downward spiral once the original boost fades.
So why do I think you should be careful with investing into eCash?
Here are my arguments:
No adoption - compared to BCH, BTC and ETH, eCash has zero adoption
No community except investors - if you read through https://np.reddit.com/r/ecash/ you will notice that there is almost no meaningful discussion on the merits of eCash. No annoucements of new adoption, no annoucement of new software innovations. Compare this to /r/btc or even /r/bitcoin. 90% of the posts are writting by confused people who invested into a coin without any idea why. https://www.reddit.com/r/ecash/
Too centralized. No alternative implementations of the node software exist and the incentives being centralized makes it unlikely that someone will make one
Difficult leadership. The person in charge, Amaury Séchet, has a track record of being hard to work with and not caring much about his own community.
Name/Trademark risk. The term eCash is registered by another company, this is a huge risk for any business adopting eCash in the future. https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:a7d6hx.2.4
Slow development speed and no resources. It took Bitcoin ABC 8 months to find a new name and rebrand to it. The global network council announced for January 2021 has still not happened 9 months later https://www.bitcoinabc.org/2020-08-27-global-network-council/
Non-organic "growth" could lead to quick fall of price
On the plus side, I only see their re-denomination by converting what used to be a BCHA satoshi into one XEC. It is an interesting experiment if the psychological effect of this will help the coin in the long term.
In summary, I personally would not invest into eCash today. At the current prices, I would recommend Amaury to convert his eCash holdings into USD in order to fund a multi-year development. Since they left the BCH world relatively peacefully, I have no quarrel with their team and wish them best of luck with their experiment.
Edit 2021-09-14 Changed the word "solo" to "unilateral" to clarify that Amaury did a small group of Bitcoin ABC employees.
Why Bitcoin Cash needs recurring payments and a roadmap that goes beyond protocol features
The world's most famous Porn site, Pornhub, has recently received some well-deserved bad press for not reacting properly when people upload illegal content to its site. As a reaction to this, major payment providers Mastercard and Visa banned Pornhub from using them as a payment option. They are following the example of the number one online payment service PayPal, who already made the same decision in 2019. https://www.nytimes.com/2020/12/04/opinion/sunday/pornhub-rape-trafficking.html https://arstechnica.com/tech-policy/2020/12/visa-and-mastercard-ban-pornhub-over-abusive-videos/ https://www.vice.com/en/article/d3abgv/paypal-pulls-out-of-pornhub-payments
This effectively destroys Pornhub's chances to keep their business alive in an already very difficult time. They certainly made big mistakes, but I am sure many will agree that they do not deserve to have to close shop over this.
Cryptocurrency to the rescue?
These news made me wonder why companies like Pornhub don't put more focus on supporting and advertising payments via cryptocurrencies like Bitcoin (BTC) or Bitcoin Cash (BCH) in the past. On first glance, there seems to be clear **benefits of paying with cryptocurrencies**:
**No chargeback risk:** PayPal and credit cards make it easy for customers to get their money back, e.g. if they claim to their angry wife that they totally didn't pay for a subscription
**Secret payments that don't show up:** I imagine most Pornhub subscribers do not want the charges visible on their bank or credit card statement. Paying with a cryptocurrency doesn't have this issue.
**Anonymous payments:** celebrities, politicians, pastors and paranoid users would probably refrain from subscribing using PayPal, bank transfers or credit cards anyways because they link the payment to their real name. Cryptocurrencies allow you to stay anonymous, some more so than others.
**Nobody can stop you from using it:** Migrating from a payment provider because your services were deemed negative for their reputation is very expensive. You may lose active subscriptions. With cryptocurrencies, you can receive payments without the need for a 3rd party.
On the flipside, **typical arguments against accepting cryptocurrency payments** are:
**lack of adoption:** while many people have heard of Bitcoin (BTC), not many use it yet. Even fewer have heard of **Bitcoin Cash**, which is arguably a major upgrade from Bitcoin while sticking to its original values.
**expensive fees:** the "biggest" cryptocurrencies Bitcoin (BTC) and Ethereum can have fees of up to $10 per transaction. This makes them unsuitable for most day-to-day payments like a $7.99 Pornhub subscription. It was the reason why the game store Steam stopped accepting Bitcoin in 2017. . https://steamcommunity.com/games/593110/announcements/detail/1464096684955433613
**they don't scale well enough:** For some reason many crypto developers think that companies are holding back from accepting crypto because their transaction capacity limit is too low.
The case for Bitcoin Cash
While some of these arguments are valid against other cryptocurrencies, I think that they would not stop us in convincing a company like Pornhub to build their business on **Bitcoin Cash**:
**User adoption will follow** if companies like Pornhub clearly maket the benefits of Bitcoin Cash.
**Bitcoin Cash has fixed the fee issue.** By increasing the size of the blocks storing the transaction whenever necessary, transactions only cost a cent. It is mostly held back by the bad reputation Bitcoin (BTC) has caused by keeping their blocks small intentionally.
**The scaling issue is a fallacy**. Companies understand that processing and storage gets cheaper every day and that today's artificial limits can easily be increased if the usage justifies it. Today, Bitcoin Cash is at 0.3% of its capacity (100KB average blocks out of 32MB possible) with proven easy steps to increase it much further (scalenet).
Why recurring payments are a must
When we think about increasing adoption today, too many people are focusing on protocol features. SLP, block size increase, pre-consensus and new OP codes for reversing the byte order are certainly nice implementation details but ultimately I highly doubt a potential business user would be asking for any of them. They obviously still have merit but they are not what is stopping Bitcoin Cash from taking over the world.
I believe that real businesses care much more about actual use cases like the ability to collect recurring payments. Getting a customer to perform a payment is hard enough once, but to do it monthly is pretty much impossible because people are lazy or forgetful. As a business, you want to convince the customer to enter his payment details once and then not to worry about it again for recurring payments if he enjoys your service.
That is the reason why so many companies offer "almost free" $1 trials. Once the payment method is established, the lazyness works in the company's favor: many people just keep the service running because canceling would take a few clicks and they might just use it again next month.
This is why the **Bitcoin Cash community must put recurring payments at the top of their priority list**. It would be a huge unique selling point for Bitcoin Cash. Large subscription companies like Amazon Prime, Netflix, Disney Plus, HBO Max etc. will never adopt cryptocurrencies without that capability. Neither will any gym or sports club or other companies charging monthly fees.
How do we build and fund it
The first step is writing down requirements for such a service. While I am not a crypto developer, I can write a rough first draft of what such a feature would require to be successful for a business perspective:
**No "top up" needed:** bank transfer work as long as you have money in the bank account. Credit card payments sometimes even work if you have no money in the account. Either way, as long as the user has funds in their wallet, the subscription payment should keep coming.
**No need to be online:** remember, companies want their users to forget about the service. If you need to launch your wallet or open a website for the next payment to be made, too many payments would be forgotten.
**Amounts to be paid can be specified in a real world currency** (probably requires what developers call an "oracle" for reliably converting the amount into BCH)
**The pre-Authorization should allow for amounts you don't have a balance for yet:** If you sign up for a service, they will not ask you how much money you have in your bank account. If you have it available or will add the funds later, the system should still work
**A change of rates after a given period** should be possible with pre-given consent. This is needed to allow for a free or cheaper first period followed by the full subscription.
**The feature must be widely available for users of that cryptocurrency:** if only some obscure wallets support such a feature, the company will have to do too much education. It must be something that users of this cryptocurrency get easily get familiar with.
Obviously, these requirements should be refined by talking to the right people at these companies, for example starting with Pornhub. Not only will this give invaluable feedback, they may also be interested in helping to build it or to at least use it once it is available.
Which leads us to the biggest challenge here: to actually build it. Someone has to transfer these requirements into a technical proposal that then has to be manifested in code. Jason Dreyzehner already wrote a detailed technical proposal called "CashChannels" that covers some of the listed requirements. He could start a flipstarter for it, or we could set a bounty for whoever implements the refined requirements and adopts the first major merchant. https://blog.bitjson.com/cashchannels-recurring-payments-for-bitcoin-cash-3b274fbfa6e2
Another path would be to get Roger Ver and Bitcoin.com to collaborate with Pornhub on such a feature. Surely they have a painful need and Roger's team is known to implement new ideas quickly.
We need to re-think how we think about roadmaps
When I originally came to these conclusions, I was wondering why this feature doesn't show up on the ABC roadmap. Surely it was not an original idea. By a quick google search I did find the CashChannels proposal mentioned above. But even as a daily visitor of /r/btc I had not come across this idea before. I think the reason is that **we still think too much of Bitcoin Cash as a protocol as opposed to a solution and an ecosystem**. Another indicator of this is how little the topics marketing and branding are discussed in the community or included in any roadmaps. We also don't talk enough with real businesses and try to understand their needs. Surely there are crypto supporters in these large companies that could tell us or internally ask what it would take to adopt Bitcoin Cash as a payment option. We need to reach them. https://www.reddit.com/r/btc/
I have a lot of work experience in tech companies. Releasing only a tech or feature roadmap like the one originally written by Bitcoin ABC is a bad idea if it is not derived from a company roadmap and vision that justifies it. In our case, that would be a community roadmap and community vision, which obviously is a bit harder to come up with in a collaborative way. I think Amaury never understood that part. Maybe he had a vision in his head, but he never shared it. We should not ask
1) "what do we build?"
Instead, the right process is:
1)"what do we want to accomplish?" (vision)
2) "what are the steps to accomplish that?" (marketing, branding, strategy, technology, features) and only then do
3) "how should the marketing look like", "how should our branding be", "how do we build the technology?", "which features do we implement first"
The good thing is that most other cryptocurrencies don't seem to have this either. At least none of the Bitcoin derivates. So it is a huge chance for us to overtake them if we find ways to discuss and decide upon these things in a collaborative manner.
I don't have all the answers. I have a very busy life already and even my time for writing articles like this is unfortunately quite limited. But I want to start a discussion. I want to encourage others to get involved in this process. If more people with a business background get involved, even if they just write articles and take part in discussions, I believe we can generate a lot of buzz and a lot of value together.
Will Bitcoin miners allow a rogue development team to steal their block rewards
Disclaimer
Even though the source of this event is the BCH community, its outcome will also affect all SHA-256-mined coins like Bitcoin BTC and Bitcoin SV. Please read this carefully even if you dislike BCH because it will affect all three communities.
Background
Bitcoin ABC, the node software historically used by many BCH miners, has decided to implement a controversial consensus rule that forces any BCH block to redirect 8% of the miner's reward to Bitcoin ABC. Blocks that do not redirect this fee will be orphaned by Bitcoin ABC nodes.
The collected funds are intended to fund Bitcoin ABC development and to provide seed funding BCH-related companies.
All other BCH node implementations as well as the vast majority of the BCH community is strongly against this unilateral, self-beneficial move. A team of independent developers has since copied Bitcoin ABC, removed the controversial fee and released the result under the name BCHN.
There will now be a battle on which side comes out as the majority on November 15th.
How does this affect BTC and BSV
The cost for ABC's funding would not be borne by BCH miners only. Due to the difficulty adjustment algorithm, every SHA-256 mined coin like BTC and BSV would pay.
Here's why:
On average, the SHA-256 hashpower generates a block of BTC, BSV and BCH every 10 minutes, which will give 6.25 of each coin to the SHA-256 miners. At current rates, this amounts to 6.25 x ($10673 + $163 + $227) = $69144.
If Bitcoin ABC should win, 8% of the BCH reward would be directed to them:
6.25 x $227 x 0.08 = $113.5 every 10 minutes, $6M per year.
The same amount of hash power would now generate $113.5 less revenue every 10 minutes.
Setting a dangerous precedent
Yes, that is "only" a loss of <0.2% of SHA-256 mining profitability today. Maybe that loss would be acceptable, especially from the perspective of the Bitcoin ABC team that would benefit from it. But the issue is that it sets a really dangerous precedent.
It touches a core coin distribution mechanism that all Bitcoin derivatives share: the coin reward belongs to the miners.
What if Bitcoin Core would suddenly introduce a similar rule for BTC? What if Bitcoin SV does? Who stops Bitcoin ABC from raising their fee to 20% later down the road?
Also, if the value ratio between BTC and BCH changes, this 0.2% could quickly grow.
So the question is: will BTC, BSV and BCH miners support development teams redirecting a portion of the block reward to themselves?
Call to action
I know that there is some animosity between the three mentioned cryptocurrencies. But I am hoping we can put them aside to fight this money grab.
Make all miners aware of what is going on by linking them to this article. Translate it to other languages and share it, you hereby have my permission.
If you are a miner:
Replace Bitcoin ABC with BCHN before November 15th
Talk to other SHA-256 miners, they will all be affected
Publicly state that you will put your hashpower against this move by Bitcoin ABC
Redirect hash power towards BCHN on November 15th to make your opinion heard
Follow the hash signaling on https://cash.coin.dance/blocks (currently 0% for Bitcoin ABC, 55% for BCHN, 45% undecided/neutral?)
Futher reading
For brevity, I left out a lot of the details surrounding this controversy.
Here is link to a collection of relevant articles:
https://read.cash/@ralak/archive-of-ifp-to-ifp-with-grasberg-and-assert-somewhere-in-middle-dc4f975c
And here are my previous articles:
https://read.cash/@ZakMcRofl/analysis-of-the-global-network-council-framework-ed307d5a
https://read.cash/@ZakMcRofl/how-bitcoin-cash-should-defend-against-the-hostile-takeover-attempt-by-rogue-developer-amaury-sechet-0e34ea08
https://read.cash/@ZakMcRofl/rogue-bitcoin-cash-developer-adds-contentious-code-attempting-to-syphon-8m-per-year-30697eb8
https://read.cash/@ZakMcRofl/create-a-bitcoin-abc-spin-off-now-a-developers-analysis-2c476e00
Analysis of "The Global Network Council framework"
Background
As you may know, Bitcoin ABC has changed their code to attempt to funnel 8% of all coinbase rewards into their control beginning November 15th. Since almost all other BCH community projects are rejecting this unilateral cash grab, this will result in a fork. In case the Bitcoin ABC chain survives this (currently 0% of miner blocks signal for ABC, 53% signal against ABC, 47% are still undecided), this will result in an BCH-ABC airdrop for all BCH holders.
Today, Bitcoin ABC has announced their rules for the previously announced governance model of their new fork. This article is an analysis of the announced rules. https://blog.bitcoinabc.org/2020/09/04/the-global-network-council-framework/ https://blog.bitcoinabc.org/2020/08/27/a-new-era-in-governance-for-bitcoin-cash/
Re: "Why is it needed"
Since it was created, Bitcoin Cash development has relied solely on donations. Part of the reason funding wasn’t sourced from the coinbase reward sooner was due to concerns over how the fund would be managed and distributed.
Unfortunately, this framework only covers how 50% of these funds will be managed and distributed. Bitcoin ABC can spend the remaining 50% with no restrictions.
Alignment with Bitcoin principles
The rules have a section attempting to consolidate this massive change with the original Bitcoin whitepaper.
"Bitcoin is a voluntary system."
This is correct. However, the fee payment demanded by Bitcoin ABC is not voluntary, it is mandatory. Today and on the future BCH chain, miners can voluntarily donate to any infrastructure of their choosing (or not at all).
"A Bitcoin network is made secure and stable by leveraging the economic incentives of participants. As stakeholders, members of the Global Network Council have a joint incentive to increase the coin price."
This may hold true for the coin holders and the miners that own many coins. It does not hold true for the developer. Even if you chose to do no improvements and the coin price stagnates, your income does not change. At $4 million per year, this is a pretty comfortable position.
The rules quote the whitepaper with
"The system is robust in its unstructured simplicity"
and then claim that
The Global Network Council is [...] designed to be a simple system
Falsehood 1: not simple, not unstructured, not robust
The proposed rules are neither simple, nor is the result unstructured, nor is it robust. The entire rule set is defined as a management structure for the new coin. With Bitcoin ABC as a fixed, central company in control of all the funds as a single point of failure.
Nakamoto Consensus is the foundation of Bitcoin. The Global Network Council itself is an extension of this consensus mechanism.
Falsehood 2: "is an extension of this consensus mechanism"
If Bitcoin ABC would follow Nakamoto Consensus, Bitcoin Cash would not exist in the first place. As unfortunate as it is, no BTC-derived coin can claim this for themselves. The ABC-created checkpoint system also undermines Nakamoto Consensus. Creating a minority fork and attempting to keep the ticker is also clearly against Nakamoto Consensus. To be clear, neither side of this fork should claim to follow Nakamoto Consensus, doing so would is hypocritical.
Falsehood 3: Ignoring other contradictions to the whitepaper
This section also conveniently ignores the section of the whitepaper this governance model is breaking: https://bitcoin.org/bitcoin.pdf
"By convention, the first transaction in a block is a special transaction that starts a new coin **owned by the creator of the block**. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, **since there is no central authority to issue them"**
The ABC rules remove **ownership** of 8% of this reward **from the creator of the block**. It also introduces a **central authority** that issues 8% of each block.
"If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins."
This is how Satoshi described an attacker. In the context of a fork/hash war, the behavior of the ABC client is effectively resulting in an attack similar to the one outlined by Satoshi. If a group of attackers with significant hash power rejects all blocks that do not pay them a fee, they can out-compete any honest miner. Obviously, this requires coordination between Bitcoin ABC and their favored miners but this is very easy to accomplish by ABC giving them kickbacks from their funds.
Stakeholders
Three co-equal categories of network participants can be proven, through the above principles, to be genuine stakeholders within the network.
Falsehood 4: "co-equal"
The stakeholders are not co-equal. Here are some of the inequalities:
Miners get 52 votes, Holders get 21 votes
Only the Bitcoin ABC presides over meetings
Only majority holders can present fund-seeking projects
Only Bitcoin ABC has control over the funds
Only miners and holders have to vote to allocate funds, Bitcoin ABC can freely spend 50%
Falsehood 5: "**Three co-equal categories of network participants can be proven**"
It is noteworth that only holders and miners have to provide cryptographical proof to gain a place at the table. Only they can be replaced. There is no mechanism outlined for the development team to be replaced. This is by design because the entire fund is not neutral, it is kept by Bitcoin ABC.
The word "Developers" should thus be replaced with Bitcoin ABC throughout the document.
Ignored stakeholders
The rules completely ignore a large amount of other stakeholders:
The top 21 BCH addresses only hold 13% of all coins. Assuming there are dual-ownerships, this would mean that 87% of all coin holders have no way to influence any decision.
In addition, other development teams have no method to obtain a place at the table. Again, this is by design.
Earning and casting votes
Holders can earn one of 21 holder votes by proving they are one of the top 21 coin holders.
This can easily be gamed. If I am the top coin holder, I can split my holdings into multiple sub-entities to gain more seats.
During the Global Network Council meeting, miners and holders will receive their voting token (or tokens) to the address they gave us when they applied to join the council.
Why is there a need for a meeting? There is no logical explanation for this requirement. It does however give massive power to the ones organizing this meeting because denying a party physical access is much easier than stopping them from using their vote token directly.
How do the funds get split?
Regarding the fund allocation, the rules say this:
"50% of the fund will finance the work done by the reference node development team, which is currently Bitcoin ABC"
Falsehood 6: "by the reference node"
A decentralized currency by definition does not have a "reference node". For the sake of this argument, let us assume we need to defined one. An objective definition would be "the node implementation that implements proposed changes first, with the rest of the ecosystem following their implementation."
Falsehood 7: "which is currently ABC"
Bitcoin ABC may be the first node to unilaterally implement self-funding code, but nobody in the Bitcoin Cash ecosystem is following their lead. Not a single node implementation, not a single wallet implementation. In addition, the only actual change in the November 15th, the new ASERT algorithm has been implemented into BCHN first, with Bitcoin ABC following them. Therefore, Bitcoin ABC is currently not the reference node of BCH.
Funding for other projects
Another goal of the fund is to finance other infrastructure-related projects (outside of the Bitcoin Cash roadmap) that will further improve the network and help drive adoption. 50% of the fund will finance these types of projects.
Note how this rules out other node development teams. If you work on the Bitcoin Cash roadmap, you cannot get funding. This way, competition on node development is never possible.
Academic projects, such as advanced research into pre-consensus models, are funded in the form of research grants.
Entrepreneurial projects are seed-stage ventures, funded within an incubator model similar to Y Combinator. Miners and holders will retain an equity stake in future profits, which will be sent to the same address as the coinbase reward.
This wording is very suspicious. Who would be giving out these "research grants" and who would be the owner of the resulting IP?
The incubator suggestion is even worse. Implementing this incubator model requires a legal entity. The only legal entity in this framework is Bitcoin ABC. In other words, Bitcoin ABC would hold a 7% stake and voting rights (see Y Combinator) in any entrepreneurial project funded by the miners and only very few companies would even be interested in making use of such funding.
This description of the incubator model is incredibly vague for something that sounds like a legal nightmare for miners, holders and the affected companies. https://www.ycombinator.com/faq/#q4
The two categories also somewhat rule out normal non-academic, non-entrepreneurial development work like marketing campaigns, other node implementations, libraries for using BCH etc.
No transparency, no audits, no reporting, no accountability for Bitcoin ABC
So far, I covered what is written in the framework. However it has some notable omissions.
The main concern with any IFP proposal is kickbacks. If Bitcoin ABC buys off miners by returning a part of the share they receive, they can effectively completely undermine this voting structure. And none of the votes affect how Bitcoin ABC spends the money.
There are also no indications of an audit or any kind of reporting structure for Bitcoin ABC. They can spend their 50% on whatever they please, Amaury can pay himself an insane salary and there is literally nothing in this framework to stop him.
There is also no way to replace Bitcoin ABC since they are in the center of everything. They run the incubator, they invite to the events, and they hold and distribute all the funds.
Summary
This framework outlines a Blockstream-like centralized development scheme for the Bitcoin ABC coin. None of the stakeholders can affect the Bitcoin Cash roadmap. There is no mechanism to monitor the spending by Bitcoin ABC or to change the amount of money they get. The choice of fundable projects is intentionally limited. The few funding methods for other project are structured to further increase the power of Bitcoin ABC. The vast majority of holders and users are completely ignored by this governance model.
It should be rejected outright by anybody who believes in liberty, decentralization and the principles of Bitcoin.
How Bitcoin Cash should defend against the hostile takeover attempt by rogue developer Amaury Séchet
Now the Bitcoin Cash community knows where it stands.
In the last weeks, many major pools mining BCH vowed to defend Bitcoin Cash against the attempted hostile takeover of its community by Bitcoin ABC developer Amaury Séchet by switching over to the mining software BCHN or other alternatives. https://read.cash/@ZakMcRofl/rogue-bitcoin-cash-developer-adds-contentious-code-attempting-to-syphon-8m-per-year-30697eb8
Today, ViaBTC announced that they would "stay neutral" in the upcoming November 15th battle between BCH and the new Bitcoin ABC coin. However, upon further inquiry they admitted that they would let their customers choose if they want to mine using BCHN or Bitcoin ABC, with Bitcoin ABC being the default. That's not really being neutral... https://twitter.com/yhaiyang/status/1297377355602653189 https://twitter.com/yhaiyang/status/1297424037279236096?s=21 https://twitter.com/Coinelius_BCH/status/1297428716650483717
Together with their sister company, Antpool, they represent around 30% of the BCH hashrate today. That is a minory but their implementation will make it very easy for BTC miners to temporariy use their hashrate against the BCH community. They would be acting against their own interests because they would effectively pay money to Bitcoin ABC forever if the IFP remains, but they might just do so out of spite.
To prevent a contentious November 15th fork, the community should now prepare its defense strategy. In this article I will propose some methods for discussion in the community.
1. Encourage miners to migrate from ViaBTC to other pools
We should make BTC and BCH miners aware that supporting ViaBTC (and maybe Antpool) means risking that their future profits will be reduced by the amount syphoned towards Bitcoin ABC. Staying on the ABC coin chain will also mean that they will likely lose all their mining profits by the time they can sell them in case the ABC chain loses.
ASICseer already showed how effective this can be. They issued a public user alert that resulted in their customer's hash power for ViaBTC fell from 50 petahash to 39 petahash within only 12 hours. https://www.reddit.com/r/btc/comments/ifd0s3/asicseer_is_advising_its_customers_to_move_off/
2. Educate businesses that a 70% majority of hashrate will move away from Bitcoin ABC
We need to educate businesses using Bitcoin Cash that they should replace Bitcoin ABC with BCHN in preparation for the upcoming upgrade. This will ensure that they stay on the majority chain.
3. Hold a coin vote
When the IFP was originally proposed, Bitcoin ABC claimed that it was requested by chinese miners. Once the community showed its universal disapproval, the chinese miners that presumably put the idea on the table quickly backed down from it and the proposal gained a 0% approval rate in the block vote.
This shows that the chinese miners care what the BCH community thinks about a proposal. Therefore, I propose that we should hold a coin vote regarding the future we want to see for Bitcoin Cash (IFP or Non-IFP). Every BCH gets one vote, results are tallied on a given day.
This would send a clear picture to them that the IFP is universally unpopular amongst coin holders.
While I do not have the skillset required to detail how such a vote would best be held, I believe it could be an important tool to judge community support for technical proposals, now and in the future.
4. Translate articles to chinese
As explained in the paragraph before, the chinese miners care about what the rest of the community thinks. But language can be a barrier. So we need to find a way to reach them better, for example by translating articles like this one to chinese.
5. Block other mining nodes from building upon Bitcoin ABC blocks
Currently, BCHN and other nodes would happily continue building upon blocks mined by Bitcoin ABC (including the 8% IFP fee). In the other direction, Bitcoin ABC would reject all blocks that do not send them money. This creates an unequal playing field.
To level the playing field, some community members (not developers) have suggested to outright blacklist the hardcoded Bitcoin ABC wallet address and rejecting transactions sending money to it or from it. This would however be problematic because it would demonstrate that Bitcoin Cash can blacklist addresses, a mechanism many governments and companies would be very interested in.
Others have pointed out that miners who disagree with developers stealing from the coinbase would likely manually reject any blocks that were mined using Bitcoin ABC. My proposal is to coordinate such an effort without forcing anyone to use it. Here is how it would work: all node developers would add the ability to load a list of "bad" blocks from a user chosen URL. If a block is on the list, the software would refuse to build upon it.
These lists would only be used in the event of an attack on the network. Miners would be free to use such a list or not, but it BCH is getting attacked, they may very well chose to. It could be a list maintained locally by their admin or some other entity that identifies hostile blocks.
This would allow nodes with shared interests to reject hostile attacks without touching the source code or manually rejecting blocks on every instance. This mechanism could not be used to enforce a transaction blacklist because there is no central authority maintaining these lists and it would not be economic for a miner to reject blocks based on some government blacklist.
Other ideas?
If you have more ideas on how we can have an easy transition in November, please let me know in the comments. I am also very curious to hear what you think about my suggestions.
Rogue Bitcoin Cash developer adds contentious code attempting to syphon $8m per year
TL;DR
If you are using Bitcoin ABC, you should migrate to BCHN (or others) before November because Bitcoin ABC will stop following the BCH blockchain if not every block contains a forced payment towards Bitcoin ABC.
Recent events
On August 15th 2020, Amaury Séchet, the lead developer of one of the Bitcoin Cash node implementations (Bitcoin ABC), has introduced code that will syphon 8% of miner's block rewards into ABC's pockets beginning November 15th 2020. Starting with version 0.22.0, Bitcoin ABC will reject and attempt to orphan all blocks that do not contain this forced Bitcoin ABC fee payment (let's call it AFP from here on out). https://github.com/Bitcoin-ABC/bitcoin-abc/commit/d2b040ab307f41d7bef72137e9efa1f1d64c7eb3
This selfish behaviour by a single node will likely lead to a soft fork because the rest of the Bitcoin Cash community interprets this as a unilateral attempt to change the consensus rules, effectively resulting in an attack on the network for personal gain. This is especially painful because for many years, Bitcoin ABC was considered a strong cornerstone for BCH's development and improvements.
However in the last few months Bitcoin ABC's lead developer Amaury Séchet has made many similar unilateral moves and made it clear that he does not care about the interests or opinions of the BCH community. A good write-up on these concerns was written by BCH developer Jonathan Toomim and many of its sentiments echoed by George Donnelly, who worked closely with Bitcoin ABC lead developer Amaury Séchet and has since left the organization: "Amaury is not an effective leader, period, full stop." https://www.youtube.com/watch?v=XjRQCUw4qII https://read.cash/@BigBlockIfTrue/this-conversation-was-marked-as-resolved-43b6ea7d https://read.cash/@jtoomim/dark-secrets-of-the-grasberg-daa-a9239fb6 https://read.cash/@georgedonnelly/a-manifesto-for-the-next-10-years-of-bitcoin-cash-1592813d#amaury-sechet-and-bitcoin-abc
Drop-In replacement and other alternatives
Luckily, people who still use Bitcoin ABC have many migration options because Bitcoin Cash is one of the few cryptocurrencies with node implementation diversity and real decentralization. The easiest migration is using the drop-in replacement Bitcoin Cash Node. It was derived from Bitcoin ABC and had its first release on February 27th 2020. It contains various improvements over Bitcoin ABC, most notably it does not contain the code enforcing the AFP. It is written and maintained by the team that spearheaded the development of the new difficulty adjustment algorithm ASERT which is the only change to make it into the scheduled BCH Update for November. https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node https://news.bitcoin.com/bch-devs-bitcoin-cash-node/
Other BCH software alternatives are BCHD, Bitcoin Unlimited, Bitcoin Verde, Flowee The Hub and knuth. https://bchd.cash/ https://www.bitcoinunlimited.info/download https://bitcoinverde.org/documentation/ https://flowee.org/hub/ https://github.com/k-nuth/kth
Miner position and risk to miners
As with any soft fork, it is relevant what the position of the miners is, so let's look at the early indications:
A similar funding proposal was universally rejected by miners in May, where no miners voted for the "Infrastructure Funding Plan". That plan at least pretended to include a chance of other parties being funded through it but was troubled with the same concerns (chance of corruption, kickbacks, centralized whitelist approval, lack of auditing, lack of accountability). It seems likely that the arguably worse ABC fee payment will be equally rejected.
Following the pre-announcement of the AFP, a group of notable BCH miners issued a statement that the majority of the BCH hash rate will not adopt the forced Bitcoin ABC fee payment. https://medium.com/bitcoin-abc/bitcoin-abcs-plan-for-the-november-2020-upgrade-65fb84c4348f https://read.cash/@asicseer/joint-statement-from-bch-miners-regarding-bitcoin-abc-and-the-november-2020-bch-upgrade-2cbdc38d
Another major player in the BCH-BSV hash war, Roger Ver's bitcoin.com, has released the following statement: https://read.cash/@Bitcoin.com/to-our-customers-regarding-the-bitcoin-cash-network-upgrade-in-november-47879f0f
Bitcoin.com is one such miner and for the record, we will not be mining with any Bitcoin Cash software that implements the IFP feature in the November 2020 network upgrade. At this time we also have reason to believe that most other miners have come to the same decision.
It is not clear yet if non-ABC node implementations will accept or reject blocks containing the AFP. But given this strong opposition, at least a manual rejection of such blocks through miners seems likely. In any case, if the majority of blocks is mined without payments to Bitcoin ABC, all other node implementations will follow that longer chain instead of the Bitcoin ABC chain that enforces AFP in every block.
This forces the companies and individuals mining Bitcoin Cash to act now. If they keep mining using Bitcoin ABC and thus paying the AFP, they risk that their block rewards will end up on the shorter chain. Since they cannot spend their block rewards for ~16 hours (100 blocks), chances are that the ABC chain will have already died out or lost all its value by the time they would be able to sell. Another indication of the value of the ABC coin is the futures market, that shows the Bitcoin ABC coins being worth only around $30, around 1/10th of the value of the BCH side . https://coinflex.com/markets/BCHABC-USD-201225-LIN https://coinflex.com/markets/BCH-USD-201225-LIN
In comparison, migrating to BCHN is a safe no-regret move because as it stands, BCHN will follow the longest chain (=BCH) no matter what happens.
Company positions and risks to companies
Various companies already have voiced their disagreement to the Bitcoin ABC fee payment scheme:
On the day of the AFP pre-announcement, the Token Exchange cryptophyl.com has stated on Twitter: https://cryptophyl.com/
"Today's announcement by Bitcoin ABC was not a proposal, it was an announcement. Their actions are not representative core values we and others expect and uphold within Bitcoin Cash." https://twitter.com/cryptophyl/status/1291350077416538113?s=19
The SLP foundation issued the following statement:
"We will support SLP infrastructure development on Bitcoin Cash, not on a fork of Bitcoin Cash by ABC." https://read.cash/@SLP-Foundation/simple-ledger-protocols-joint-statement-regarding-bitcoin-abc-on-bchs-november-2020-upgrade-8cb73564
The promising adoption and ease-of-development initiative mainnet.cash has stated on reddit that they will not support an ABC side if a fork happens. https://mainnet.cash/ https://www.reddit.com/r/btc/comments/i4y76a/warning_mainnet_will_support_bchnside_only_if_you/
General protocols , the company behind AnyHedge had already positioned against ABC's unilateral Grasberg announcement, today Company President John Nieri confirmed to me that his statement towards CoinFugazi was also representative of the company as a whole: https://generalprotocols.com/ https://anyhedge.com/ https://read.cash/@sha256_88ebd526/bitcoin-cash-bch-november-2020-upgrade-statement-f7c03159 https://read.cash/@CoinFugazi/bitcoin-abcs-8-play-for-bitcoin-cash-9a82d2bf
"The Bitcoin Cash (BCH) ecosystem has made it clear that it requires rational, well evidenced, well reviewed proposals. The only change that has met that bar for November 2020 is the aserti3-2d DAA algorithm. No other proposals have enough time to be considered. Pools and Exchanges are advised that the entire infrastructure of BCH will only support one chain in November, and that chain will have aserti3-2d DAA algorithm with no other major changes."
Roger Ver's company bitcoin.com similarly elaborated in their statement what they recommend other companies building on BCH to do: https://read.cash/@Bitcoin.com/to-our-customers-regarding-the-bitcoin-cash-network-upgrade-in-november-47879f0f
The reason Bitcoin.com is choosing to run software that does not implement IFP is that we do not observe that this feature is supported by what we see as a prerequisite governance model necessary to ensure that funding raised via its use is spent in furtherance of the vision of Bitcoin Cash that we freely associate with. Thus, we can neither risk our vision of peer-to-peer electronic cash nor the future value of our customers’ Bitcoin Cash by implementing IFP at this time. **Furthermore, we encourage all network participants who share our perspective to run only Bitcoin Cash software without IFP specifically during the November 2020 network upgrade.**
If you find further company statements (no matter what side they favor), please reply in the comments and I will add them here.
In conclusion:
**If you are a company using Bitcoin ABC, you should migrate to BCHN or other BCH implementations as soon as possible.** As it stands, they will follow the longest chain and will still be compatible to blocks built by Bitcoin ABC. If you stay with Bitcoin ABC, there is a very high risk of getting stranded on an outdated chain due to ABC rejecting every block that does not include the ABC fee payment.
Roger Ver's 3rd BCH anniversary keynote and his position on raising the block time
As part of the 3 year BCH anniversary event "BCH:Scaling the Globe: 2020 Bitcoin Cash Conference & ForkDay Celebration", Roger Ver gave a keynote speech. https://www.youtube.com/watch?v=ZIhQnfAk8AU
It is a 12 hour video and it was very easy to miss the speech within, so I decided to transcribe it and link to the direct timestamps.
In this keynote, Roger addresses the recent idea to raise the block time from 10 minutes to 11 and laid out his thoughts on it.
In summary, Roger is strongly against the block time change since there are no technical or business benefits to it. But I recommend reading or listening to the keynote in full. Below I will add my own interpretation of what was said.
The keynote starts at 7:27:07 , you will find the transcript with the relevant sections highlighted below. https://youtu.be/ZIhQnfAk8AU?t=26827
https://youtu.be/ZIhQnfAk8AU?t=26827
Roger Ver 3rd Keynote "The importance of developers" (Transcript by ZakMcRofl)
The title was supposed to be [...] the importance of developers, both business and software developers.
I've been in this cryptocurrency space for a while and I've noticed - not so much in the Bitcoin Cash community but mainly from that other Bitcoin community, a bunch of software developers mocking people who aren't software developers. But I think they're not seeing the big picture there.
Software developers are incredibly important. If there is nobody to write the software, the software won't exist and then people won't be able to use it. But the reverse is true as well. If there is nobody wanting to use the software, what was the point of the software?
So you need both business developers AND software developers. Where the business developers are so important is that they have - in broad generalizations - a much better sense and finger on the pulse of what it is that users actually want to be able to use in their daily life.
An example of this that we've seen in Bitcoin for a while is that you see a lot of these software developers say "Oh, it's easy to calculate the fee. Just look at the current state of the mempool, then you see what that is and what the other people are bidding in the mempool and then you see ok, what price do I need to pay in terms of Satoshis per byte and then you calculate, my transaction has 5 inputs so its going to be a little over a kilobyte, so that means I'm going to have to pay this many Satoshi times that many kilobyte and calculate it all out." For software developers, maybe sometimes that's fun or interesting for them. For the normal person that just wants to buy something on purse.io and save 20%, they don't want to have to deal with any of that. So we need the business developers to let the software developers know "Hey, you need to hide all of that complex stuff from the end user and focus on that software of thing".
**Or another example of this, and this is all supposed to be our happy celebration today but in the Bitcoin Cash community, we have recently seen some software developers talk about wanting to make up for previous drift in the issuance of Bitcoin Cash, so they want to have the block time changed from 10 minutes to 11 minutes for the next 5.5 years. As a software developer maybe that's fine or interesting or even fun, as a business developer that's a bad user experience you are causing, right? Now, the average block confirmation time is supposed to have been 10 minutes for the last 10+ years of Bitcoin, now suddenly it is going to be targeting 11 minutes. That means people are going to have to wait more than 10% longer for their transactions to be confirmed on average. That's detracting from the user experience. It's not a huge huge detraction but it's a detraction nonetheless and there is no benefit whatsoever I can see as both a user and a holder of Bitcoin Cash myself.**
**So I think that's an example where the business developer should let the software developer know: "Hey, you're developing something that the users don't care about and don't want and aren't interested in and it won't make a difference. We should be spending that time and effort and resources on developing things that users actually want, things like super fast, super cheap, super reliable confirmations for their transactions."**
**So I think there needs to be less animosity between the software developers and the business developers because it absolutely takes both. And if you don't have the software developers working and talking closely with the business developers, you're going to have the software developers building a product that the actual end users aren't going to care about or want to use at all.**
**So that's where I would really like to see more collaboration going on within the Bitcoin Cash community. Let's have the business developers talking with the software developers about what sort of things the users are actually going to want or the businesses are actually going to want or need. So the software developers can focus on those things rather than on intellectual experiments that may be interesting for some software developer but don't make the user experience better for Bitcoin Cash and the people that are actually trying to use it.**
So the main things that I see as problems on the Bitcoin Cash network: let's get rid of the 50 unconfirmed transaction chain limit, let's make the unconfirmed transactions as irreversible as we possibly can through whatever consensus method is the most useful for that. Those are the things that I think are holding Bitcoin Cash back the most.
And software developer tools too, as a business developer I want to see as many software developers building on top of Bitcoin Cash as possible, so the mainnet guys [..] (https://mainnet.cash/) are doing a fundraiser ( https://flipstarter.mainnet.cash/ ) for building a bunch of awesome software developer tools to make it even easier for the software developers to build their businesses on top of Bitcoin Cash. So you can go and donate over there, Bitcoin.com already put up 200 Bitcoin Cash to get thing's started towards the goal of 750 Bitcoin Cash. I think it's over 300-something Bitcoin Cash have been committed so far using Flipstarter.
And Flipstarter is another really cool tool that I am a fan of, if you haven't clicked around and looked how Flipstarter works, it is really amazing. Basically you can have people fundraise together but you don't have to give the money until you know that the target of the fundraising amount is going to be reached, otherwise you don't have to give anything at all. So that's a really cool way to fund public goods or public works projects, so I'm a big fan of that as well.
**I think I have summed up most of what I wanted to say in about 5 minutes there, long story short, let's make sure that the business developers and the software developers are working together and not against each other. Because that's how we can move the whole ecosystem forward because we need both business developers and software developers and if you only have one without the other you're going to be dead in the water. You need to have both and you need to have both of them working together as a team, not fighting with each other, not attacking each other. They need to be working together to build the products that the world wants to use.**
If people have questions or if George wants to elaborate on that as well from what he's seen being in the crypto space for a long, long time as well, I'd be happy to hear other people's thoughts as well or what other want to see in the space. What are the missing tools that people don't have yet, that they want to see built by both the business and the software developers.
Comment on the keynote by George Donnelly
George Donelley of Bitcoin ABC was moderating the event and gave the following comment after the keynote:
https://youtu.be/ZIhQnfAk8AU?t=27216
[...] I definitely think that overall in the crypto space the software guys rule the roost. You know, as a business guy it can be quite hard to get through to the guys who are actually making the software. I have seen a lot of projects where it's just a software guy sitting in his basement or something, just coding stuff up, not even a point of contact with the outside world to see if it's needed or if the UX is on, or any kind of systematic approach.
Follow up plea from the Q&A session
Following the keynote was a Q&A session where Roger gives away some BCH, talks about adoption, suggests Darknet markets to make an IPI with SLP tokens and explains what he would want to see happen in the next year.
Then, this question from the audience came up:
"What do you think of building DeFi on Bitcoin Cash?"
In his response, Roger further explained his position towards the block time change proposal:
Yes, yes and more yes. Go and take a look at the general protocols guys, they are working on exactly that. I think that's another really big deal that people don't fully appreciate, that all of this is coming to Bitcoin Cash as well. So check out generalprotocols.com. They are working on exactly that for Bitcoin Cash and I am really really excited about that. Actually the other site that you may be already familiar with, George, is anyhedge.com and that's their product as well. Can't wait for those guys to launch.
Although they reached out to me recently "Please don't change the targeted block time from something other than 10 minutes." Because that screws up all sorts of the stuff that apparently these guys are working on. There's no advantage that I can see any business being in favor of, making the block time go from 10 minutes on average to targeting 11 minutes on average. And there's lots of minor inconveniences that I'm aware of and maybe some major inconveniences to people that are trying to build. So please don't change that.
From one business developer a request to the software developers: there should be a really strong business or technical reason to change it from 10 to 11 minutes. I am not aware of one, I haven't heard one. I have watched all the videos about it with the discussions recently. Please don't change the targeted Bitcoin block time from 10 minutes to 11 minutes. It certainly shouldn't be a longer than 10 minutes block time. If you want to change it from 10 minutes to something shorter, I think that's a discussion very well worth having. I can't see any benefit to making it longer, there isn't one that I am aware of or that I can see.
Here is the timestamp in the video:
https://youtu.be/ZIhQnfAk8AU?t=28182
Commentary / Interpretation
I want to close this article with my thoughts on the keynote and the interaction.
First I want to applaud Bitcoin ABC for inviting Roger and allowing him to give a keynote that is strongly critical of their developer's recent actions. This openess gives me hope that their mindset is changing, at least on the business side of things.
I find it remarkable how Roger phrased his criticism and tried to make it constructive: he calmly and with strong arguments explained to his business development counterpart George, that the actions taken by the software developers at Bitcoin ABC need to get a strong reality check from the business developers (both inside Bitcoin ABC and outside of it). My personal hope is that George reflects on these words and tries to convice Amaury that raising the block time is bad for the user experience and bad for the public perception of the coin.
However the response by George is a bit concerning. If he really feels like the software developers (read: Amaury) are the ones in charge of the decision making, that would be de facto capitulation in his role of business developer for Bitcoin ABC. [Update: George has reached out to me in the comments so I want to quote him here: "Try not to read too much into what I said. When I made those comments, I was thinking primarily, tho not exclusively, of my experience with Dash. It is important tho to not simply permit software guys to rule business guys. There has to be some parity there, with both points of view harmonized."/Update]
From my personal experience in having worked a lot in this dynamic between software developers and business developers, I learned that the reality checks Roger mentions are very healthy and required to be successful as a team. If only the coders dictate what gets coded, chances are that they lose sight of what the users and the business needs. If a business developer cannot influence the direction into which the business develops, why is he still in that business?
Since I want nothing more than BCH to succeed, I hope that George will listen to Roger's advice and collaborate more strongly with Amaury regarding what users and businesses need. He is in a unique position that could help us unite the Bitcoin Cash community as a voice of cooler heads within Bitcoin ABC.
A non-technical analysis of ASERT vs Grasberg
ftrader wrote an article comparing the technical aspects of ASSERT vs Grasberg.
While I agree with most of the technical arguments presented, the even bigger problem is the leadership failure demonstrated by Amaury and by extension Bitcoin ABC:
Failure 1: No pre-decision communication, acting in bad faith
Amaury did not propose this DAA in the last developer meeting in which he already said it was late for adding new ideas for the November update
A good leader should not be so bad in communicating and should not participate in technical discussions in bad faith (withholding their ideas)
Failure 2: Dishonesty
Amaury mischaracterized the situation and claimed that no proper proposal was on the table despite this being discussed for weeks now, including with him.
A good leader should not be dishonest to further his agenda or to satisfy his own ego
Failure 3: No recognition of well prepared contributions
Amaury voiced no notable concerns against JToomim's proposal, so accepting it would have been an easy home run in terms of healing our community from the damage ABC has caused with their IFP behaviour -
A good leader would encourage others to contribute, not reject their ideas in order to trump them with his own implementation in the last minute.
Failure 4: Unilateral decision making
Instead of presenting his ideas as a counter-proposal to the community, Amaury immediately said "Bitcoin ABC is therefore moving forward with the Grasberg DAA"
A good leader would aim to bring everyone to the table and convince them of the merits of his ideas, he would not unilaterally decide such important changes.
Failure 5: No follow up communication
Following the announcement, Amaury and George Donnelly have done no attempts to discuss their decision with the community, neither from a technical nor from a decision process perspective. Instead, the community is left to itself to interpret and speculate by such a puzzling decision has been reached at Bitcoin ABC
A good leader would understand that this proposal is controversial and do his best to defend it in the community
Previous instances of similar behaviour
It is not the first time that Amaury has shown such significant leadership failures. In fact, in during the IFP events I wrote an open letter to Amaury outlining many of the same observations:
But I know that in your mind, you think that are doing the right thing for Bitcoin Cash's future. After all, you were there since its inception and a big part of its early success. Now, you feel that without being paid proper salaries, you and maybe some of your team cannot continue working on Bitcoin Cash full time. Unfortunately, the way you are trying to accomplish this funding is leaving you with **very little support in this community**. **Trying to ram through unfinished, unreflected major changes** to Bitcoin Cash's consensus rules is not the Bitcoin way. Neither is **disregarding community feedback**, **not consulting with other client implementations**, **not offering any transparency** regarding the unknown company that is supposed to get funded and not offering a plan for the usage of the collected funds.
(Source: https://read.cash/@ZakMcRofl/building-bridges-an-open-letter-to-amaury-sechet-66b63780 )
Summary
Overall, I think these failures in leadership are much more concerning than making a non-optimal technical decision. Even if Grasberg had technical merits over ASERT (in my opinion it doesn't), introducing it this way is hugely damaging to the ecosystem.
We should reject a leadership is not only incapable of uniting the community but also seemingly unwilling to do so.
The motivation for developing Bitcoin Cash
When watching the Bitcoin ABC live stream from Juli 3rd, a statement by Amaury Séchet brought me closer to understanding the current conflicts in the Bitcoin Cash scene.
Should the people that work most on BCH get "the richest" over time?
Here is the relevant quote with context:
If I put myself in the shoes of a VC [venture capitalist] and I'm gonna talk to someone that is building something on top of BCH, well my first question is gonna be "Why BCH rather than some other project"? And the thing that is going to come back to me as a VC is that this is an external risk because things are being built on an infrastructure that is funded on a shoestring. And VCs - you know the community may not be aware of those number I just talked about - but VCs this is what they look at and they are very good at evaluating this kind of stuff, this is their core business. So they're gonna see well, you know this is a community that is funding it's infra[structure] to the order of 500k a year and they consider that a great success. This is like a big red flag for stuff that VC's specifically care about and that's a bit of an issue I think and that's probably one of the reason it's difficult, right? Because really you don't want to be like you know "oh we need to fund the products, oh no we need to fund the infrastructure".
The reality is that you need to fund both because both depend on each other. And if you don't fund both then - you know - the thing is just not going to work. So if you have limited resources needed to fund those two stuff and those both are pretty expensive if you want to make that happen at scale, then we need to get smart and find [a] creative way to get the money in.
Because the way it's happening right now it's just not going to work. **The only thing that it's gonna achieve is that it's gonna bankrupt the people that believe the most in BCH which is exactly what you don't want. A successful system would do the exact opposite, would ensure that the people that support it the most get richest over time, you know, richer or get the richest over time**.
And right now this is not what's happening and so **the incentives are just not aligned** and it's not bringing it enough money to succeed with the objective that that we set for ourselves and we need to be very honest with that. Because VC are going to be very honest with that, VC's they don't invest in ideology, they invest in businesses and are gonna look at all the numbers especially the financial numbers and do the calculation based on that.
Please watch the statement in full context, here is a link to the full video at the corresponding timestamp:
https://youtu.be/tiZw6fXLW-s?t=4231
The bold parts of this statement reveals how Amaury feels about the ABC position. He feels that if you believe in BCH the most, you should get "the richest" from it. And nobody from the ABC team showed any concern with that statement.
Bitcoin was not invented to be a get rich scheme for its developers. It does give rewards to the miners for the mining infrastructure and power consumption, but there was never a reward model for the programmers. I think this was by intention because there are many striving open source projects that do not have a build in reward structure. This is only temping because unlike Firefox, OpenOffice and the Linux Kernel, we are dealing with writing code for generating virtual money. This makes it very tempting to put your hand in the cookie jar.
Reminders of the Bitcoin Core corruption
The attitude that you should get rich from coding "your" cryptocurrency is unfortunately very human and very widespread in other Cryptocurrencies. However, I believe it goes contrary to why many (most?) signed up for Bitcoin Cash. Bitcoin Cash was born out of the frustration and fear of Blockstream intentionally crippling BTC for their own gain by keeping the blocks small and thus pushing people into more monitizable layer 2 alternatives like Lightning Network and more recently Liquid.
The idealists that believed in keeping Bitcoin available to everyone and usable by everyone in the world, left in hope of a better, less centralized future with Bitcoin Cash. Personally, I was always hoping that the motivation of people like Amaury stems from this idealismn, wanting to create a better world and a better currency, not enriching himself.
Watching Bitcoin ABCs unilateral behaviour during and after the IFP events reminded many of the corruption they had to witness in the Bitcoin Core ecosystem: Improvement ideas are not judged on their technical merit but on what best benefits the bottom line of the company.
Personal enrichment goals explain past behaviour
Amaury's "confession" in the livestream helps us fill in the gaps of previous concerning behaviour over the last months. Why is Bitcoin ABC so secretive about its legal entity? Why does Bitcoin ABC not want to share how many full time equivalents they have? If your agenda is to enrich yourself based on community donations or miner fees, the last thing you would want to disclose is how much money you reserve for yourselves in your business plan. https://medium.com/bitcoin-abc/bitcoin-abc-may-2020-transparency-report-b213fc588463
It also explains why the funding requested by Bitcoin ABC is so much higher than all the other Bitcoin Cash projects combined. It seems like it is not just about putting food on the table and a roof over your head. Maybe the entitlement to become "the richest" found its way into these numbers.
For me, it also sheds some light on the history of the IFP. I never believed that sheepish line that "we just put a miner's idea into the code". The way it was implemented, the IFP would have been a great way to ensure personal wealth to everyone who has their name on the whitelist, without having to answer to the community's demands for transparency.
The way it was drafted and the benefiting parties were chosen should be seen even more sceptically after this confession.
What does this mean for Bitcoin Cash
I think our community is at a crossroads. We need to decide if we are ok with having a leading implementation team that strives for profit above ideology. If we choose a business to lead us, we cannot really complain if that business and its managers strive for profit instead of putting the community's wants first. If their money runs out, they will try to push ideas like the IFP again.
The alternative is building an ecosystem where the value comes from the applications and projects building on top of BCH. Linux is a great example how this can work. It was built by thousands of people contributing for free or as part of their daily work in Linux-related companies. They build up a massive ecosystem with big players like Intel, Red Hat, Samsung and IBM profiting so much from it that they now hire full time developers to work on making Linux even better.
I believe this approach could work for Bitcoin Cash, but it will likely not make anybody rich in a while. People like Amaury might leave for more lucrative engagements if they do not believe the incentives are sufficient and we would have to offset this loss of manpower with a more positive, collaborative approach to coding that motivates more people to work without getting rich from it directly.
Edit history:
2020-07-05 19:12 UTC: Added more context of discussion before the quote
Bringing the community and Bitcoin ABC back together
There currently is an ongoing discussion about "Is there an anti-ABC mob" on twitter and reddit. I think the more important question is not if, but why many in the community concerned with the way Bitcoin ABC is operating. This article is aiming to be an updated collection of valid arguments and critical observations regarding the behaviour of Bitcoin ABC in the last months.
The goal is to help ABC better understand where the critizism is coming from and hopefully finding a way to come back together and compromise.
Reason 1: Refusal to take responsibility, to apologize and to remove the IFP code
The IFP in the current form has been almost universally rejected by the community and the miners. The code in question cannot even activate anymore because the ntimeout of May 15th has passed for more than a month now. There is absolutely no reason to keep it in the code yet 3 new versions have been released that all include it. Removing the code would be a very easy gesture to aim for unity for the community. https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57
ABC has not explained why the code is still there. It should be in their best interest to remove it for community goodwill and better funding chances. The fact that they keep it in is an indicator that they want to reactivate the implementation at some point.
Here is a recent thread that demonstrates that Amaury has no understanding of the consequences of his actions during the IFP introduction and the results of not removing the IFP: https://np.reddit.com/r/btc/comments/h8ieri/developer_activity_around_tron_eos_and_bitcoin/futwwfj/
*If the divide was about the IFP, it would have died down now that the IFP did not pass. Yet it hasn't. Unfortunately, by the time this is self evident, I expect we'll have lost a ton of value again, unfortunately.*
He understands that this was not just about funding development using coinbase rewards yet he completely fails to recognize the damage his own choices and ABC's choices have done. He and ABC were the ones who:
brought the IFP code into production releases with no way to vote against the IFP
Made up criteria for the whitelist that ruled out other major players in the community (source) https://www.bitcoinabc.org/2020-02-15-miner-fund/
Implemented the IFP in a way that to only allows ABC to decide who gets on the whitelist (ABC rejects all addresses except the ones hard coded in its own source code)
ignored glaringly obvious game theory / kickback problems before making such a major change (https://read.cash/@noise/the-ifp-and-unhealthy-incentives-a382fb01)
added an unknown legal entity with no accountability concept to the whitelist (how does the money get spent, control mechanisms for the miner fund)
did not push for transparency before implementing the miner's plan (who does the miner fund adress belong to? how to check for kickbacks? what do the recipients do with the money?)
gave the coin owners and the community no control or input over where the money should go
intended no funding for BCHN or BU or other projects except BCHD and Electron Cash (who didn't even require more than $100k in funding)
Yet he claims that:
*Goodwill assumes that somehow we did something wrong by putting something to vote.* ***We did not****, and the only people who will disagree with this are the people who want their scream to speak louder than actual verifiable stake in the system.*
Screaming loudly is considered bad form but it doesn't make the shouted argument wrong. ABC did many things wrong and the fact that Amaury doesn't recognize and acknoledge that is why we are still having division.
As a side note, I find it very dishonest from him to pretend that ABC merely put a random miner request to a vote that they had nothing to do with. They openly admitted to being involved at least in the 5% revision of the IFP and it is very inplausible that the miners just got the original idea without any discussions with ABC. Clearly Amaury and ABC had a strong conflict of interest that should have given him pause for consideration. https://www.bitcoinabc.org/2020-02-15-miner-fund/
His original implementation demonstrates that he was willing to accept an unpolished, critically flawed and thus damaging proposal into the project against the better judgement of almost the entire community.
Reason 2: General lack of transparency
When you ask for community funding, you should be willing to disclose how you spend it to that community. While ABC recently started doing transparency reports (thank you!), they omit information that is very vital: to which people would the proposed $3.3 million funding go and in what proportion. How many people do they intend to hire? What is the legal entity behind Bitcoin ABC? How is the ownership and governance of said legal entity? https://medium.com/bitcoin-abc/bitcoin-abc-may-2020-transparency-report-b213fc588463
In this comment thread they refuse to answer how many of the 8 people mentioned in that report are working in Bitcoin ABC full time and what legal entity is behind it. George claims that answering this question would compromise a team member's privacy. Even after reflecting on this for a longer period of time, I cannot understand how this claim can possibly be true. https://medium.com/bitcoin-abc/bitcoin-abc-may-2020-transparency-report-b213fc588463
Reason 3: Intransparent salary structure
This point is an opinion of mine and I am not sure how much support it has in the community. For the sake of the argument, the amount of support it has should not matter anyways.
May's transparency report lists the amount of salaries for the month as around 70546.17 + 120.78 BCH. Assuming a price of $220 per BCH (source) that comes out at $97117.77. Using these assumptions and the information that 8 people work for Bitcoin ABC, the average salary spending per employee at Bitcoin ABC is $12,140 per month or ~$145k per year. https://medium.com/bitcoin-abc/bitcoin-abc-may-2020-transparency-report-b213fc588463 https://www.statista.com/statistics/807070/bitcoin-cash-price/
In reality it could be higher because ABC is not willing to disclose how many of the 8 only work on the project part time (the Full Time Equivalent number would give that indication). These salaries may be totally justified depending on the degrees, profiles and countries of the employees, but we have no way of reviewing that because we only know 4 of 8 names (Georg Donnelly, Amaury Séchet, Antony Zegers and Jason B. Cox) and nothing about the salary split. When asking the community (or a VC) to invest $3.3 million in your team, there should be much more transparency about your salary structure. https://medium.com/bitcoin-abc/bitcoin-abc-may-2020-transparency-report-b213fc588463
Finally I would like to point out that many successful open source and crypto projects can operate just fine without directly paying salaries in that magnitude to its contributors (corporate sponsoring, ethusiasts who develop in their spare time).
Reason 4: Unwillingness to debate and find compromise
In a reddit post from April, Amaury Séchet of Bitcoin ABC has stated that he does not see the need for a governance mechanism for BCH: https://np.reddit.com/r/btc/comments/g2ff4h/fun_question_for_the_abc/fnluzh7/?context=3
*If you think that BCH needs to experiment governance mechanism by making decision via X or Y, then what you want is not BCH. It is tezos, maybe, or something else. BCH is about digictal cash. It already has a roadmap. This is BCH.*
I think this argument is flawed because you will always have decisions arise that you didn't put on any roadmap a few years back. Also how do you decide on the original roadmap in the fist place if not using debate, compromise and social consensus.
In the same post, he states
*It is okay to disagree with the roadmap. If you think another plan is better, then the best is to execute on that other plan on its own coin.*
The IFP was not on the agreed upon roadmap, yet ABC included it without searching for new social consensus, almost resulting in a split. By Amaury's own logic, he should have executed that plan on his own new coin.
Also the example used in the article is very telling:
*they then end up wandering 40 years in the desert and almost all of them die in terrible conditions. Because they spent all their time debating where they need to go and how and why instead of actually takeing the steps required to go there.*
*Right now, we are wandering in the desert. This will continue for as long as we don't get our shit together and execute on the roadmap.*
I feel like this comparison is a admission of his own ability to find compromise. Yes, debate takes time and finding consensus by compromising is not easy. But there is a lot of value in consensus:
more people to work on the agreed goals
less risk of splits
less time wasted on implementing features like the IFP that don't find community consensus later
less time wasted defending a roadmap the community feels little involvement in
less stress for everyone involved
Successful leaders try to listen to valid arguments, they unite and try to find compromise within their ecosystem. There is a reason why people prefer living in a democracy over living in a dictatorship.
A constructive way forward
I don't want to leave this article as a wall of complaints without suggesting a contructive path forward that would - in my opinion - bring us back together and help BCH grow.
Bitcoin ABC should **remove the IFP code**
Amaury Séchet should reflect on the way he introduced the IFP, **take responsibilty** (even if the original proposal really came just from the miners) and apologize if he (hopefully) sees that he has had are part in the damage it caused. An apology from the miner(s) who presumably pushed for an immediate implementation of this unfinished concept would also be helpful
We should all **embrace that a decentralized development model of multiple node implementations holds value** compared to trying to go alone
The community should **brainstorm for mechanisms of finding BCH ecosystem concensus** (e.g. a voting mechanism by coin holdings)
All node projects should hold a public meeting together for discussing which of the proposed mechanisms to implement and publish a **joint statement that they accept that this will be the social concensus method** for proposing and accepting new features going forward
It would be a great catalyst if we would **test drive the new consensus method by finding a common color for our coin** as discussed in this thread with George Donnelly https://np.reddit.com/r/btc/comments/hc1o5d/community_request_which_green_shade_shall_we/fvfes0t/
Additionally addressing the transparency issues mentioned above, might further help Bitcoin ABC with its funding challenges.
Building bridges - An Open Letter to Amaury Séchet
Dear Amaury,
In the past week, a lot of things have happened and I want to try to build bridges instead of burning them down.
Many people, including myself, have accused you of being a malicious force in the Bitcoin Cash community in the way you have pushed forward with the IFP. https://read.cash/@NilacTheGrim/regarding-the-ifp-004f1d5c https://read.cash/@ZakMcRofl/create-a-bitcoin-abc-spin-off-now-a-developers-analysis-2c476e00
But I know that in your mind, you think that are doing the right thing for Bitcoin Cash's future. After all, you were there since its inception and a big part of its early success. Now, you feel that without being paid proper salaries, you and maybe some of your team cannot continue working on Bitcoin Cash full time. Unfortunately, the way you are trying to accomplish this funding is leaving you with very little support in this community. Trying to ram through unfinished, unreflected major changes to Bitcoin Cash's consensus rules is not the Bitcoin way. Neither is disregarding community feedback, not consulting with other client implementations, not offering any transparency regarding the unknown company that is supposed to get funded and not offering a plan for the usage of the collected funds.
Your clearly are a brilliant developer. But like many strong developers, you have a lot to learn in terms of social and leadership skills. That's ok, nobody can be a genius in all disciplines. The problem is that you are trying to solve a people problem with a technical solution and you don't seem to understand that people are what makes a project successful, not funding. If the community is so alarmed by your behaviour that within a few days a new ABC fork is created, it is clear that the community is rejecting having a self-proclaimed "benevolent dictator" as its leader.
Here is what I suggest: Motivate the right people and they will find easier ways to get you the funding you are looking for. Search for somebody you can trust who can motivate and inspire people. Somebody respected by the community. Let him or her be the project lead, let others do the team building, the governance, the marketing and the business development. Use your amazing talent to focus on coming up with new technical solutions to the challenges we face regarding scaling and adoption. The community will love you and embrace you for it and you will surely regain the respect that currently seems lost.
Bitcoin Cash does not need dictators, even if they are benevolent, it needs a ecosystem with positivity and many different teams working together in harmony.
In closing, I want to thank you for making Bitcoin Cash so great. For making it something worth fighting for. Please come back to the light side.
Regards, ZakMcRofl
Create a Bitcoin ABC spin-off now - A developer's analysis
*Disclaimer: This article is calling for an unofficial software modification of the Bitcoin ABC software. In the developer world, the process of making a modified copy of an open source project is also called "forking". This is very different from a coin/network fork which we should prevent at all costs.*
Today Bitcoin ABC released version 0.21 which includes support for Amaury Séchet's Infrastructure Fund Plan.
It forces miners to give 5% of all block rewards and fees to Amaury or projects hand picked by him or to an unknown "General fund", presumably a Hong Kong company.
A lot of articles have been written about why this is a bad idea, today I want to highlight the way this was implemented in a very deceitful way.
While Amaury claims that he was only implementing wishes from an unknown miner, there are multiple concerns with the way it was chosen to be implemented:
No Time Limit
Nothing in the implementation has a time limit on the funding period for the IFP. It is unlimited until Amaury decides to release a new version that disables it and thus stops funding to himself.
*A non-malicious developer would code an automatic end to the IFP, at the very least to make the intention of removal in the next version clear.*
Modified BIP-9 Threshold
The article ABC posted , ~~the one presumably agreed upon with BCHD,~~ lists BIP-9 as the method of decision. BIP-9 is a concensus method that specifies a threshold of 95% agreement to prevent a chain split due to contention. In the actual implementation however, a lower threshold of 66% has been implemented. It becomes obvious how misleading this is if even the whitelisted BCHD lead developer Chris Pacia ~~who was presumably involved in the planning~~ was surprised to learn that the implementation only requires 66% agreement instead of 95%. https://www.bitcoinabc.org/2020-02-15-miner-fund/ https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R114 https://www.reddit.com/r/btc/comments/f4mkge/as_it_stands_now_bitcoincom_will_not_go_through/fhrvtl4/
*A non-malicious developer would stick to the the specification of a well thought out proposal in order to find out if there is enough agreement for a proposal to prevent a chain split.*
Hardcoded Whitelist
ABC has unilaterally decided which hard coded wallet addresses are allowed to benefit from taxation:
Their own (does anyone know which individuals have ultimate control over it and how funds will be split amongst ABC developers?)
Electron Cash (despite its lead developer Jonald Fyookball withdrawing his support for the IFP in its current form and asking for removal from the whitelist here ) https://read.cash/@jonald_fyookball/latest-thoughts-on-infrastructure-mining-plan-681269b7#comment-64634b6f
BCHD (their lead developer Chris Pacia was expecting the proposal to require 95% BIP-9 consensus, not 66% ) https://www.reddit.com/r/btc/comments/f4mkge/as_it_stands_now_bitcoincom_will_not_go_through/fhrvtl4/
a "General Fund" - an unknown, unmonitored and non-transparent entity, presumably a Hong Kong company with an unknown shareholder structure, unknown management, unknown rules, unknown intentions
Corresponding source code is here . https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57#diff-5c20e210ed453866a3bf7cca3c5e792eR20
Notably, other valuable open source projects like Bitcoin Unlimited, Bitcoin Verde, bitcoin.com wallet and many others have been omitted from this list. There is no way to get them on this list unless Amaury decides to include them.
*A non-malicious developer would not hard code their own wallet address in this way. A non-malicious developer would search consensus on the list first and then implement it in a way that can be easily accessed by other implementations and updated to include new projects. A non-malicious developer would not add any entry to this list that is not community reviewed (General Fund).*
Misleading Parameter Name
They introduced a new parameter called enableminerfund. This name is very misleading because this parameter is not required at all to enable the miner fund. If it is omitted, the fund still gets activated and blocks without taxation get ignored after modified BIP-9 activation. You have to call bitcoind with -enableminerfund 0 in order to get it to accept blocks without taxation (after modified BIP9 activation).
Hiding the Parameter
Unlike most other parameters, the parameter was added as a hidden parameter. This means it will not show up if you call bitcoind with --help and there is no way to find it unless you inspect the source code.
*A non-malicious developer would not choose to hide such a contentius feature.*
Omission of the Parameter from Documentation
The new parameter enableminerfund was not included in the documentation update. https://github.com/Bitcoin-ABC/bitcoin-abc/commit/a64244c3a72749351ddb9f0b825fb9fb18c028aa#diff-3da6427abdeef1f0d6761fe5374f8a90
This could be an oversight but is more likely intentional because previous updates did include new parameters in the man pages, see for example the addition of -enablebip61 . https://github.com/Bitcoin-ABC/bitcoin-abc/commit/db8ac1be82e340c499c520aca3ad34cbf1edd2da#diff-9e9f66b5b2833c022b0408b81a17cfd9R191
*A non-malicious developer would recognize the controversy around this feature, add the parameter to the documentation and clearly highlight its importance in the release notes.*
Automatic Consensus
Even if you go through the source code, find the parameter and set it correctly, your ABC mining node still will NOT vote against the IFP. Consensus to the IFP is hard coded as you can see here . https://github.com/Bitcoin-ABC/bitcoin-abc/commit/b46180893ed61fdc13fa5f95a5a7292c003e1a57#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R151
There is NO way to configure ABC to vote against the IFP unless you change the source code and compile a modified version.
If enough miners run an unmodified version 0.21 of Bitcoin ABC, the modified BIP-9 consensus (66% of blocks consent over any 14 day window) will be ensured way before the May upgrade.
*A non-malicious developer would give the user a way to set this consensus decision.*
Conclusion
In conclusion, the way this was implemented is a malicious and dishonest attack on Bitcoin Cash.
If we want to stop the IFP, we have to:
Create a modified copy (software fork) of Bitcoin ABC in order to create a version that is compatible to ABC but forces the user to make their own choice regarding IFP
Develop an easy upgrade path for miners from the corrupted project to the clean one
Publish these upgrade pathes and spread awareness for the need of the modified version
A more agressive approach would include a hard coded vote against the IFP and the removal of the malicious IFP code. However I fear that this would be open to similar criticism as Amaury's approach and would risk the modified version not following the "correct" chain in case the malicious attack succeeds. On the other hand, people could still pick between running ABC 0.21 or the new modified version of it.
A last resort would be a hard fork of the entire Bitcoin Cash network but we should all strive to prevent that.
Edits:
20200219 Fixed incorrect presumption about BCHD participation in the planning.
20200220 Replaced the word fork where sensible to avoid misleading those who are not familiar with its usage in the software world
20200220 Fixed gammar mistakes and added the fact that miner choice could be accomplished by choosing between untouched ABC and the modified version.
20200220 Clarified that Jonald Fyookball withdrew support for the current form, it is unclear if he is against the IFP completely. Since the time of writing, Jonald also wrote an article that sounds like he is rejecting the idea altogether. https://read.cash/@jonald_fyookball/on-changing-the-economic-policy-of-bitcoin-cash-dacbc30b
@ZakMcRofl