Necessities for funding plan to work

7 342
Avatar for EmilOldenburg
4 years ago

Here are some of my thoughts about the funding proposal. I will mostly just explore the statements already given by Bitcoin.com here and here.

Who is paying for it?

There has been many ideas floating around who is actually paying for it. Would it be the miners (hashers), the pools or BTC paying for it? Some people suggested on Reddit that this is completely free. It’s not that easy, and I will explain it.

The old saying goes, “There is no such thing as a free lunch”. And this is correct in this case as well. At a first glance, it would appear that the miners would pay for it, and the mining pools would act as collectors. Initially, the miners will take a small hit and they will start mining BTC instead.

Due to the unique properties in bitcoin, when miners leave the network, the difficulty goes down. In practice, this means that kilowatt hours (kWh) needed to produce one BCH will go down. So even if the miners will be paid less BCH by the pools, less kWh will b required to produce the coins. The net effect is that miners will end up paying the same amount of USD for producing coins.

That doesn’t sound like sound economic theory, one would argue. Well it does, because what really happens is that we are mortgaging the PoW security of the chain. The BTC chain holds a mortgage loan on BCH that will increase the difficulty on BTC and lower it on BCH.

Some people asked on Reddit, “If it’s free, why don’t you just allocate 80% instead? Why stop at 12.5%”. The answer is simple. Because taking too much mortgage debt is dangerous. We need to balance it. Financing something with a mortgage is the most normal and common thing to do, but it has to be reasonable.

Because bitcoin has this unique feature with difficulty adjustment, the mortgage can be considered repaid when the coinbase allocation stops after six months. When this will give an immediate boost to BCH since BCH suddenly will be more profitable to mine and PoW security returns to the BCH chain.

If it turns out the mortgage we take out is more than the network can handle, the initiative should be abandoned.

Is this a tax? An initial glimpse at it makes it look like one, but if you dig deeper into the game theory, how bitcoin works; it's not that simple. Tax is a dirty and bad word among bitcoiners, and the hate for taxes have somewhat blinded people. The gross effect could be called a tax, but the net effect is more like a PoW mortgage. I don't think we should focus on the semantics, rather focus on what the consequences are, and if they are worth it.

Why can’t it be a voluntary contribution?

All mining is always voluntary. Each mining pool vote with their hashpower and decide which block to mine. The truth is that just because you mine a block, it doesn’t mean you will get paid for your effort. The other mining pools needs to voluntarily choose to put 99 more blocks on top of yours before you can use your coins.

After 12.5% is shaved off the block reward, 5.46875 BCH remains. Each miner (hasher) will be paid from that. Any mining pool trying to do this alone will just have all their hashrate leave. It’s like a boxer cutting off his leg to lose weight. You would just create a disadvantage for yourself. For the game theory to work, all pools needs to do it. If not, the difficulty won’t go down and we won’t be able to mortgage the PoW. Either everyone does it, or no one. There is no middle ground.

For this to be voluntarily, the amount would be much lower and it would need to be a configuration on the pool account where each miner can choose to get paid less and the mining pool would allocate coins directly to a development team.

Are the miners actually supporting it?

The main person who wrote this proposal, Jiang Zhuo'er owns most of his hashrate. He is both a miner (hasher) and runs a mining pool. Not all pools own their hashrate, but we have spoken to some of our customers mining on Bitcoin.com that are positive. We also acknowledge there are miners against the proposal. Please keep in mind that this proposal can only work if a majority hashrate supports it. We are not doing this to enrich a few individuals, but to strengthen Bitcoin Cash as a whole.

Without majority hash support behind it, this effort could risk a chain split.

How can we make sure this is not permanent?

We have stated that it must be temporary and reversible. This is important, and there are a few things that needs to be in place for this. To make sure it is temporary and reversible, we need checks and balances. This can not be added as a consensus rule in the nodes everyone runs, because then it would not be reversible. This is a soft fork that only miners need to do. Exchanges and wallets should follow the longest PoW. That way, this proposal can only work as long as the miners mine on pools supporting this proposal. This adds accountability towards the mining pools. It also makes sure that mining pools have an incentive to dissolve the initiative if they lose majority hashrate support. Because newly mined coins require 100 confirmations to mature, it creates an incentive to mine on the longer chain the exchanges are on and salvage the coins mined rather than sticking to the initiative.

The mining pools should have their own special client that enforces the soft fork. The allowed addresses and the rules must be decided beforehand. After the rules are set, they can't change. There has been worries that miners will take the opportunity to change the rules as they go. That’s why it’s important to do this as a “code once, deploy once” effort. If it turns out something doesn’t work according to plan, the initiative should be dissolved and we return to normal.

Does this make BCH less decentralized and more censorable?

