BUIP143: (passed) Refuse the Coinbase Tax

[theZerg]

BUIP143: Refuse the coinbase tax
Submitted by: Andrew Stone
Date: 2020/01/27


Background

A part of the BCH ecosystem proposes to enforce a percentage of the coinbase mining reward being allocated to whitelist addresses. Eventually, any mined block not making such an allocation is to be orphaned in order to ensure 100% compliance on the most-work chain. Hence, this allocation becomes involuntary and can be considered a “coinbase tax”.

In this BUIP I am asking you to make the most important decision in the history of Bitcoin Unlimited. I am asking you to vote to disallow any coinbase tax in the Bitcoin Unlimited full node with the effect of forking from any blockchain that requires such.


Why should we do this?

Philosophically, a mandatory tax undermines the voluntary and capitalist principles of Bitcoin. The practical effect of this tax will be to introduce fiscal policy to Bitcoin Cash, and indefinitely sustain a power structure, effectively a BCH government, that is answerable to no one. This, essentially political money with no clear disbursement process, will go to people who are excellent at politics and social media presence rather than those who are rewarded in the capitalist system. History is replete with examples of how such funds are inefficiently utilized or misused to the detriment of the host societies. In contrast, those who practice sound capitalist business and engineering practices succeed and therefore do not need such a tax in the first place.

Applying this philosophy to BCH, this tax can be used to indefinitely sustain inept development or no development whatsoever since payments are not ultimately earned through the production of real value. In contrast, multiple systems can and are used to solve this problem in existing successful projects today. For example, a system similar to other open source communities, and/or an entrepreneurial system where start up companies fund development and maintenance of features can simultaneously be employed.

Rather than sustain a regime through taxation force, the Bitcoin Unlimited and BCH community should deny the creation of a centralized and opaque power structure, instead allowing the capitalist process to do what it does best -- reward success.


Technical Implications

By passing this BUIP the BU developers are authorised by the membership to release a BCH full node client which prevents the enforcement of a coinbase tax. The risks are accepted that a new and persistent BCH fork is a possibility. The responsibility for such an outcome, damaging to network effect, lies with those who are beneficiaries of the coinbase tax.


Budget

No extra expenditure is envisaged above pre-existing funded development.

2/17 edit & formatting.

 

[AdrianX]

A founding principle in BU discusses this. While I'd reword it with the luxury of hindsight, it's still relevant.

https://www.bitcoinunlimited.info/resources/BUarticles.pdf

Governed by the code, we run.

And

The solution to the funding problem is also discussed in the document linked above.

Article 4: The Bitcoin Unlimited Mining Pool

The solution, in principle, is defined in Article 4, the source for development revenue.

What ABC should do is make this tax optional they should make the ABC implementation pay the 12.5% developer service fee to their wallet and let miners chose which application they want to run. Their roadmap is voluntary, after all.

If ABC is a fly by night team of yahoos who've bitten off more than they can chew, they don't need to destroy BCH. They can look to BU a group of people who participated in thinking through these issues well before ABC even considered the consequences of their actions.

Then there is also the option to move back to BSV, a chain that does not seem to be run by cleptomaniacs.

 

[Norway]

In this BUIP I am asking you to make the most important decision in the history of Bitcoin Unlimited.

No, this is not the most important decision in the history of BU. That was the decision to drop support for BSV. BCH is a dead man walking, regardless of this vote. A persistent split of BCH will only result in two dead men walking.

 

[Zarathustra]

> This, essentially political money with no clear disbursement process, will go to people who are excellent at politics and social media presence rather than those who are rewarded in the capitalist system.

Ironically, the payment process within the BU project is also unclear, and this sad fact gives the number one bitcoin saboteur unnecessary food for his agitation on social media.

 

[digitsu]

This is why you lost the plot when you went grass roots instead of serving the BUSINESSES. Because the BUSINESSES (yes big corps) are necessary for capitalism to work. In order for people to be rewarded in a capitalist system, you need to have the business class. Because they are the ones that can pay for development, because their businesses SERVE and profit from those OUTSIDE the bitcoin system. So it is a net source of external capital and value. Without businesses, if Bitcoin (like what BCH became along with BTC) is just a bunch of neckbeards technocrats writing stuff to serve the end users, who have nothing better to use the platform for that to send to other end users. It is a closed loop system with a static amount of value, just recirculated internally. This doesn't work, because as long as businesses control which form of payments they will accept, as long as not everyone in the world value your internal funny money equivalently, then businesses won't accept it for payments. So you have the biggest chicken and the egg problem in the history of mankind. The bootstrapping of a coin, which is technically worthless, until everyone in the world values it, at which point it is instantly valuable.

