Join 74,293 users and earn money for participation

Why I support the IFP despite the community seeming to hate it and how to fix it

30 1329 boost
Avatar for TobiasRuck
Written by   95
1 year ago

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 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, 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.


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.


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.


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.


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 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:

  1. A coinbase output as part of consensus is a natural way of funding infrastructure development

  2. 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 ( 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.


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 I hope more businesses will follow and I hope that my own business,, 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”.


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:

  1. 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.

  2. 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.

  3. 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:

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 (

“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 ( 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 extent. 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.


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.

$ 107.89
$ 45.00 from @J-Stodd
$ 10.00 from @Cain
$ 10.00 from @Nicknameul
+ 32
Avatar for TobiasRuck
Written by   95
1 year ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.


fine fine I used to be anti-IFP but now I'm maybe changing my mind.

Implement the tax (no no no it's not a tax, except it is), and we'll see how Bitcoin Cash Tax will perform.

Maybe change it down to 4%. Not 8%. too high.

$ 0.00
1 year ago

If I understand it correctly, you support IFP in principle, but not in the form currently proposed.

$ 0.00
1 year ago

What a wonderful job! But some points tickle me.

First of all: tax versus fee. When you drive on a motorway built - at least in part - by private funds, you have to pay a fee for using it. When you send a transaction on the BCH network, you pay a fee for the miner who will use electricity to enter it in the block hi signs. (Unfortunately, nodes who validate and propagate it don't receive anything. Snif!).

When we live in a society, everything cannot be financed by private funds, for various reasons, and not only political. Public funds are necessary to build global infrastructures. They are fed by taxes (on our income, on the products we buy , etc). And it's normal. Similarly, it seems normal to apply a tax on the income generated by the BCH ecosystem in order to build and maintain its infrastructure. And by infrastructure I mean development (physical and human resources) but also the necessary marketing and adoption plans

A fee is paid when we (individually or not) use a service. A tax is paid to some organization like a public foundation, the government..., in order to fund global infrastructures, which will be used by everybody.

Another "detail": When a rule is implemented, it is inevitably accompanied by a constraint : fine or worse (like orphaning blocks). Due to human nature, an unconstrained rule is not applied. Writing a lot of words to try to demonstrate the opposite is (at least) useless ... So try not to pay your taxes!

There are some other details, but I don't want to troll or bother the reader...

Anyway, trying to twist words to divert them from their effective meaning is only useful for those who want to bury points of the debate, which are perhaps more important, like the notion of "government" precisely. In some post somewhere I read: "A top developer is rarely a good manager". I think we can extend that to top technicians. It's obvious, and I know that, as I'm a technician / developer and not a good manager! Self-centeredness and authority are good for survivalists. But when you manage a world-class project, these are not the most useful qualities. Delegation and democracy seem to me to be much more effective. If these concepts had been called upon, the debate would certainly be on a whole new level.

How can one have a good and constructive idea, and finally get such a fracture of the community? Is it a good way to manage things? Oups! Sorry : may be this is too French !

$ 0.00
1 year ago

taxation is theft

$ 0.00
1 year ago

There is no community that is fractured. There are influencers trying to gain, hold or regain influence over the development of Bitcoin Cash BCH with other means than code.

Delegation does happen already and would even more so, if the money was there to pay for the delegates. "Democracy" is just fassade for social manipulation, as there is no better consensus mechanism that could or should rule over Bitcoin. Having "Governance" only in the realm of Bitcoin PoW seems to me far more emergent and decentralized, than trying to steer it via gremiums and campaigns. It's social/politics vs. Bitcoin/PoW.

This "ideological" battle is not fought between rebels and dictateurs in the realms of Bitcoin Development or BCH network. It is fought between people, who want governance implemented - as flawed as it may be- on BCH PoW and people who still have not understood how this is far better than having a handful of commissars decide, who and what to include. Wouldn't be surprised if they start to pay themselves out for the bureacracy they cause. For real now. This is where the "collectivism" vs. "individualism" issue lies.

People who think it is better to have BCHgovernance + BCHgovernment and people who see the Bitcoin marketplace for what it is and let BCHgovernance make its thing alone.

I want no one else decide the direction of the funds, than the dominant dev teams themselves. If BU or BCHN can outcompete them in the Bitcoin game, so be it. It means they are doing something right. If they want to retard them from playing the Bitcoin game by campaigning on the social side of Bitcoin, they are simply signaling time and again, that they can't compete on Bitcoin and are not the guardians we should even consider as such.

$ 0.00
1 year ago

Well reasoned, excellent article. I think Roger made a good point. Patreon accounts will help a lot. I love crypto but passive monthly payments are still nowhere. I want to set and forget not reminders to donate each month.

$ 0.00
1 year ago

so much insight that I just didn't have before .. thanks @TobiasRuck for also explaining to me WHY BU was on everyone's shitlist..

Devs provide support for their software, Red Hat style

this SHOULD be how it's done .. I get that many feel this has already been tried and failed, or that there is NO time for this, but I HAVEN'T TRIED YET, so this is still going to be my FIRST course of action..

I'm happy to now be working with the Flipstarter team (specifically @emergent_reasons) and these guys have some really great ideas already in the works .. I'm confident that we'll be able to DEMONSTRATE a better solution before May 15th ..

No one wants to see a SPLIT/FORK and I believe EVERYONE agrees that funding is absolutely necessary .. We just need to work harder at making that happen .. I don't believe I've seen a GENUINE effort for ABC to "monetize" their efforts .. in short, very smart devs, usually make very poor business managers

$ 0.00
1 year ago

Thank you for writing this! It was a very good read.

$ 0.01
1 year ago

I have read this but I don't seem to understand anything because new to cryptocurrency

$ 0.00
1 year ago

The part about white paper is spot on. The part about improvements to the ifp is crap.

$ 0.00
1 year ago

Thanks for making your opinions clear.

When you have time, I would like you to re-assess Vermorels anecdotal evidence of a bad practice. From what I understand, the changeset referenced is merely a collection of smaller parts being merged together to form a release candidate.

If there's something inherently wrong with this, I'd like to know more - to me it seems sane to separate the development and the release process.

$ 0.00
1 year ago

I skipped to the conclusion and I want my beer and pretzels. Will go back to read now.

$ 0.03
1 year ago

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.

I am quite convinced that the IFP makes incentives worse rather than better. It incentivises developer corruption, development centralisation, and miner centralisation, ultimately undermining properties like censorship-resistance. It builds the tyranny of the majority into the protocol, which is not good for the ecosystem.

Any needed rules and incentives can indeed be enforced, but the IFP is neither desirable nor needed. With respect to the latter, I would also like to point out that Litecoin is in fact one of the longest running cryptocurrencies and it is still functioning fine.

$ 0.01
1 year ago

Nicely done, well thought out.

$ 0.00
1 year ago

You missed the biggest concern many had for this most retarded idea: it splits the community and will cause many high integrity people to leave. This alone should cause it to be a non-starter, and anyone working towards furthering the tax idea is promoting a reduction of the BCH community.

Also needing multiple pages to describe why something definitely isn't a tax and instead a fee paid towards the people who govern the protocol in exchange for their work on fixing the roads I mean preventing an attack I mean it's just paying for security from a central entity isn't a very strong argument towards why something isn't a tax - politicians pull these tactics all the time and it's the same now. When the result of not paying a "fee" is a fine (via orphaning) it is a tax. Not unlike politicians, Amaury also decides the law, and so therefore by decree deserve some of the tax. Otherwise society would fall apart, I mean Bitcoin Cash. So the tax must be paid, otherwise there will be a split, unless the dictator is ousted or relents his power.

Your manifesto idea is the same as a constitution, because this isn't a tax we must call it something else. The government I mean Amaury must be restricted in their power. May be we should vote on who receives the tax, I mean fee? Maybe we could elect trusted representitives from Bitcoin Cash to vote on our behalf for who should receive the tax? This still is not a government, this is something else. This is Bitcoin! This is money not backed by a government! This is freedom!

We should reject taxation and all who support it with every bit of blood in our body.

$ 1.61
1 year ago

we should reject every ancap that doesn't know what a tax is

$ 0.00
1 year ago

You missed the biggest concern many had for this most retarded idea: it splits the community and will cause many high integrity people to leave.

This claim is as true for both sides of this disagreement. Also, who is creating the new fork? Anti-BCH forces with pro-BCH supporters just like when BSV did it. Most real pro-BCH forces would not want to split the community. The powers behind stopping miners from donating to developers want to split BCH, reduce developer funding and remove our lead developer. And, the powerful forces behind it will try to keep his new BCN project going to use to divide our community again in the future.

$ 0.15
1 year ago

We will not move forward with a trial of intent ...

$ 0.00
1 year ago

What's sort of interesting to me, is that instead of allowing me to "sell" the IFP to the community in an effective way, ABC just took the ball and ran with it, much like a bull in a china shop, which pretty much guaranteed the community would hate it. In doing so, they ironically demonstrated the principle that it's a good idea to trust as few details of the protocol as possible to humans, and that this was never really a sound idea for a system that aspires to adhere to the original principles of Bitcoin. This is essentially why I've changed my mind on the IFP.

$ 1.01
1 year ago

Likewise, my main point of opposition to the IFP is not on ethical grounds. I do believe that using block rewards to fund protocol dev (or marketing, or adoption), if adopted by miners, falls under the "any needed rules and incentives can be enforced with this consensus mechanism..." bit of the whitepaper.

Had the idea been introduced more gently, and its proponents spent more time building support for the idea, collecting feedback and adjusting the idea along the way, I think it could have been an interesting (and hopefully successful!) experiment to try.

Instead what we got is a half-baked implementation of the idea, hastily thrust upon everyone and using somewhat disingenuous tactics. Merging the code on the day of the code freeze for the May 15th upgrade, and making it so that any miner running ABC would be voting 'yes' by default seem quite sneaky to me. Also the fact that the whitelist is basically "Amaury and a couple of friends," rather than including a longer list of valuable projects that could be funded.

Yes, it could have been an interesting experiment, but its certainly not worth splitting the community over.

$ 0.15
1 year ago

You are right : probably funding is necessary and the tax is the easiest way. But the way it's imposed leads to a split in the community. A tax can be implemented only if it is accepted by the community and it should be directed to a couple of published addresses, managed by some kind of organisation (and not only "the chief") which allocates the funds to the projects and resources, which are considered as useful on the base of accepted and objective criteria

$ 0.00
1 year ago

There is no poison pill. BIP-9 works that way, and Amaury has already said that in the next release of Bitcoin ABC, they will set the default vote to no. Source is the latest Developers meeting.

And I agree with Tobias that Electron Cash does not really belong on the list. It should just be Bitcoin ABC and BCHD. None of the other node implementations are even used besides BU, and they have a warchest of millions that they aren't really utilizing as it is. Also barely any miners, if any at all, runs BU.

$ 1.05
1 year ago

this was never really a sound idea for a system that aspires to adhere to the original principles of Bitcoin

I think you have jumped to this conclusion too quickly. Yes, the recent proposals and current attempt to ram it through are terrible as written and proposed. I believe the idea of miners donating block rewards to development funding is still a great one. It will not be easy to make a community supported plan with all the anti-BCH forces speaking loudly against any good plan, but, that does not mean we cannot come up with a plan that is supported by 100% of the BCH miners doing the donations and does not give the power to determine who gets funded to the developers who are getting funded.

$ 0.10
1 year ago

Thank you for the well thought out arguments. I especially liked the part about individualism v. collectivism. I hate collectivism.

$ 0.50
1 year ago

I liked your article. Hope more people read it because it gives some nice insight into the Miners Development Fund and BCH. I hope the guys over at BCHD get some part of the funds because I like their project a lot. Very easy to use and written in GO, making it accessible to new Devs joining BCH!

Wish you all the best Tobias!

$ 0.50
1 year ago


  1. 需要给出基金管理的直接责任人,不能全权交给开发者,尤其是不能由Amaury一个人来决定。我的建议是先建一个3人或5人委员会,由他们平衡社区意见,制定进一步的基金管理规则。为保证委员会的效率,基金采取2/3或3/5的多重签名地址。

  2. 赞同基金不是对矿工的抽税。基金只是在保持总量不变前提下的发行政策变更。如果中本聪一开始就设计了50个btc的新币发行中,有10个形成公共基金,40个由矿工挖出。不会有人认为这抽了矿工的税。现在反对抽税,仅仅因为以前没有基金发行,如果现在在总量基础上增加发行,就不存在抽税的含义了,但这样就改变了总量,反对意见会更大。所以,从现有的coinbase中划分5%或4%是最理想的。

  3. 我建议coinbase的4%形成公共基金。减半后,Coinbase为6.25bch,4%刚好是0.25bch,容易计算和识别。

  4. coinbase发行中提取基金的经济模型是帕累托改进。

    1)挖矿本身是有成本的、竞争的,并由难度调节的,对于sha256算力总额而言,新增基金几乎没有影响。 2)基金用于奖励外部性很强,但有非常重要的贡献,对bch发展很有意义。 3)矿工收益的很大部分要卖出弥补成本,而贡献者获得奖励却不一定会卖出,他们持币的数量增加,有利于他们更加关心bch的发展,为生态做出更多贡献。

$ 0.10
1 year ago


"In general, support the viewpoints of the article and add the following:

The person who is directly responsible for fund management needs to be given, and the developer cannot be given full authority, especially Amaury alone cannot decide. My suggestion is to first establish a three- or five-member committee, who will balance the opinions of the community and formulate further fund management rules. To ensure the efficiency of the committee, the fund adopts 2/3 or 3/5 multi-signature addresses.

The approval fund is not a tax on miners. The fund is just a change in the issuance policy under the premise of keeping the total amount unchanged. If Satoshi Nakamoto had designed 50 new currency issuances of btc at the beginning, 10 would form a public fund and 40 would be mined by miners. No one thinks that this is taxing the miners. Tax collection is now opposed, simply because there was no fund issuance before. If the issuance is increased on the basis of the total amount, there will be no tax collection, but this will change the total amount and the opposition will be even greater. Therefore, dividing 5% or 4% from the existing coinbase is ideal.

I suggest that 4% of coinbase form a public fund. After the halving, Coinbase is 6.25bch, 4% is just 0.25bch, which is easy to calculate and identify.

The economic model of withdrawing funds in coinbase issuance is Pareto improvement.

1) Mining itself is costly, competitive, and adjusted by difficulty. For the total amount of sha256 computing power, the new fund has almost no impact. 2) The fund is used to reward strong externalities, but has very important contributions, which is of great significance to the development of bch. 3) A large part of the miners’ income has to be sold to make up for the cost, but the contributors will not necessarily be sold if they are rewarded. The increase in the number of their coins will help them to care more about the development of bch and make more contributions to the ecology."

$ 0.00
1 year ago

Hello friend @TobiasRuck we loved your article, we also hope through this article you can clarify to the Spanish speaking community why you support the IFP and why it aligns with your principles. We also hope that this article encourages the Spanish-speaking community to participate in the friendly and productive discussion you have proposed. Delighted with some beers and pretzels. We hope you continue creating articles of great importance for and the entire community.

$ 0.25
1 year ago

It's a coercive tax from a central authority that goes to the central authority for expenditures you may not agree with. It stops being coercive when you leave that governing body's borders (the chain). This makes it less coercive in a sense that makes it more like a tax, not less. Honest and intelligent reflection should have revealed this. More egregious in the sense of not demonstrating honest intelligence was mixing dumb tax assertions with two good ones and stating this: "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:..."

$ 0.00
1 year ago

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.

So, in fact you are telling us that ABC nodes will not accept blocks from other nodes because ABC nodes pay the 5% percent of rewards and others nodes do not. In that way ABC nodes are pushing|forcing other nodes to accept that compulsory payment rule(consensus rule) or will not accept the validated blocks of them.

$ 0.00
1 year ago