No. It doesn’t. There is a fear that the mining pool initiative would get full the power over BCH, and they would be able to decide everything from that point on. It won't be the case and I think it's very far fetched. It does not make it less decentralized or more censorable than today. The only difference would be that we allocate money to developers. Already today, mining pools know how to contact each other in case of emergency. The mining pool operational staff rarely talk to other pools and this proposal won’t change that. There won't be central control room, because it's not a requirement for this to work. The argument that it would be a slippery slope towards centralization is just a strawman. Any pool that would get a block orphaned would quickly comply to avoid getting more blocks orphaned, so it would not lead to less pools. Since this would be a one time rule change, no infrastructure for censorship would be established. Bitcoin.com and any other pool I know of would refuse to setup infrastructure to censor transactions.

What about the Hong Kong company?

I’m frankly disappointed in some of the community members about this point. Hong Kong is not a shady place for a company, and it’s not China. Anyone suggesting that China would be able to take control over the development funds needs to read more about Hong Kong law and how Hong Kong works. The easiest way to offend someone from Hong Kong is to call them Chinese. It would also not hold any fiat, just BCH. Even in the very unlikely event of a company takeover, it does not guarantee private key take over.

That being said. Roger doesn’t like the Hong Kong company idea, I don’t like it, and it’s very likely that this part of the proposal will be scrapped. It's not because it's a Hong Kong company, but because it's a company. I agree with Roger, we don’t really need a company for this.

How will the funds be distributed?

It's still in the works. We are still discussing it. There have been suggestions about establishing a list of addresses belonging to several developer teams and letting the mining pools distribute coins directly to those addresses and cutting the middleman that would be the Hong Kong entity. That way no single entity receives all the funds, and if one recipient gets corrupted the pools can just fund another development group.

Each development team that wants to get funded should state what they plan to do, how many developers they plan to hire and how much money they need. If all the goals were to be fully funded early, the funding initiative can be dissolved early.

We fully acknowledge the contention and are seeking ways to avoid conflicts of interests, establish checks and balances, and a proper power balance.

Bottom line

This proposal was suggested in order to strengthen the Bitcoin Cash community by properly funding it. If it turns out at the effect would be the opposite, we will not go forward with it. If it turns out halfway through that things are not working out, it will be dissolved.

Bitcoin.com will never risk another chain split, because this time it will be our actual friends that would be leaving. That’s why we want as many people on board as possible. For this to work, we need the miners (hashers) on board and we need the community. We need the community to follow up on how the funds are used, help recruit the right developers and voice your opinion on what we need to build to make Bitcoin Cash the best kind of money in the world.

Funding is a real issue we need to solve. This is one suggestion that I believe would work if done right, but I also acknowledge that this could be done wrong. That's why we need checks and balances, and avoiding conflict of interests.

For now, it's back to the drawing table.

Emil Oldenburg
CTO, Bitcoin.com

1
$ 2.72
$ 1.00 from @joshmgreen
$ 1.00 from @randomuser
$ 0.50 from @Pete
+ 5
Avatar for EmilOldenburg
4 years ago

Comments

This can not be added as a consensus rule in the nodes everyone runs, because then it would not be reversible.

Every soft fork is reversible by a hard fork. More about that after you've read the next point.

This is a soft fork that only miners need to do.

In 2018, when the network was under attack (Hash War by C&C), miners ran with a rolling checkpoint patch, but even this code was released swiftly.

Now you are suggesting miners run code that others do not need to see. For 6 months (or a shorter but still indefinite period until it is dissolved)?

It's no longer a permissionless network if other nodes cannot join to mine the chain without going to a trusted party to obtain clearance, or a copy of the holy scriptures.

If the consensus change were not reversible if ordinary nodes ran it, then you've just identified a major risk to the plan which breaks the entire promise of "it'll be temporary".

Someone just has to defect the mining cartel and open the code, and runs a bunch of nodes, and suddenly it's permanent. WTF? Or someone hacks whoever's got a copy of the code (remember: several pools and possibly more people) and puts it out, and the change is permanent. Or someone is bribed, and suddenly it's permanent. Or... you see the problem?

Please clarify.

This is only the tip of the iceberg of what I find an extremely disturbing plan which you try to sell.

Also, Bitcoin.com official update tone from a day or two ago [Edit: I noticed this article is also a day old but I only encountered it published via an /r/btc link 4 hrs ago] versus this reads completely differently, as if there was a day shift and night shift. Or a good cop and bad cop.

It's clear you (bitcoin.com) are doubling down on the mandatory nature of the orphaning aspect. It's not off the drawing board.

Excuse my annoyed tone, I really am very annoyed by what is on display. As a member of the community, I feel we are being truly jerked around.

$ 5.00
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
4 years ago

Every soft fork is reversible by a hard fork. More about that after you've read the next point.

It's a very different dynamics. Mining pools can at any time decide to tighten up the rules if they have majority hashpower. As long as the rest of the non-mining nodes (wallets, exchanges) don't have the same rules, the miners can at any time stop enforcing the more tight rules and everything goes back to normal. No chain splits. Network is kept together. If all nodes (mining nodes and non-mining nodes) decides the run the same node implementation with tighter rules, then if the mining pools wants to stop, all other nodes needs to upgrade their nodes at the same time. This was basically what Jonald Fyookball was proposing, and that would be a bad idea.