Good luck with that! King's and Queen's and Emperors have tried this in the past, and it has never worked. (and they had the military might to force adoption... you don't). Capitalism is about CAPITAL.If you don't let capital IN, and give it fertile environment to GROW, then it leaves, and you end up with the bullies starting to hussle and steal what value the ecosystem has left over in order to survive in an revolutionary mad grab for resources. Communism.


That being said, its good to see that you have finally grown a pair and are standing up to the anarchist/communist bullies. I will support this BUIP.

 

[AdrianX]

@digitsu people too often get hung up on words at the expense of the principles.

In Craig's latest interview, he makes a needed distinction between entrepreneurial capitalism and corporate capitalism. Only one is pro-business, the other only superficially so, the world we have is governed by corporations, we're moving away from that to a world where everyone is playing by the same rulebook (a protocol set in stone).

BCH is not attractive to entrepreneurs or businesses as it's unstable, exposing businesses to the risk they may have the rug pulled from under them, BSV is a platform to build on precisely because it's not going to change the rules.

BSV is more anarchic than BCH, Amaury and his ilk are more akin to authoritarian communists than anarchists.

What 99% of the modern world called capitalism is quite removed from what Craig and Friedrich Hayek call capitalism. In fact, what Craig calls capitalism is closer to Anarchism than than what the majority understand when Craig says the word capitalism.

When Craig says he hates anarchists I totally agree with the ideas he's opposed too; I don't advocate for that type of chaos either even though I identify as an anarchist. BSV is apolitical.

 

[freetrader]

From https://memo.cash/post/590948a27604ddcaea70a2c690d809c7ef12d7f84d888ccefb9087565bfc725f .

Below is an unrolled version of the thread, which I will decorate with some more thoughts (italicized) or references since this forum allows for longer posts.

What I don't like about BUIP143 is that some BU devs want it to give them "carte blanche" to do a soft-fork against donation addresses.
[Note: I have seen several comments confirming this attitude, both by OP and by Greg Griffith. Please understand that I think it's your right to suggest and even threaten with this, but I don't think it's wise. Hence this thread]

I'm not at all sure that's needed, or a prudent countermeasure.

I know the IFP proposal seems to be losing support, but let's examine theoretically if BTC.top & others went ahead and set up their plan & code in ABC to pay to a HK fund address.

Now imagine BU sets up their code using BUIP143 as justification to soft-fork in a rule which orphans any blocks containing the "HK fund address(es)" advertised in ABC code.

A lot has been said about "optics" of the IFP proposal (tax-like, non-debate theory etc).

But what about the optics of adding a address-based blacklist to BCH (BU) code?
Not good!

If we want to keep a "tax free", non-discriminatory incentive structure on BCH, I'm not for such a blacklist, and I am contemplating putting up a counter-BUIP to express that.

Blacklists don't work well.

"The cartel" could make their code have a flexible mechanism, distributing "approved" donation addresses among their members (pools, exchanges etc).

One possible BU defense would be a further SF to restrict CB [Ed: generalize to: transaction] outputs to a address, but I'm sure you can see how that would be another bad move (think existing donations & optics).

As I see it, such soft-forks would work against the ideals of BU to bolster and not to degrade the existing p2p cash system.

[Ed: "If"] I opened another BUIP, it would ask to release a May version that contains any non-controversial updates, but simply not include orphaning based on some involuntary CB [Ed: generalize to: transaction] payouts.

In other words, to do on BU what this article [Ed: link below] is proposing to do with the ABC codebase in such a case:

https://read.cash/@SharkySharkdog/you-lead-and-maybe-i-will-follow-ff383504

Finally, another major reason not to go down the road to blacklisting any coinbase [Ed: generalize to: transaction] outputs:

I believe it would open the door to more requests from regulators / governments. Eeek.

Link to Memo poll on whether I should open another BUIP unless BUIP143 is amended:

https://memo.cash/post/05213910f1d09a05b781efaa75f12b1d8352ee99b58db70942c6c33a966845e6

 

[freetrader]

Blacklists don't work well.

I'd like to expand on that.

Firstly, I think it leads to cat & mouse or "whack-a-mole" games.
One side coerces, the other censors, the first introduces a different address, the other side needs to adapt their blacklist etc.

Checkpoints don't solve this. (majority hashpower does)

You end up with the need for a counter-cartel to coordinate the update of blacklists.

This becomes an organization (or a set of members) that can be approached by regulators if it demonstrates aptitude at censoring the blockchain.

 

[Griffith]

@freetrader Where did you get the idea that we would blacklist an address from? There are much more effective ways to soft fork than doing that.

We could specifically invalidate their first fork block by adding a checkpoint to ours.
We could change the MTP of the HF changes making our chain incompatible with the tax one and then add some basic replay protection.

To be honest, blacklisting addresses was the one thing that was not on the table. It goes against a lot of peoples personal beliefs on censorship and the like. We know the technical details were lacking but that is only because details on how to enforce the tax were lacking

 

[freetrader]

@Griffith I appreciate that it's early days w.r.t. technical details, but let me cite some comments I read in the Reddit thread which I followed, which directly gave me impetus to make my commentary above.




Andrew's statement which compelled me to comment was

I am asking you to vote to disallow any coinbase tax in the Bitcoin Unlimited full node with the effect of forking from any blockchain that requires such.

Which is fairly broad, so I thought it appropriate to comment as I did. Even if BU hatches a plan that doesn't need to censor based on a coinbase scheme, the other side can decide to add some other consensus rule like "there must be at least one non-coinbase-output in the block that pays to <HKcorp>", I would still oppose adding code to BU to censor blocks based on such because it would of course be futile. Payments can be broken up into arbitrary amounts and collection and enforcement coordinated by a cartel if they wanted to go to such lengths for their chain.

Guess the point I'm trying hard to make here is: BU cannot technically block the other side if the other side wants to coerce, and it is folly to try.

BU's only hope - with some ad-hoc technical measures to possibly assist staying on a clean chain and fend off attacks which could recur - is to eventually get more hashpower or sufficient hashpower and have the other side drop attacks they may try to conduct.

I'm glad that it seems I was mistaken in interpreting your statements as giving enough leeway for some kind of address-based censorship.

For now, I'll wait, like you, to see what the other parties want to cook up in terms of a technical proposal.

If this BUIP ends up being used to possibly justify code changes which amount to any kind of technical censorship, I'll ask the membership via another BUIP to keep the code censorship free.

We could specifically invalidate their first fork block by adding a checkpoint to ours.

This would open the Whack-a-Mole games.

We could change the MTP of the HF changes making our chain incompatible with the tax one

Maybe, not entirely sure what you mean but I'll happily wait until (if) changes are required and released, and will re-evaluate my stance on feasibility if and when that happens ;-)

and then add some basic replay protection.

Significant hit to light wallets who want to support this. Would avoid, but one would need to see what the options are.

 

[solex]

I see this BUIP as a valuable statement of intent, seeking membership support for a course of action. It has to be high-level at this time.

For now, I'll wait, like you, to see what the other parties want to cook up in terms of a technical proposal.

Absolutely, this is the next step, to see what technical proposal appears. Though, like the rolling checkpoint change, we can't really expect any kind of specification to be written and be made public beforehand.

If this BUIP ends up being used to possibly justify code changes which amount to any kind of technical censorship, I'll ask the membership via another BUIP to keep the code censorship free.

After all these years, it should be apparent that BU is against technical censorship. The infamous 1MB even falls into that category, where the overcoming of it was a founding impetus.

At the end of the day, I hope the coinbase tax idea will be dropped permanently and the community moves forward. Only those prepared to risk splitting BCH yet again will keep the proposal alive.

 

[freetrader]

After all these years, it should be apparent that BU is against technical censorship.

I am mildly relieved to see respected voices from BU re-iterate this.

Though, like the rolling checkpoint change, we can't really expect any kind of specification to be written and be made public beforehand.

No, we absolutely can, and will, expect that.

In this case, we are talking about an impact to the whole ecosystem by a soft fork which could trigger another hash war (e.g. by SHA256 miners from other chains who feel unfairly impacted by the tax).
The ecosystem should absolutely demand to see technical requirements of the proposal before they decide to go along with a consensus change of the proposed nature. It would be cRaZY not to.
Very disruptive compared to the 2018 BSV split.

At the end of the day, I hope the coinbase tax idea will be dropped permanently and the community moves forward.

This is my hope too. Many good alternatives have been floated.

 

[theZerg]

Looks like the tax idea has not been dropped so this BUIP is important again. The BUIP was broadly written to give us the ability to react to what may be a very dynamic situation. And I stand by that -- we may need to react quickly. And the BUIP process, which includes non technical members was not meant to handle the nitty-gritty technical details of proposals, which is why, for example after BUIP055 was passed, freetrader wrote an actual specification for the fork.

I also dislike the idea of blacklisting on practical and ideological grounds, yet dislike the idea of this tax more. Its pretty ugly to have to determine which thing is less bad.

Luckily, the tax proposal looks to be predicated on BIP9 voting. If its "normal" BIP9 there is a grace period after activation. If this grace period happens, if we know that the tax begins on block or date XXXX, there are lots of options that won't involve a blacklist.

 

[solex]

The next vote is announced and this BUIP is being included for the minimum reason of time criticality.

 

[freetrader]

Luckily, the tax proposal looks to be predicated on BIP9 voting. If its "normal" BIP9 there is a grace period after activation. If this grace period happens, if we know that the tax begins on block or date XXXX, there are lots of options that won't involve a blacklist.

As coded it is not "normal" BIP9 because they removed 95% fixed threshold, and who knows what else they might change.
There is no counting on there being a grace period.

Thanks @solex for including this BUIP, and @theZerg for raising it.

 

[torusJKL]

I understand that from a game theoretic point of view the non-Tax chain would be at a disadvantage if blocks with the tax were not to be orphaned.

But I dislike the idea to actively restrict others to do with their money how they please.

 

[theZerg]

Although we need to see exactly what ABC does before coming up with a fully baked proposal, let me propose that we use the exact same BIP-9 like voting trigger and bits to create the no-tax chain. Voting for the tax simultaneously votes for a no-tax fork and if one activates, both do.

Without giving up the BCH name (which IMHO should go the no-tax branch for not undermining the essential properties of the blockchain, but realistically will likely go to the majority hash), we can change the forkid as a courtesy to users and exchanges. This will also make the fork persistent -- the two forks won't reorganize to whichever has the majority hash.

The only negative aspect in changing the forkid is that we "lose" the un-updated light clients. But we have significant light client support so I think we can rely on them to be updated.

 

[TierNolan]

From here, it looks like it adds up to 4 addresses to a whitelist and each option has a 66% miner threshold to be enabled (here).

The mining code pays to the first item on the whitelist. I assume the intention is that miners could just change that code.

The validation code checks if there is at least one coinbase output that pays to a whitelisted address. It doesn't appear that you can split the payment over multiple white listed options.

There are 4 whitelisted addresses.

static const CTxDestination &GetMinerFundDestination()
static const CTxDestination &GetMinerABCDestination()
static const CTxDestination &GetMinerBCHDDestination()
static const CTxDestination &GetMinerElectronCashDestination()

I assume the first one is the Hong Kong trustee address and the others are for leaders of their respective projects?

 

[solex]

True, but it really is an academic exercise to determine who is the beneficial owner of those addresses. Ultimately, the community has to take it on trust that the funds received on them will be spent on BCH improvements/infrastructure, leaving aside whether those improvements are value for money. Many observers have pointed out that BCH as it stands can handle blocks up to 32MB. By the time blocks are this size from organic adoption, the worldwide community will be far larger and far more funds will accrue to developers from voluntary contributions.

Assuming activation, the actual percentage spent on BCH improvements will be anywhere from 0% to 100%. From a pure mining perspective, "insider" miners could have their 5% refunded while "outsider" miners don't. This possibility alone arises from the plan's simplistic architecture.

Fundamentally, what makes Bitcoin a historic breakthrough is removing the layer of 3rd party trust in electronic money: "digital gold". The key to it is decentralization. I know the word has been attacked a lot in recent years. but it is still most accurate to describe how it must work.

If the BCH community is to trust the owners of a bunch of addresses, then they might as well use something like XRP, which has the same increased level of trust, where it is centrally managed, but the community has promises of good behaviour from the management.

 

[cypherblock]

Just immediately invalidate any block that votes for IFP. No blacklists. Launch on same date as their release. Any BIP9 version bits that vote for IFP are invalid blocks. Done.