CHIP 2021-05 Minimum Fee Rate Voting Via Versionbits

freetrader · June 6, 2021, 12:44am

[…] a minimum relay fee adjustment mechanism driven by miner voting in block header version bits 11 and 12. This will allow hashpower to express a fee adjustment preference: increase, decrease or no change to the relay fee.

The votes would be evaluated at regular intervals by full nodes and other software such as SPV wallets. A minimum relay fee change would happen if 75% or more of blocks within the last 1,008 voted in its favor. The votes would be evaluated approximately once a week, or more exactly: whenever the block height is an integer multiple of 1,008.

Fee adjustments would be made in steps of 25% of the prior fee rate.

This is a draft of this specification. There are still plenty of rough edges, some of which I know about and may correct later today, and others on receiving your comments.

Review and feedback are appreciated!

Update 2021-06-06: updated to draft v0.2

Changes in v0.2:

switch to simple majority of >= 505/1008 blocks
add REQ-MINFEE-ACTIVATION-ANCHOR
(to set starting fee to 1000 sat/kB when the CHIP first calculates)
add risk of miners rejecting the responsibility to manage relay fees
add risk of excessive fee rate granularity
add risk of reduced fee rate stability
update the projected fee table to use 500 sat/kB for typical txns
rename REQ-MINFEE-ACTIVATION to REQ-MINFEE-ACTIVATION-FLUSH
spell check fixes
update references, acknowledgments, timelines

emergent_reasons · May 30, 2021, 2:03am

Before I do a full review of this CHIP, I just want to point out something I noticed that I think is important. A big part of the CHIP process is having it serve as a guiding rail that focuses on careful consideration of economic, technical and other aspects, leaving less room for half-assery on a network that needs to serve billions of people.

In that context, I deeply appreciate that @freetrader dedicated so much space to these difficult topics that go beyond “good idea” and get into the gritty work needed to understand if the idea will work in the real world.

MaxHastings · May 30, 2021, 5:06am

First I want to thank you for putting this CHIP together.

One concern I have is how the miners feel about having the responsibility to change fee policy. Is this something they want to control? Cause I foresee a couple of hypothetical scenarios that may play out if miners are responsible for the fee policy.

Miners may not bother changing fee policy and will have to be pressured by users, devs, or businesses to change it.
Miners may accidentally change the fee policy too low and increase the risk of spam transactions. And again they would have to be contacted by users, devs, or businesses to change it.
Miners may not want this responsibility and be annoyed that they now have to micro manage fee policy and be under constant pressure from users and businesses.

(1) (2) are already accounted for under the Risk Mitigations section. I would like to add (3) to it.

im_uname · May 30, 2021, 5:26am

Given that minrelayfees are now local (even though an observable “prevailing” default exists), how do adjustments start under this scheme?

Do we define an absolute “anchor” of some sort, perhaps at activation, of 1000sats/kb? If that is the case, it might be useful to write into specs.

In case we do have an anchor there, to determine prevailing fee from miner vote, is a given client expected to calculate current default fee from reading all the headers between that anchor and the current block (collecting all adjustment vote information), or is there some more elegant way?

ShadowOfHarbringer · May 30, 2021, 7:44am

Ideas like BMP, and miners voting to decide on relay fees might work, if miners become more active participants in this ecosystem.

So far unfortunately, miners are not active and instead are just installing whatever code developers produce without giving it much thinking.

This could be useful as an helper mechanism, but will it really solve the ultimate elephant in the room-type problem? I don’t think so.

But perhaps I am wrong.

Change my mind.

im_uname · May 30, 2021, 8:29am

In the very worst case, even if all miners are completely passive and always run default, this coordination mechanism (or something similar) will help node teams push default fee level updates at a higher frequency than the “everyone must upgrade” yearly consensus update window. You only have to persuade pools to update their software with a new default (perhaps in a new version) to change prevailing fee.

Not the most ideal situation by a long long shot, but still solves a practical problem.

freetrader · May 30, 2021, 8:43am

Thank you for the review. I will add your point (3) to the document, it is an certainly an open question.

I very much invite miners / pools to review the document and let me / the community know what they think about it.

Perhaps something I didn’t mention explicitly is that I think they already have the infrastructure to set those versionbits, so this wouldn’t require new code on their end. And they already have experience with this kind of voting through BIPs.

They would be put into more of a deciding position w.r.t. the network fees though. But I think that even when this is used, it would be need only infrequent adjustment on their end.
How I see this mechanism being used:

Either a pool comes to the decision that fees need to move itself, or via input from its customers or from discussion in the wider Bitcoin Cash ecosystem.
The pool itself should be persuaded that it is in the long term interests of both BCH and itself to adjust the fees. This depends whether people present a good case for moving the fee.
If the pool is not convinced of a need to change the fees, then it would simply do nothing.
If the pool wants to participate in a fee movement, it should select its own a fee target (based on the discussion and taking into account their own minimum fee requirements, and hopefully comparing fees to other competitor currencies and).
Every pool would decide its own fee target and set its voting direction accordingly (based on whether the target represents an increase or decrease from the current fee).
Once decided, the y keep the vote setting in until the fee has dropped to at or below the target. This may take a long time. They would only need to change their voting settings if they have some internal discussion to modify the target and if they would need to vote differently to reach the new target.
Once the target is reached by the network, they set back to “00” (No Change) and wait until they see a need again (back to step 1)