Now you are suggesting miners run code that others do not need to see. For 6 months (or a shorter but still indefinite period until it is dissolved)?

I never said that. It would be a publicly available and open source node client. Otherwise anonymous miners would have no way of joining.

If the consensus change were not reversible if ordinary nodes ran it, then you've just identified a major risk to the plan which breaks the entire promise of "it'll be temporary".

No, it's the opposite. If only the mining pools mine blocks with stricter rules, then it's easily reversible by mining pools stopping to enforce the stricter rules, or they lose majority hashrate (which would lead to the mining pools donating to the fund forking themselves off from the rest of the network).

It's clear you (bitcoin.com) are doubling down on the mandatory nature of the orphaning aspect. It's not off the drawing board.

I'm just saying that orphaning has to be a part of it for the game theory to work. Otherwise the difficulty won't adjust and it would just be a couple of pools shooting themselves in the foot. The only way to keep the "dollar per mined coin" the same is if everyone does it.

$ 0.00
4 years ago

It would be a publicly available and open source node client. Otherwise anonymous miners would have no way of joining.

If it remains open source and other miners can join, that would alleviate that particular concern of mine.

I just have problem squaring it with this statement:

To make sure it is temporary and reversible, we need checks and balances. This can not be added as a consensus rule in the nodes everyone runs, because then it would not be reversible.

How one can have an open source mining node with the consensus rules rules fully available to all who want to mine, and at the same time NOT make these rules available to those [other] nodes, is beyond me (for now).

Anyone who understands this how this could work, please can you shed some light.

$ 0.00
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
4 years ago

The whole point is to make sure the initiative can be dissolved or overthrown at any time.

$ 0.00
4 years ago

p.s. you may have responded before I finished my edits.

I tend to add some stuff to my posts after I think about what's missing.

$ 0.00
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
4 years ago

It's an either/or situation to me, unless one introduces permissioning.

Either all nodes have access to the consensus rules (for this it does not matter if the code for ordinary vs mining nodes is split up across separate repositories). Or they don't, concretely as per your requirements, the nodes "everyone runs" (non-mining nodes in this discussion nodes) should not use those rules, otherwise it becomes not reversible (again, per your statements).

But you can't prevent someone sybiling the whole network with relay nodes if they have access to the mining node rules.

Only way I can see to eliminate this attack vector is to postulate secrecy around the mining node rules. That could take the form of a whitelist of fund addresses. That would mean one would distribute a client with incomplete consensus rule configuration, with some crucial bits (data file) externalized and possibly shared only by mining nodes "in the know". If this were the case, it would fall under what I called "permissioned".

$ 0.00
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
4 years ago

I am all for supporting developers with some mining rewards. I really appreciate the miners/pools offering to make this happen. What I think is/was bad about the plan was forcing all miners to lose 0.44% of potential profit against their will. Personally, for a variety of reasons I am ok with making people who do not want to donate 0.44% to BCH developers lose this potential income anyway, but, I can see that this is a legitimate gripe.

I believe most who gripe will be doing so because they are anti-BCH, only care about BTC or are making the decision based on short-term greed (ignoring the longer term increase in value). I would feel bad for people who do not fall into these categories and just cannot afford the loss of 0.44% of what they were expecting to get.

So, I agree with this quote from above:

Please keep in mind that this proposal can only work if a majority hashrate supports it. We are not doing this to enrich a few individuals, but to strengthen Bitcoin Cash as a whole. Without majority hash support behind it, this effort could risk a chain split.

My concern is what hash rate majority do you think you can get? I do not know. Maybe the majority of all the Bitcoins' hash is BCH-friendly? I would love to believe that. I do think we can get majority support from BCH-friendly miners for a plan. I would be very surprised if we could get a majority of all of the Bitcoins' miners to agree to support BCH developers.

I believe it was anti-BCH forces dividing the the BCH community the last week or so that stopped the original plan. The plan was full of unsettled issues and the attackers used the uncertainties to spread false assumptions about what was going to happen. Anyway, unless most of all the Bitcoins' hash is BCH-friendly I think we will need to be very wary because the anti-BCH forces are still circling and looking for weaknesses to divide out community further.

They are good at pretending they are a part of the BCH community and that they represent a majority view even though they work for dark money that hates BCH and are not real people with real opinions (rather they are mostly professionally implemented social engineering agents).

They are very good at ensnaring and enlisting real people into their web of lies. But, of course, not all anti-plan voices are anti-BCH and not all of the pro-BCH opposition is under the influence of the "trolls". I never intend to suggest that even though the trolls like to pretend that is what I am saying.

I hope BCH-Friendly hash is the majority because these social engineers will make gathering support very difficult even if it is a great thing for BCH and the BCH community. IMO, even if it is known to be good for BTC and BCH, there will be attacks from those who cannot stand supporting BCH developers.

$ 0.00
4 years ago