Technically, I’m a Bitcoin ABC developer. I recently developed the OP_REVERSEBYTES opcode and it got added to the codebase.
One might say that’s a conflict of interest and would make me biased towards ABC, however, as I didn’t take any money for my work, I believe the opposite is true: I know how ABC devs work, their rigor and practices while I’m also not getting any money from the IFP. And I don’t intend to, as I want to work on different projects instead, like be.cash and Mitra.
So far, I’ve only voiced my opinion on the fund in a handful of Tweets and recently told that I’d just work on NFC cards. Well I’m at the airport right now so the latter is probably not possible. It’s going to be a long flight so better set some time aside for reading this.
What I find fascinating is that on both sides of the argument, there are people I deem extremely intelligent, driven and passionate about BCH. How is it possible that people that agree on so many things, but diverge on this one issue so strongly? And one thing that has been even more startling to me, why are some people getting so emotional about this issue? Why are some just flat out insulting me directly, making a productive discussion impossible?
Recently, I had a private chat with a BCH node developer the other day whom I don’t want to reveal. He was supportive of the fund but didn’t want to voice the support too publicly, as he was afraid of losing face given all the vitriol of the side opposing the fund. If the climate regarding the fund is that bad, there’s something wrong going on.
I also had a chat with Vin Armani about the IFP the other day. I explained to him, I’m not a contrarian. I’m actually very agreeable (too much you might say) and always eager to get along with people as good as possible. I told him it’s quite surprising to me as to why I would be in favor of the fund while most people around me seem to be against it. He suggested that since I founded be.cash, I now have an increased time horizon, he compared it to having a child. That this changes one’s perspective of the world.
Maybe that’s the case, maybe not. I have to be on the “right” side of this issue, this project is my full-time job now. If I get it wrong I’m set back a lot of years a hundred of thousand dollars of opportunity costs.
And there is a large number of concerns and questions, some of them of them valid, some of them less valid:
It is a tax!
It’s against the whitepaper. It clearly states that all incentives should go to the “creator of the block”.
It creates a powerful entity that can arbitrarily dictate the course of Bitcoin Cash
Amaury is a huge fils de pute and can suck my bits
Amaury is a bad project leader and very wasteful with the resources his team has been given. Code reviews are late, he’s demoralizing his developers and the mood is bad
If there’s an infrastructure development fund, why is there no marketing/adoption fund (similar to DASH)? A chain without usage is useless regardless of infrastructure development
This will be a slippery slope towards changing the protocol arbitrarily; who will prevent Amaury from changing the 21’000’000 BCH inflation schedule?
Changing the coin issuance will be really bad optics, just imagine BTC did this
Should BCH‘s distribution be redirected to Warren Buffett if he promises to help promote it?
What hashrate of all SHA256 miners is pro/neutral/against the fund, as they are the ones paying for the fund?
How will miners against the fund respond to having a percentage of their income redirected to BCH devs?
How can accountability be established for the funded projects?
Why can’t development not be funded by donations instead of the IFP? For example, via an assurance contract. Holders benefit more than miners from a price increase therefore it would be natural for them to fund the development.
Satoshi worked for free, Amaury can work for free. If he doesn’t like it, others will take on that burden.
Nakamoto Consensus is nice and well but most miners and exchanges just follow the code ABC releases anyway without changing any defaults.
BIP9 (miner voting) doesn’t work because Calvin and other adversarial miners will just cause trouble by voting maliciously
The proposal is very contentious and will likely cause a split; the crypto community is already fractured enough
Bitcoin Verde is not on the whitelist
The requirement for a project to be “in need of money” incentivizes developers to pretend to be in constant need of money, making sure they always spend all the money regardless of whether that’s actually needed. It’s also unfair to projects who aren’t in need of money.
I believe anyone agrees with at least one of the points or questions above, at least I do. If you do, too, this article could be very interesting for you.
A tax?
Before we get into why I support the proposal, let’s first get the terms straight. I believe calling the IFP a tax commits the logical fallacy of begging the question by using a loaded term. Let me explain why I think this is the case.
I’ve posed the following question on Twitter: “anyone can explain to me how the IFP is a tax but a minimum transaction fee isn’t?”
Interestingly, I got about a dozen of different reasons! Many of them directly contradicting each other:
It’s not a tax, it’s just an easy metaphor that everyone knows
Miner policies are voluntary, consensus rules are coercive
Both are a tax; fee = tax
Both are like a tax but not in the strictest sense of the word
Anyone can collect transaction fees, only a few specific people can collect the IFP
The IFP is central planning; projects funded by taxation are too. Minimum transaction fees are not central planning
Infrastructure development is too broad of a category of work, which is also true for projects funded by taxation, transaction fees are not
Orphaning blocks is like burning down the proof-of-work of miners and thus coercion
The IFP is theft as it’s taking something that doesn’t belong to them.
If the IFP really is a tax, then why are the many reasons for this argument so clearly divergent and contradictory? Intuitively, this reeks of backwards reasoning: You’re already convinced of X and you‘re then coming up with reasons why X is true, which often results in widely different assumptions—which in turn often lead to conclusions even the proponent would deem incorrect.
Instead, we should start with assumptions and argue from there. If our assumptions are considered true by all parties and every logical step made is valid, we have arrived at a conclusion that must be considered true by all parties.
Let us do just that and see where we arrive.
What is a tax? Usually, it’s only used in the context of governments, but for this argument we can relax that definition to the following:
A compulsory contribution to some entity.
Compulsion in this argument doesn’t have to be violent, it could also be by someone not having access to a private key or something along those lines.
What is the IFP? In short, it enforces a certain list of addresses to which a fixed percentage of the coinbase output has to be sent to. This is ensured by orphaning blocks that don’t follow the rules of the IFP.
But what is orphaning? Technically, it’s when a miner node rejects an incoming block from another node and doesn’t include it in the block header of the current block he’s solving. The whitepaper explains it in the conclusion: “They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.”
This mechanism is also known as Nakamoto Consensus. Generally, any divergence in consensus creates a fork so that one set of nodes follow one chain of blocks and another set of nodes follow another chain of blocks.
Is orphaning blocks compulsion? Even using the very relaxed definition above, orphaning a block is not compulsion, as it merely is refusing to perform work on top of a different block.
An analogy would be when a girl asks me out and I decline (although the reversed situation would be more plausible). She might claim I forced her to spent the day alone by rejecting her invitation, but this is not the case, as she could just go on a different date. Similarly, just because my node rejected your block, this doesn’t mean no other node can accept it.
Equally, even if she put a lot of work into her invitation, that wouldn’t change the fact that it wouldn’t be compulsion for me to reject her. Similarly, just because a node spent a lot of electricity working on a block and my node rejects it, that wouldn’t make it any more or less compulsory.
In the same vein, if I tell her beforehand that I will only go on a date with her if 5% of our expenditures go to my friend Amaury, this too will not make it compulsion.
Similarly, the IFP is not compulsive. It’s not a tax.
What about “The IFP is like a tax”? Well, that’s perfectly fine. My brother is like me. We’re quite similar actually. But does my grandmother call my brother ‘Tobias’? No, because we’re not the same person. Similarly, just because the IFP and a tax have some commonalities, it wouldn’t be fair to call the IFP a tax.
Unless, of course, “tax” obtains a new meaning, which presently isn’t the case.
Nenn mich “Fee”, Baby
I hope I’ve been able to make clear why I don’t think the IFP is a tax. Instead, I suggest calling it a fee, which is much more accurate. Users ask miners for confirmations of their transactions, therefore they pay a transaction fee to miners. Miners need infrastructure to run the network, therefore they pay an infrastructure fee to developers to develop infrastructure.
I would be less insistent on refraining from calling it a tax if the word wasn’t so emotionally and ideologically charged. It would be like when socialists insist on calling a business owner’s profits “exploitation”—how could you support exploitation, hence, how could you support free enterprise?
More so, a good portion of Bitcoin Cashers are libertarians, which includes me, which consider taxation to be theft and immoral. Suggesting that libertarians in favor of the IFP are supportive of something they themselves abhor, is a cheap and very unconvincing way of arguing against the fund and just guarantees people to get angry, which empirically is the case.
It’s using a loaded term and begging the question, which is a logical fallacy where you assume the conclusion. The conclusion here is whether the IFP is bad, the assumption is that IFP=tax.
Some people actually get annoyed when I point out this error, calling it “focusing on [semantics]”. However, what is the point of a debate if one side has permission to just commit a logical fallacy?
Ex falso quodlibet—from a false assumption we can derive any statement we like. It is therefore paramount to get our terms correct, otherwise we can end up at completely incorrect conclusions.
There are some people who instead of calling it a tax moved on to calling it “not-a-tax”. I appreciate the sentiment of this, but hiding a fallacy behind sarcasm doesn’t make the fallacy disappear. Intuitively, it also appears pretty childish to me.
Now that the discussion has become even more charged, it’s hard for me to differentiate between trolls trying to stir things up and people who are genuinely concerned but just use flawed terminology. Therefore, from now on, I’ll refrain from arguing with anyone who genuinely refers to the IFP as a tax and instead point them to this article.
And frankly, after thinking about the IFP a bit more, I figured that referring to it as a tax fundamentally rejects Nakamoto Consensus, the whitepaper and what I consider to be the spirit of Bitcoin. The final sentence of the whitepaper—“Any needed rules and incentives can be enforced with this consensus mechanism”—explicitly allows for the IFP, by changing the incentives if such a change is needed.
Holding onto the belief that Bitcoin‘s rules and incentives should never be changed out of principle is rejecting the foundations of Bitcoin. People are free to follow such principles, but they are not the principles Bitcoin has been built upon.
I’m not interested in convincing someone that the IFP is good for Bitcoin if they don’t believe in Bitcoin.
Principles
Thinking about it some more, I figured I should first establish what my own principles actually are. During my time off from developing which I spent in Acapulco and while being 10’000 ft above the ground, I had some time to reflect on my principles. What are the principles that guide me? And most importantly, does the IFP naturally follow from those principles?
Those are the principles I found which are relevant here:
Truth
Individualism
Selfishness
Meritocracy
Paying for what one values
Let me go through them one by one to explain what I mean with each.
Truth
This is my foundational principle. It’s a very tough standard—it‘s very hard to overcome ones biases, drives and emotions in the face of truth—but the only one I can personally live by. I’ve broken up with girlfriends just because they’ve violated that principle. It’s the principle that got me into libertarianism and Bitcoin Cash specifically. It means that I will not speak untruth deliberately and that I will not refrain from telling the truth when it counts. Which is the reason I‘m writing this post.
Individualism
Other words for this would be ‘secessionism’ or ‘sovereignty’ and it’s very related to selfishness. It means I’m responsible for my own actions. It‘s the opposite of collectivism, where action should be taken as a collective, diverging from the group is seen as bad and the guiding principle is following “the greater good”. In the individualistic view, one is free to not comply and do one’s own thing.
Selfishness
This term carries a lot of negative connotation, however, it is still very important for me. Developers like me often get exploited by other people, which already happened to me. Now, I always ask “What’s in it for me?”. Being selfish means putting one’s own well-being first. This of course doesn’t mean one ought to exploit others, and usually that isn’t in one’s self interest anyway—as it burns valuable bridges.
Meritocracy
Meritocracy means those who provide merit are in charge. It means decisions in a project are not made by majority vote but instead by the accomplishments one has made in the project. Rust, Linux and many other successful open source projects use this mechanism. Also, it’s the foundation of capitalism.
Paying for what one values
I don’t know if there’s a word encapsulating this principle, but in short, it means deliberately paying when one received good services and goods. If I get a convincing and friendly sale, I’ll gladly buy the product and pay for it. If I get good service, I’ll gladly pay a good tip. If a content creator creates good content, I’ll add them to my Patreon or buy their merch.
Bitcoin is an expression of all of the above principles.
It enforces truth by everyone being able to see the entire blockchain and verify for themselves the validity of the chain.
It allows individualism via censorship resistance: Anyone can send money to anyone on the whole planet and there‘s no “collective” that could stop it, as miners are in competition with each other. Bitcoin and collectivism are incompatible.
Bitcoin embraces selfishness as a virtue and turns it into a well functioning economic system by aligning incentives of miners. It doesn’t force or compel anyone to share their coins with anyone.
In the blockchain world, meritocracy is called Proof-Of-Work. ASIC mining—the number of leading zeros—is a good measure for Proof-Of-Work. Proof-Of-Stake is a good proxy for that, less so, though, as it doesn’t mean continuous investment. Development is also meritocratic, if you produce good code and products, you‘ll automatically gain influence.
Bitcoin Cash currently also enforces a transaction fee. If you want to make a transaction, i.e. if you value it, you pay for it.
So far I’ve established why the IFP is not a tax and I’ve explained my principles and how they relate to Bitcoin.
Is the IFP consistent with my principles and might it even follow naturally?
Obviously, just because the IFP is not a tax that doesn’t mean it’s a good idea. Therefore, I will be making the following arguments:
A coinbase output as part of consensus is a natural way of funding infrastructure development
Bitcoin ABC and BCHD are ideal recipients of such a fund
Along the way, I will make a couple of suggestions how the fund can be improved to be more in line with what I think is the spirit of Bitcoin.
One: A coinbase output as part of consensus is the natural way of funding infrastructure development
When thinking about the problem for a minute, one comes up with a myriad of ways different from the IFP how one could fund BCH‘s developers, for example:
Devs just work on their free time without getting paid
Devs get paid by miners directly
Community donates to the devs
Devs provide support for their software, Red Hat style
Establishment of a Bitcoin Cash Foundation, Linux Foundation style
The first one empirically doesn’t work in practice (see most other chains, e.g. Litecoin) and violates the “Paying for what one values” principle. For most people, this sounds like a crazy proposition, but there are actually some Bitcoin Cash supporters that hold this view.
The second one is the one propelled by BSV. If I understand it correctly, miners basically hire developers to write the software for them. Of course, it‘s obvious that this is only a good option if there‘s only a handful of miners (ideally, 1) and if they make massive profits to allow the waste of having different developers working on different implementations. Also, it would be more efficient for miners to form a cartel and pool resources to fund common infrastructure.
This is also how infrastructure has been funded in the past on BCH. In the recent developer meeting, Amaury explained that it‘s been miners, especially those behind the IFP, that have funded ABC so far. However, they are only a subset of miners on BCH. All other miners—often switch miners—aren‘t funding the developers and are basically free-riding. As they don‘t want free rider miners to mine on BCH anymore, they‘ve proposed the IFP.
The third one is sound and consistent with my principles. I really hope the infrastructure can be funded this way. However, my principle of truth also includes empiricism and empirically, BCH would be the first cryptocurrency that would be funded via donations successfully. There have been multiple attempts at this, for example Lighthouse, which didn‘t really take off. There‘s been a recent renewed attempt at this with Flipstarter. It is unclear to me as to why this renewed attempt should succeed while previous ones failed. The arguments I‘ve heard have not been convincing. I still hope it will come around and succeed this time. However, following the principle of truth and empiricism, I cannot just dismiss the past failures of equivalent projects.
Other ways for funding via donations would be for wallets to integrate an additional fee output to the developers, or to make some ritualized event where all holders are asked to kindly pay a certain percentage of their holdings to the developers. Maybe generous donors could be added in a Hall-Of-Fame or something. I think it would be a great idea if we could establish a culture that would partake in such events.
imaginary_username has done an excellent analysis of the dynamics and economics of holder funded development (https://read.cash/@im_uname/assessment-and-proposal-re-the-bitcoin-cash-infrastructure-funding-situation-3e5179fc). Empirically, I don‘t think infrastructure development correlates as clearly with price increase as is insinuated in the article, but I agree with the sentiment.
Given that there‘s a new Bitcoin Cash Node that has forked from ABC just recently, it would be thoroughly surprising to me if both the development of ABC and the BCN can be funded via donations, or even just one of them. It seems like a very short-term solution.
The last two solutions are both economically sound and work empirically. Amaury himself suggested that we should establish some form of foundation that‘s modelled after the Linux Foundation. However, I don‘t believe the ecosystem is yet mature enough to support either of those models. While doing everything in our power to emplace a foundation or a Red-Hat-esque support model, in the meantime, we need a different and temporary solution for funding.
IFP
This is where the IFP comes in.
In short, it adds a new consensus rule to Bitcoin Cash, namely that a certain percentage (in the most recent proposal, 5%) of the coinbase must be sent to one of the addresses of a whitelist of projects.
For some, the idea of miners funding infrastructure development via consensus in any shape or form seems to be against perceived Bitcoin principles. I don‘t think this is the case. While the whitepaper does say “the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block”, which for some appears to be a rule that shall never be broken, it is referred to as a “convention”. In fact, the coinbase reward is an “incentive for nodes to support the network”. It‘s not a dogmatic rule but a practical rule that has a reason to be in place.
What is this reason? The reason is that without miners, the network would not function, as nobody would voluntarily waste resources on mining blocks and transactions would not be secured.
The same reason also applies to infrastructure development. Just as miners wouldn‘t want to waste their time and money on securing the network if they wouldn’t get paid, developers also wouldn’t waste their time and money on securing the network if they wouldn’t get paid.
The concluding statement of the Bitcoin whitepaper clearly allows for a consensus enforced developer fund: “Any needed rules and incentives can be enforced with this consensus mechanism.”
It specifically mentions incentives.
Of course, the question is whether those incentives are actually needed. This clearly is the case if infrastructure development cannot be funded in other ways.
Public Goods
Now wait! What about all the other stuff that’s important for Bitcoin Cash, like merchant adoption, wallet development and advertisement? What‘s the point of a highly secure and safe network if no one uses it?
The difference is that all of those things can be done by a profitable business. As I‘ve outlined above, infrastructure development can’t really be done by a profitable business, except in e.g. the Red Hat model above. However, merchant adoption, wallets and advertisement are already today being done by profitable businesses, most notably Bitcoin.com. I hope more businesses will follow and I hope that my own business, be.cash, will be one of those that spread adoption and awareness of Bitcoin Cash.
That’s why ABC’s proposal specifically limited the addresses to those that are to be considered “Public Goods”.
Whitelist
The IFP enforces a specific whitelist for a fixed set of allowed addresses. Many are supportive of the idea of the IFP, but also think this whitelist is against Bitcoin‘s principles. I don‘t think it is—for Bitcoin Cash specifically.
Practically speaking, the whitelist is up for a vote (at least) every six months. Given that Bitcoin Cash is supportive of frequently changing the rules of the network, I would be thoroughly surprised adding or removing projects from the whitelist wouldn’t be strenuously debated each hardfork. Even the benign change of my opcode—OP_REVERSEBYTES—has caused quite a lot of (mostly productive) debate.
The community and ultimately the miners will come to a consensus which projects should be added or removed from the whitelist, developers will update the whitelist and miners will then enforce said whitelist.
Some members of the community are afraid some form of government could form around the IFP. “What happens when this government is targeted by one or more national governments […] that are x100 size and influence?” one tweet says.
I don‘t think whatever entity will emerge (if any) will have similar powers like a government. My fear is actually the opposite: That there will be so much debate around the whitelist that it will cause a lot of contention and that achieving consensus on the whitelist will be prohibitively difficult. Especially since getting on the whitelist will be a big privilege to have. Miners will still have to choose which project they actually want to support, so getting a project erroneously on the list or one that later turns out to be not a good idea can be avoided by miners simply not sending any money to the address.
To avoid any of these issues I believe we will need three things for the IFP to function, which presently don’t exist yet:
Some form of Bitcoin Cash Manifesto, which lays out clear and concise principles of Bitcoin Cash (similar to how I’ve laid out my principles in this article). I’m sure there are numerous sources to draw from, but one has to be very careful about which principles to include and which to omit. If the principles are inconsistent, it will make the whole thing useless.
A clear set of conditions a project on the whitelist has to fulfill. There currently exists such a list for the IFP, but it seems too arbitrary, relaxed and over-inclusive. It also isn‘t very convincingly written, not very precise and doesn‘t define its terms well.
An independent set of auditors. These auditors can be volunteers from the community or funded by third parties. It‘s an open group, anyone can become an auditor. It should be a community effort. They will keep the projects on the whitelist accountable to the whitelist conditions, gather metrics regarding the projects’ performance and productivity and uphold the principles of the manifesto. If they violate any of the conditions or principles or don’t show sufficient performance, they will first be removed from the list miners choose from and subsequently removed from consensus.
All projects publish the development history (i.e., amongst other things, the git history) of the developed code, with accurate timestamps. This already is the case today anyway so it wouldn‘t change anything about how developers operate. Based on the development history, auditors can see the progress and performance of the project. Are many tickets closed? Are the made changes necessary and are they clean? Is there time wasted on vanity changes or instead spent on useful refactoring? What new features are added? Do benchmarks improve over time? Can the software process more transactions now?
I do believe that this mechanism will both be efficient and effective. It is principles based and doesn’t add unnecessary overhead for developers. Developers will have to answer more questions about their work than before, but that is the price that is—and should be—paid for receiving funds via the IFP.
For me, it seems like ABC didn’t make it’s due diligence when coming up with the IFP implementation that’s now part of the ABC code, which is also reflected in the fact that no miners are signalling for the change: https://bitcoincash.network/voting/
The conditions for the whitelist seem sloppy and too lazily established. Why are those conditions there and what underlying principle do they it serve? What is the “General Fund”? What does “in need of money” actually mean and on what principle is it based? ABC needs to pay a bit more attention to these questions.
I think miners would be very grateful for having a whitelist of projects that has been properly audited and based on principles they agree with. They would have the certainty that their investment is in good hands.
Such a modified IFP would be d‘accord with all of my principles:
Truth: It would establish clear rules and principles and anyone can verify they are actually upheld. It embraces discussion and scrutiny.
Individualism: Everyone has a chance of getting on the whitelist and the rules are clearly defined. The whitelist itself is enforced by Nakamoto Consensus and ultimately, anyone is free to choose a different chain.
Selfishness: It allows BCH-supportive miners to follow their own self-interest. Currently, they are forced to be altruistic and have to accept that a certain percentage of their money goes to fund developers despite all miners benefiting off it.
Meritocracy: It financially rewards projects based on merit and what they‘ve accomplished so far and it punishes wastefulness.
Paying for what one values: Infrastructure development is valuable and the IFP makes sure it is paid in exchange of a relatively small reduction in PoW security.
Two: Bitcoin ABC and BCHD are ideal recipients of such a fund
Now, we haven’t established the principles that will be used for such a whitelist yet. However, we can use my principles from above for now.
There are numerous projects that could need funding. As established previously, I don‘t think wallets should be included in this list, as they can (and often are) funded by a profitable business. This means Electron Cash cannot be included in the list.
What about node implementations?
The only notable ones are the following ones:
Bitcoin ABC
Bitcoin Unlimited (BU)
BCHD
Bitcoin Verde
Flowee
BU already has sufficient development funding, but more importantly, funding BU via a development fund would violate my principles of truth and meritocracy. Joannes Vermorel in his recent blogpost writes the following (https://blog.vermorel.com/journal/2020/2/21/abc-is-bitcoins-biggest-asset.html):
“Bitcoin Unlimited (BU) has abysmal development practices, and keep misleading the community about the ‘grand’ features they have delivered. This team has zero clue on how software is supposed to be engineered. By way of anecdotal evidence, this recent commit merged into the master branch: 267 changed files with 18,311 additions and 4,526 deletions. For infrastructure code, this is beyond amateurism, this is madness.”
If BU doesn‘t improve on its rigor and professionalism, to include them on the whitelist would be a violation of my principles. In fact, due to bugs in the creation of block templates, some miners have lost a good portion of money already (https://bitcoinist.com/bitcoin-unlimited-bug-miscounting-bytes/). Development practices should be rectified and improved regardless of the fund. If this would be the case already, there‘d be no funding problem in the first case.
Neither Bitcoin Verde and Flowee show up on any node explorer that I could find, which made me conclude that the node share must be relatively small. Bitcoin Verde has made laudable process over the time and I‘m almost certain that the project would eventually be included in the whitelist once its significance rises even more. However, as it currently stands, the merit of both Bitcoin Verde and Flowee does currently seem too small to warrant an entry in the whitelist.
BCHD, on the other hand, is used quite frequently when looking at the node count, and its code follows professional software practices. Going through the code myself, it was very easy to find the functions I was looking for and even make debug modifications myself, despite never writing any significant Go before. If I recall correctly, it is used by CoinText and a lot of other projects due to its easy-to-use nature. In my view, it provides sufficient merit to be included in the whitelist. This of course depends on the actual conditions that will be established for the whitelist.
Now, finally, Bitcoin ABC.
There‘s been a lot of misinformation going around Bitcoin ABC. People are claiming things are not getting done, reviews remain unreviewed for a long time and morale is down.
All of that due to Amaury Sechet, of course, who apparently is a terrible leader. Now, I do agree that some of the public communication done by him has been very questionable and, to put it kindly, a bit too French. Some of his attacks on BU seem undiplomatic. Justin Bons calls the IFP a “clear failure of leadership [...] since it is [severely] lacking in political & diplomatic sensitivity”.
However, given that the communication by other members of the community has been even worse and sometimes flat-out insulting, his behavior can be excused to some extend. And he definitely is aware that some of his communication style should be improved.
And yes, he can be harsh in reviews, albeit so far this seems fully warranted:
And when you break the code and don‘t reply for six hours (I was 10’000ft above the ground), he does get a bit annoyed:
shared with permission by Amaury
However, at least in my communication, he‘s usually a lot of fun and very supportive:
Now, your interaction with Amaury might be entirely different and likely is, but this is just my subjective view. He puts very high standards on all changes to Bitcoin ABC, even requested an unrelated refactoring to happen to make the code for the OP_REVERSEBYTES activation clear enough.
Everything about dealing with Bitcoin ABC feels extremely professional. This shows in their track record, historically, there have been only very few significant bugs and all of them have been fixed pretty much immediately. Most notably, the inflation bug found by awemany has been handled even more professionally than by Bitcoin Core, which have a reputation for having excellent coders.
Also, Bitcoin ABC was solely responsible for the inception of Bitcoin Cash.
It should be crystal clear that they’ve provided enough merit to warrant an entry in the whitelist.
Conclusion
I hope I was able to make clear why I do support the IFP and why it aligns with my principles. Regardless, creating some form of manifesto would be a good idea in my opinion.
I further hope this article will be used as a basis for a friendly and productive discussion.
If desired, I can provide beer and pretzels.