im_uname · May 30, 2021, 8:51am

Note that while the onchain signaling can be relative to facilitate gradual changes, imo RPC-wise it might be be easier and more robust for pools to handle if they can explicitly adjust a “target”. Relative adjustments specifically has the property where a one-time adjustment motivated by price increases or social discussion, if left alone as interest wanes, can result in the fee floor continuing to go up or down until it gets unreasonable enough for social pressure to push miners to change their settings again.

One possible implementation would be:

A config line feevote= is used to indicate a desired target minfee, in sats/kb.
If feevote is higher than current prevailing relay fee by 25% or more, the vote is 01 (decrease).
If feevote is lower than current prevailing relay fee by 25% or more, the vote is 10 (increase).
if feevote is differs from current prevailing relay fee by less than 25%, the vote is 00 (no change).

At the beginning, if unspecified, feevote is set to a default value of 1000.

freetrader · May 30, 2021, 8:51am

Thanks, good point. I need to update the document.

Yes, I was indeed assuming a starting level of 1000 sat/kB, so that needs to be made explicit.

In case we do have an anchor there, to determine prevailing fee from miner vote, is a given client expected to calculate current default fee from reading all the headers between that anchor and the current block (collecting all adjustment vote information), or is there some more elegant way?

They would need to scan the headers, but they might not need to read all the headers.

I briefly mentioned a scheme where they can cache the fee value at the most recent finalized block, but they could also add some a fee checkpoints for old blocks or at least cache a recent finalized blockheight to their application and then only need to scan from that checkpoint up to tip.

I’ll review to see where I can make that clearer in the spec.

freetrader · May 30, 2021, 9:17am

I like this suggestion, I will create an “Implementation Suggestions” section and add it there!

(I probably need such a section anyway for the vote caching topic etc.)

tom · May 30, 2021, 9:54am

The problem with voting and any majority-based system is that it is unfair to innovators. It is unfair to new entrants to the market that are cheaper and more competitive in that they are not able to out-compete their worse competitors.

Consider: when 10% of the hashpower is having signficantly lower cost, they will never be able to get the end users to profit from that, and market disruption by better innovators will at best be delayed.

Is it not much better to push for double spend proofs to be included in major point of sale systems and wallets? We have a year to get that stable before this CHIP can land anyway, and then there is no longer a need to introduce any centralized system for setting a open market property like fees.

I’m extremely reluctant with any CHIP that introduces centralized control (in this case the majority hashpower) over free market properties. The existance of this CHIP is a strong proof that this is a slippery slope that was started with the centralized decision to have 1-sat mninimum and instread of letting go of this control the CHIP has the idea to add an extra layer of control.

Look at history, this is not unique. The following video explains the ever expanding control system of the early innovators of the train systems in the USA, notice that such systems always stay longer than is healthy.

proteusguy · May 30, 2021, 9:59am

Geepers that appendix!

My initial gut response is that I’m curious as heck to see whether the miners will actually participate in governance of fees if given such a lever and it’s well constrained enough that I don’t see any harm in letting them try.

I’m also quite curious to hear more about resuming “days burned/destroyed” as a mechanism for prioritizing transactions as a separate mechanism.

So - I support the CHIP as written thus far.

freetrader · May 30, 2021, 10:17am

Consider: when 10% of the hashpower is having signficantly lower cost, they will never be able to get the end users to profit from that, and market disruption by better innovators will at best be delayed.

Hmm, they can do what they could already do on today’s network, no?

Advertise their nodes where people could submit cheaper transactions, which their pool would mine. Since these transactions would not propagate well to other nodes, but still be valid, their pool would essentially be capturing a slice of the traffic for themselves.

Granted, this might come with some unhealthy side effects, which I guess this CHIP is intended to avoid.

But the free market is still at work.

Users / applications would (in theory) gravitate to the cheaper service provider.

They would end up mining more transactions than other pools, collecting a bigger slice of the fees. This either forces the network fees down as other pools react, or the cheaper pool gets more income and is able to attract more hashpower (because they can incentivize miners better with some portion of the extra money they collect from transactions).

Either way over time the cheaper pool causes a market reaction by the other pools who want to stay competitive and not lose hashrate.

Maybe my view is a little simplistic here, but I think a point I’d like to make is this CHIP is a compromise solution which is purely voluntary (not consensus), and anyone who feels that the minimum fee set by it is too high and they can provide service cheaper, is not prevented from doing so!

Thanks for the reading suggestion, it sounds like a great topic and I’ll give it a read!

proteusguy · May 30, 2021, 10:25am

@tom , agree with your concerns and principles but not so certain about the magnitude of the issue. It clicks on my rational brain but not my empiricist one.

