BUIP144: Voluntary pay out to config list of addresses from mined block coinbases

[freetrader]

BUIP144 Voluntary pay out to config list of addresses from mined block coinbases
Submitted by: freetrader
Date: 25 Jan 2020

Background & Motivation

Recently, a consortium of miners have proposed a funding scheme which would divert a certain percentage of Bitcoin Cash coinbase rewards to a development fund.
This scheme has been controversial.

I would propose this BUIP as a potentially less controversial and more decentralized alternative for client software (here BU) to obtain a funding stream from Bitcoin Cash miners who use their software.
If other client softwares followed suit with similar features, the client development projects might garner sufficient miner funding without a need for coercive measures at protocol level.

Technical scope
This BUIP would propose to implement the following:

1. List of optional, additional payout addresses and associated percentage of block reward
   • configuration via additional config file or new parameters in existing (TBD)
     
   • each address would need to be a valid, either CashAddr or legacy format
     
   • each address must come with an associated percentage in the range 0.00 - 50.00 %
   • sum of percentage not to exceed 100% in any case
   • the remaining output gets 100% - (the sum of configured additional %) of the block reward
     
   • any addresses configured to 0% must be ignored
   • RPC call to inspect payout addresses and their percentages
   • default configuration with a BU treasury address and a TBD percentage (recommendation up for discussion in this BUIP: 3% of block reward)
2. Testing
   • Unit and regtests
3. Documentation
   • goes without saying that this should be a clearly marked out and well documented mechanism, both in the software docs and also in Release Notes, probably some blog posts on the matter so that no BU miners are blindsided

Project Duration
Expedited to complete before next planned BCH upgrade in 15 May 2020.

Budget
If the work is done by BU salaried devs, no extra budget to be assigned.

If it's to be done by non-BU-salaried devs, suitable budget must be discussed. Since this work is in relatively critical areas of the client, a starting budget suggestion of $5,000 is proposed here for further discussion.

 

[freetrader]

@solex , could I get a BUIP number assigned for this please? Thanks!

 

[Griffith]

@freetrader if we ignore the fact that a super majority of the miners use the ABC client so this would be mostly useless if not entirely useless in the other node implementations.

A miner can already trivially add additional outputs to the coinbase transactions. Most of the development groups already have or can easily provide public donation addresses. What is the point of all of this extra code?

 

[digitsu]

1) as @Griffith already mentioned, miners can already do this form of voluntary donations, by adding outputs to coinbase
2) putting BU donation address as a default seems to be the only benefit of this change,
3) but as most if not all miners are running ABC, even this subtle change is ineffectual.
4) this change is not meaningful enough to entice any miners to change from ABC to using BU.

Miners, as an economic block, operate on consensus. Whether PoW, or emergent consensus. This change provides neither. Therefore, in the general sense neither serves any purpose nor brings any meaningful new feature to the miners. At best, it will be run by about half of the 'full nodes' (non-mining nodes) in the network, and eventually these nodes will be phased out by more purposeful nodes anyway so won't likely have any real impact.

The only real nodes in the network are the mining nodes. The 'full-nodes' are economically impotent servers that are a vestige of the system after mining specialized to server farms and ASICs. People who run them now, are either 1) using it like a 'blunt hammer' to fill the space of a business bitcoin SPV server for the time being, which will only download the transactions that concern your business, 2) doing it because of a false believe that verifying everyone else's transactions and rejecting ones that you don't think are valid has some effect on the network or is part of some mythical 'decentralized mechanism of checks and balances'.

The former will eventually move on to specialized servers that filter a subset of the blockchain and transaction stream (like BitCom/Planaria) which will server businesses. The latter will eventually run out of money, realizing that what they are doing is meaningless and just a sham perpetuated by Blockstream and other proponents that want to program the public to think that non-mining nodes take part** in the consensus process to take away from the importance of miners (as blockstream develops 'decentralized network node' solutions, and are not miners)

** the role that they believe that non-mining nodes fill is one that is similar to the proletariat in a communist society. The idea that those in power (the miners, government) if they abuse the people, the people, as a whole, can rise up and overthrow the miners. So the non-mining nodes only have power if they act all together. Unfortunately, the unwashed masses have the logistical problem of mobilizing to act all together. So they always need some leaders to drive them. These leaders inevitably become the new dictators post-revolution. The only way to avoid this is to have non-mining node interests be championed by businesses that have real (outside) revenue streams, (what we have been terming "Economic Nodes" or "Economically significant" nodes, such as exchanges, etc).
Strangely enough, if economic nodes wanted something done, they would just pay for it themselves. So would not need any miner approval.

So the question here is whether MINERs need extensive/continual development work done at all?

 

[freetrader]

@freetrader if we ignore the fact that a super majority of the miners use the ABC client so this would be mostly useless if not entirely useless in the other node implementations.

Setting aside the fact that I'm always interested in reliable numbers about this, I don't see how the concept would be "mostly useless, if not entirely useless" in other node implementations.
From what I heard other implementations are interested in obtaining funding.
If they received funding even roughly in proportion to their use by miners, what you have said leads me to conclude that ABC might benefit even more if they implemented an easy feature to configure such donations. I have no reliable data on the use of other implementations in mining, versus BU, so I must premise this on your statement that "a super majority of the miners use the ABC client".

Whatever the current situation, in my view, BU should not abandon obtaining a healthy share of the mining market.