We really need to address how overloaded the term “centralized” is in our conversations about consensus - especially by better clarifying magnitude and scope. It’s often just used as a “dirty” word that means bad for the most part - typically justified when real practical centralization occurs, but sometimes not so when it appears to be a theoretical notion of direction rather than destination. Would be nice if we could come up with new terms that better delineated this dimension & spectrum so the term could become more nuance and useful rather than result in the end of thought as it often does (intentional or otherwise).

If we believe that POW miners is a decentralized mechanism than how can providing one lever signal to indicate a position regarding the value/cost consideration of the service they provide be considered as being centralized or moving towards centralization on any practical basis? It seems that before this lever could actually be manifested as having any negative centralization side-effects that the actual majority control of our mining pools will have far more severe consequences beyond this. Am I missing some other aspect of it possibly leading to more centralization than that? So long as miners are independent of the transactions in which they add to the blocks then POW is the strongest known decentralized consensus system there is. I don’t see this CHIP altering that relationship.

To your example - BCH transactors could benefit from a 10% hashpower advantage by those miners A) going ahead and mining bigger blocks (assuming frequent demands so the mempool is often not cleared each block). B) Other miners would then have an incentive to reduce per tx prices in order to increase the qty of txs so there would be more for them when they win blocks. A would benefit all users regardless of whether or not B manifests. I believe the conditions for A are present today and unchanged by this CHIP whereas this CHIP enables B which is not an option today.

What becomes the alternative solution you propose that provides an additional benefit otherwise if one set of miners suddenly becomes more competitive? Is that where “days-burned/destroyed” comes into play? That’s also an interesting concept to me but one that I don’t think is necessarily conflicting with this option.

im_uname · May 30, 2021, 2:45pm

Note that this merely provides a system to coordinate. There is nothing “enforcing” or “controlling” it, consensus or otherwise, with the possible exception that miners should have at least mild incentives to see the network succeed via not lying. Given enough support for whatever an alternative, “innovator”-facilitating system there is, nothing really stops the network from abandoning this at anytime, wholesale or piecemeal.

BigBlockIfTrue · May 30, 2021, 8:28pm

Interesting idea.

I think it’s risky if 0-conf policy is not aligned with the mining majority, so I’m inclined think the 75% threshold is too high - a simple majority should probably control the fee rate.

Also I would suggest using a predefined array of fee levels, e.g. [ …, 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, … ] (but you most likely want a more fine-grained array), and then step one element up or down the array after a successful vote. This way the fee rate can always remain a nice round number that is easy to communicate.

freetrader · May 30, 2021, 9:18pm

I am agree with the initial statement, but I’m confused about what follows. If the fees are adjusted by a mining supermajority, that would imply their are aligned with the mining majority, no? (can’t have a supermajority without having a majority)

But maybe I’m not understanding exactly what you meant by “… if 0-conf policy is not aligned with mining majority”.

Yes, this part is attractive to me since fees are a frequent topic of communication. I did consider precomputed tables, but not under that aspect (I only mention them briefly in point (1) of ‘Tradeoffs’).

I would welcome someone doing a counter-CHIP that specifies such a scheme.

They could just take this CHIP and change a few areas, as it would not be fundamentally different.

BigBlockIfTrue · May 30, 2021, 9:40pm

The problem occurs when a 70% majority want to increase/decrease the fee but a 30% minority successfully blocks it. In this example the resulting fee level does not have majority support. More precisely, it previously had majority support, but now lost it, yet it continues to exist.

BigBlockIfTrue · May 30, 2021, 9:47pm

A simpler suggestion than a full array is to use 25% increases and 20% decreases. These are equal in size on a logarithmic scale, i.e. one 25% increase and one 20% decrease always exactly undo each other, regardless of order.

alex_asicseer · May 31, 2021, 3:53am

since reducing minimum relay fees is not a consensus change, miners can reduce their minimum relay fee right now and accept/mine transactions with lower than 1000 sat/kb. once those transactions are mined, all nodes see them. before those transactions are mined, most nodes will not see them (because of current relay rules). as it stands this degrades zero-conf.

the voting proposal appears to be democratic (two wolves and a sheep deciding what to have for dinner). it does not appear to display the core tenets of voluntarism. that is, malicious actors can create a situation where they force others to behave in a certain way. assuming as a given that high transaction fees degrade a network, a malicious entity can socially engineer miners and other nodes to keep fees high.

in my opinion, a demonstration of voluntarism would be to release a custom drop-in client with a low-enough minimum relay fee set that activates upon a certain block number, that miners can download and use immediately. SPV wallets, nodes, exchanges, etc, can be advised that minimum relay fees may be reduced by that time, and they should update their software, before that happens, so that zero-conf is not degraded.

on another note, i think that BCH will not capture as much potential new users and new traffic if fees are not reduced within the next 120 days, and may 2022 will unfortunately be too late.

its my opinion that the only objectively correct move is to reduce transaction fees, and the only considerations should be the technical limitations of a rollout as it pertains to a decentralized system (i.e. reduction in possibility of degraded zero-conf would be a good example of that)

btw, average transaction size is about 500 bytes, not ~212: Transaction Size | Bitcoin.com Charts (Appendix A - Fee Projection table). if transactions size is being used to determine fee projections, it should probably be the case that current/real transaction sizes are used for these data projections, instead of the minimum possible transaction size