A miner can already trivially add additional outputs to the coinbase transactions. Most of the development groups already have or can easily provide public donation addresses. What is the point of all of this extra code?

The code has not been written, I would not assume the changes to be extensive, though they must be made carefully.

The point, plainly, would be to generate income flows for BU.

It would become more turnkey for miners to receive a block template with a coinbase transaction which already includes an outputto contribute towards BU development & support given to miners.

I have addressed some additional points on how I see this scheme being advantageous, in the header of a discussion post here:

https://www.reddit.com/r/btc/comments/etxna9/buip_to_allow_voluntary_miner_payouts_from_blocks/

I would like to draw some attention on the following mentioned there:

Fourth, why should a miner/pool need to donate 12,5% of their coinbase to spend on e.g. 4 dev teams when they might want to support only the dev team of their choice, which might only get 3% (~ 1/4) of the 12,5% anyway. This proposal might save them the 9% spent on developers they do not want to support. There is a fairness principle here - pay for the service that you use or you want to use. Not pay for services you do not use or want. I think this has been neglected in the conversation so far.

 

[jtoomim]

The coinbase transaction is generally created by pool software, not by bitcoind. This feature does not belong in BU at all. There is, technically speaking, no reasonable way to implement this in BU (or ABC) without turning BU into a pool server itself.

On the other hand, requiring a donation in order for a block to be valid is within the domain of bitcoind (e.g. BU). But since you're not proposing that, there's nothing for BU to do.

As a side note, if you take a look at BU's donation address, you might notice that P2Pool has already been donating a percentage of every coinbase to BU since July '19:

https://bch.btc.com/36XTMVtgJqqNYymsSvRonpUsbZRGkm1jvX

 

[freetrader]

Bitcoin Unlimited is based on the Satoshi codebase, so it is a drop in replacement for your mining pool software. Simply configure your pool to point to the Bitcoin Unlimited daemon, in the exact same manner you would for the Bitcoin Core daemon.

jtoomim, does pool software not obtain the block template from BU and then update it as needed?

And is this custom software in the case of your pool, to calculate a percentage and include it?

This BUIP would simply provide a template coinbase to the pool software which already includes the amounts for desired percentages of whatever addresses the miner wished to add, defaulting to only BU's address.

I don't see this as comparable to "turning BU into a pool server" much more than it already is.

But if you all find that this feature is completely unnecessary because all pool software allows easy addition of outputs with specified percentages, then I urge you to just vote to reject the BUIP.

 

[jtoomim]

The block template contains the header and all of the transactions in the block except the coinbase transaction. Pool software assembles the coinbase transaction, adding one or two extranonce values into the coinbase message (plus whatever other data or text the pool wants to stick there), then sends that package of date to mining hardware. The mining hardware increments the nonce value in the block header and (usually) the second nonce value in the coinbase transaction as necessary until a block (or share) is found.

There is an optional "coinbasetxn" mode in BIP23 and the getblocktemplate API spec that adds a template coinbase transaction to the getblocktemplate results, but no pool software actually uses this. It is not currently implemented in Bitcoin Core, ABC, or BU.

It will be more work to change pool software to take BU's suggested coinbase txn and modify it according to the pool's needs than to modify the existing pool software code to include an additional output to another address. Such a strategy would also result in the new code only working with BU, so if the pool software wants to be able to work with other bitcoinds as well (e.g. ABC), then it would still need to have the code for creating the coinbase txn from scratch. Having two code paths for one function is undesirable.

> And is this custom software in the case of your pool, to calculate a percentage and include it?

https://github.com/jtoomim/p2pool/blame/master/p2pool/main.py#L544

That feature has been in p2pool for 8 years.

 

[freetrader]

Thanks @jtoomim for the clarifications.

Noting from your Reddit response to my query that p2pool also does not use BU's getminingcandidate and submitminingsolution RPC calls.

Which is what I was assuming was in use with some miners/pools.

If that's not the case, I think it would substantially reduce the utility of this BUIP.

 

[solex]

@jtoomim
I want to take the opportunity to publicly thank you and p2pool for your continued donations in support of the BU org.

@freetrader
I see the how this is a voluntary alternative to the recent miner cartel proposal. It would benefit from slightly clearer language in the title . e.g.
BUIP??? Voluntary miner pay out to config list of addresses from mined block coinbases.

However, I also note from the feedback that this change, applied to the BU client, may not get much, if any, miner usage. So, I suggest we leave it for further discussion at the present time. I will assign a BUIP number if further changes are suggested such that you conclude it will be worthwhile of development time and money.

Further feedback from @theZerg is also welcome.

 

[freetrader]

I've added the "Voluntary" to the title.

Could you please assign a BUIP number, even if it is not put up for voting yet, @solex.

I don't like talking about things without a proper designator, and this proposal, while I may not believe it worth putting forward for a vote at this time, is technically already self contained.

If someone does not like it technically, they can put forward their own BUIP.

 

[solex]

Certainly. Reference 144 is assigned.

 

[freetrader]

Thank you @solex

 

[solex]

@freetrader, the next vote is announced, you can have this included if you consider it ready.

 

[freetrader]

@solex, after taking all feedback into account, I think this BUIP is not needed at this time, indeed it might use effort that could be needed in other areas like BUIP143.

I hereby withdraw it.

Miners / pools are encouraged to continue voluntarily donating from their coinbase outptus as they see fit (and in some cases are already doing - thanks!), or otherwise use the excellent features of the Bitcoin protocol to donate from subsequent transactions building on their blocks.