Lower the default relay fee, create a fee estimation algorithm

Technical
#16

im_uname here raining on people’s parade again!

  1. Dictating policy from one or many external oracles is a terrible idea. If we do that we can pretty much fold up any claims of being a permissionless currency and join the ranks of the EOS constitutional council or XRP. It’ll turn the whole thing into a joke. Seriously don’t do it, don’t even mention it. Internal policy of an independent cryptocurrency should never ever depend on reading from an external fiat.

  2. Forcing the miners to float fees is less terrible, but still unequivocally bad. Once you got a jungle of desynchronized fee policies you can say goodbye to any claims to reasonable 0-conf reliability. Yes. I think having a reasonable 0-conf is orders of magnitude more important than crossing some arbitrary red line drawn around one US cent per typical transaction.

  3. Free transactions are pointless. The problem isn’t that they encourage spam - we can arbitrarily limit their existence in any number of ways, coindays and hard size limit being two of them - but rather it cannot be deployed for any application that has any aspiration for reliability, at all.

If such a space strictly caters to unimportant applications that need no reliability, I’m not sure why we should care. If it aims to provide value to some useful application, these applications can and will fail-by-congestion at arbitrary times due to adverse conditions inside the “free space”, and that problem is unsolvable. Damage to BCH’s reputation as an unreliable chain will, in my opinion, be far worse than having each transaction pay two cents till the next upgrade. We’ll necessarily have to heavily discourage its use for anything useful, at which point I hope we’ll be self-aware enough to do some serious reflections.

There is one place where free txs are useful: In case you’re spammed by malicious miners with dust that can’t pay for its own movement, free space allows you to eventually consolidate them. But I doubt that’s a relevant problem these days.

Alright, enough pessimism. Looking at actually plausible solutions:

  1. Some form of algorithm that reads from aggregate fees of past n blocks. It’s easy to see how that’ll work in a congested chain - minimum inclusion fees are fairly useful as proxy to demand, due to users bidding against each other (otoh the UX, as we know, will be absolutely horrible). On a mostly non-congested chain like BCH I’m not sure how that can be done though - in “peacetime” we’ll have the overwhelming majority of tx be at the exact prevailing fee floor, so reading from that aggregate of fees doesn’t yield much useful information. We can’t have the floor constantly lower itself from prevailing fee, since that inevitably ends in a jungle of different policies as miners ditch the unreasonable adjustment algorithm. Again, 0-conf is far more important than crossing some arbitrary line denominated in a constantly devaluing fiat.

There’s probably some clever way to extract more useful information out of the past-transactions aggregate, but I don’t know what it is. If anyone has a new idea here I’m all ears.

  1. It’s a bit puzzling reading the heavy distrust towards miners here - we know they take initiatives on Ethereum to raise blocksizes, so having an adjustment mechanism that depends on miner/pool voting isn’t completely out of the question. In any case, better solutions on this front definitely exist, at least when compared to the very ugly process of lobbying node developers, which is happening right now.

Re:making minfee a consensus rule, that might not be a bad idea… but imo it’s limited in usefulness, since the only difference between that and strictly relay policy is that miners cannot arbitrary lower fees themselves to ruin coordination. Note that they may raise fees and there’s nothing anyone can do about that.

6 Likes
#17

Here are my additional thoughts after reading this thread:

Agree/Reiterate: Do Not Add Fees to Consensus Rules

I agree with others that making fee levels a consensus rule is a bad idea. IMO, fee levels always need to be flexible. What fees really pay for are mining/node costs, and these costs vary in terms of BCH because BCH’s value changes over time. We should also not take away a miner’s ability to mine whatever valid transaction (exclusive of fee) they want to mine. Sure, a miner could “attack” the network by mining a ton of no-fee transactions, but that behavior is unsustainable in the long run and may even be fought off in the short run by other miners orphaning such blocks. I view Bitcoin mining as a cartel. We’ve already seen this in action with off-chain meetings of miners to make decisions and commitments regarding policies they will enforce. Unlike most real-world cartels, however, miners have a pretty slick enforcement mechanism: orphaning blocks. We do not need to try an centrally plan this behavior. It will emerge on its own as necessary since it’s in miners’ self-interest to police this on their own.

TL;DR: I feel like the consensus ruleset should be as minimal as possible (keep it simple, stupid). Transaction fee management does not, IMO, come anywhere near passing the high bar of necessitating consensus enforcement. In fact, I would view such attempts as harmful to the network.

Interesting, but Not Convinced: Different Fee Treatment Based on UTXO Consolidation/Coin Days Destroyed Behavior

I agree that there is value to the network in consolidating UTXOs. I can also see the argument for discouraging “high velocity” usage of the blockchain, though I don’t subscribe to that point of view. Due to the added complexity that these sorts of policies add to the code and the potential for abuse (e.g., spamming the network by creating and then consolidating massive numbers of otherwise un-economic UTXOs becomes possible, and perhaps even cheap for someone with a lot of BCH who can slowly cycle groups of coins to take advantage of both UTXO consolidation and CDD subsidies) I’m skeptical of the need for or wisdom of such policy.

TL;DR: My default position on these is to oppose the added code/system complexity since I don’t yet see the benefits clearly outweighing the risk.

Great User-Configurable Setting: mintxfeerelay

I am all for individual node operators being able to set their own minimum transaction fee relay. I understand that this potentially leads to problems with low-fee transactions not getting relayed and hurts zero-conf security, but I think the tradeoff is worth it and further believe that it should always be a user’s choice in how altruistic they wish to be when running a node. The ability for node operators to manually change this setting on their nodes could also help them and the network avoid a DoS attack scenario where an attacker starts spamming 0-fee, unconfirmed transactions (especially now that there’s no unconfirmed chained tx limit).

The zero-conf security issue is the biggest problem with relaying only transactions with a certain level of fees. However, I agree with freetrader that it is alleviated if not eliminated, by Double Spend Proofs.

TL;DR: I like user-configurable minimum transaction fee relay settings and think that DS Proofs eliminate the best argument for removing this from nodes/user configurability.

Clarification

I assume that when you say “forcing miners to float fees,” you’re referring to the idea of having miners set their own fee schedules and broadcasting them somehow (such as in blocks they mine), but I’m not sure. I don’t see how a jungle of desynchornized fee policies is any worse when it’s explicit (as in the suggestion to broadcast fee schedules) vs. implicit (as is already the case today). We already have mining pools which don’t mine any transactions, and there is absolutely nothing from stopping miners from setting their own minimum transaction fee policies right now. All I advocated for in my first post was creating an ability for miners to communicate policies which they either already have or will likely have in the future.

I also question the idea that there will ever be a “jungle” of desynchronized fees. As I said further up in my comment, I believe that miners will behave more and more like a cartel where it comes to block acceptance as transaction fees replace coin emissions as their primary source of revenue. Transaction fees are just a price like any other, and prices from disparate parties tend to converge even when they are not centrally planned.

3 Likes
#18

I assume that when you say “forcing miners to float fees,” you’re referring to the idea of having miners set their own fee schedules and broadcasting them somehow (such as in blocks they mine), but I’m not sure.

No, I’m referring to the idea of setting default fees so low, the miners have to set their own minrelay fees independently. (Note: local minrelaytxfee is already a config item, has been for a while. Try it!) Miners mostly adhering to the same policy is a good thing, don’t force them into a strictly worse jungle-of-policies situation by taking away the sensible default.

3 Likes
#19

Aha. In that case nevermind that area of my earlier comment. Anyway, I agree that default fee policy should probably reflect some reasonable effort at estimating the cost of a transaction likely to be processed within x blocks.

1 Like
#20

Ah, the part you quoted was not an advice or suggestion. It was merely an item to earmark for further research. I understand your viewpoint now, good to know!

2 Likes
#22

Interesting point of view. Its obvious that a lot of people would not mind stuff being free, so thats half of your argument gone. Your point that it would somehow not be reliable has been solved already in Thinking about TX propagation.
The concept of “Free transactions” is also missing the bigger picture I tried to explain. This is not just about fees, this is about the wider picture with several metrics. Transactions that have very very low priority need to pay fees. Transactions that have high priority may omit this, but can wait an extra block or two.

This is thus a false assumption, nobody was suggesting a system.

I invite you to look at my post above
where I explain the economics where miners are fully allowed to be greedy, without hurtning the system. No need to trust or distrust.

This statement is shown to be false. Imagine 1 restaurant asking twice the price of all the other ones. The only effect it will have is that they will not get any customers and thus get even less income. Even if 90% of the miners ask for higher fees, the only effect it will have is that people paying lower fees wait for more confirmations.
Your assertion is not supported by basic economics.

Yes. And more to the point, the fee/price should be left to the open market to allow discovery of the optimal. Centrally planned fees, costs, prices etc have been tried and they always cause massive issues. Free market, learn to trust it :slight_smile:

Interesting thoughts.
First of all, I don’t think that asking people to pay a minimal fee is equal to discouraging them from participation.
My design is that a mining policy prioritizes transactions for inclusion. And transactions that need to be in the same block as 100 of its parent transactions can get that guarenteed by paying a small fee. As the system grows and we reach 10k tx/sec then the amount of fee per transaction is going to be very low in order or for miner to still get a good income every 10 minutes. So don’t worry about this being anything like a high fee.
Like freetrader said; they are paying more because they use more block-space.

The abuse is a good point to take into account should a mining software implement this idea: the cost of doing 1 → 300 and then doing 300 → 1 should not end up costing the same as a 1->1. I’m not worried about this being too hard, finding some good curves to fine-tune this doesn’t seem a big problem and this is not a consensus part so iterate and test.

Notice that this would not be any complexity in the “system”. This would be a better algorithm that miners use to build a block. Even if a small number of miners use this, the benefit would be that the system as a whole becomes more responsive to economic incentives. None of the other components need more complexity.

1 Like
#23

I’m not sure whether tom forgot to read most of my actual post before picking out of context quotes to straw-man against, or deliberately chose not to. But I’ll encourage other interested readers to go through my original post.

#24

To be honest, I felt the same way when you simply dismissed my argument with rather strong but scary statements in your reply. To be fair, you started out with a disclaimer of you going against everyone.

To be constructive; your argument rests on the conclusion that free transactions are pointless, based on the assertion that they have no reliabilty.

This assertion makes no sense to me. Reliability is not impacted. Most likely you have not understood the proposal to expand priority to not only be about fees but also about other factors. How would a different way of having priority affect reliability?

I would also really like to ask you to be more constructive and cooperative. There is an proposal and it would be nice if you try to understand it and not just dismiss it like I’m a junior that has no clue. You are exhausing to work with. Please, questions instead of dismissive statements.

1 Like
#25

A quick question to better understand it. Let’s say Alice’s node has 1sat/KB relay fee and Bob runs a BCHN node with default settings. Someone gives Alice a TX with 1 sat/KB and she relay it to Bob. Will Bob’s BCHN node accept it into its mempool?

#26

Will Bob’s BCHN node accept it into its mempool?

No.

From the BCHN method that accepts a transaction into the mempool (or not):

// No transactions are allowed below minRelayTxFee except from
// disconnected blocks.
// Do not change this to use virtualsize without coordinating a network
// policy upgrade.

That second sentence should be taken generally imo, as "do not change the policy here without coordinating a network upgrade.

#27

Thank you! But if somebody mines this 1sat/KB transaction, then the block will be accepted still, right?

#28

Dammit, I can’t have an answer less than 20 characters.

My answer would have been just:

Yes.

#29

Adding to the BCHN answer that they do not allow anything below relay fee.

This is not what the Satoshi client did for various years. This is behavior that was later changed.
In Flowee this still lives; libs/server/validation/TxValidation.cpp · master · Flowee / thehub · GitLab

Relevant upstream ⚙ D4745 remove priority free transactions mechanism (currently off by default)

The proposal I wrote above is essentially to go back to what Satoshi designed: priority transactions based not only on fee, but also on hard measurable things that can not be spoofed. It is my opinion that that would create a more stable system.

1 Like
#30

While there may be some fancy more permanent way to handle min relay fee through an algorithm. I think the simplest approach would be the best. And we already use this simple approach when deciding on block size which is to just change the variable through coordination. Just lower the min relay fee variable. I suggest decreasing min fee from 1,000 sat per KB to 100 sat per KB. A factor of 10 decrease. And if I remember correctly lowering the min relay fee will also lower the dust limit by the same amount.

EDIT: To elaborate why I prefer a simple approach over a more algorithmic one is because the algorithmic suggestions here may take a longer time to discuss, research, and implement. A simple approach will be less risky and gather more support much quicker rather than a complex untested solution.

1 Like
#31

Also I would like to add that SLP tokens are impacted by the min relay fee when it comes to the dust limit. Each time my application sends someone a SLP token it costs me the network fee + dust limit, which is 3x more expensive than a BCH transaction.

1 Like
#32

A “simple” adjustment also opens node developers as targets to continued future lobbying/harassments no matter the actual situation, such as what led to this thread. There is no pressing, urgent need to adjust minfee, a parameter deeply intertwined with 0-conf reliability and general perception of network reliability. Yet node devs who could be spending their time working on hard scaling to stay ahead of congestion - the actual specter that will kill low fee situations very quickly - are socially pressured into reading and participating in threads like this way ahead of any real need.

Solutions that do not free node developers from future lobbying efforts like this, imo, cannot be good solutions.

#33

I agree that as of today the min relay fee is not a pressing issue. I do share the same concerns that OP has pointed out which is the fact that market price of a coin can change drastically in a very short period of time. If Bitcoin Cash rises sharply in price in a short period of time the min relay fee will become a really big issue really fast. Same problems you would get if blocks got filled up.

It would be smart to be proactive on min relay fee like we are with block size by leaving a lot of room for growth.

I agree with you that devs should not spend a whole lot of time on this issue, which is why I think the simplest approach of decreasing the min relay fee would save people time and effort.

I don’t have a response on developer lobbying and harassment. That sounds like a separate issue entirely.

#34

@im_uname, you mention “a parameter deeply intertwined with 0-conf reliability and general perception of network reliability” and that “there is no pressing, urgent need to adjust [it]”.

Which means that this parameter is very important in your opinion and must not be changed in a haste. Why would it be then better to start thinking about this when there is a “pressing, urgent need”? Are you sure it’s not better to think about this now, when there is no pressure?

I really don’t think people think better under pressure.

This pressure might materialize within days at any time.

Devs will suddenly be forced to come with a solution right now about a parameter that (in your own words) is “deeply intertwined with 0-conf reliability and general perception of network reliability”.

…or people will leave for a network that offers better fees. Which is what we see with Ethereum and alternatives like BSC and Solana, etc… There is a pressing, urgent need. Nobody can do anything now, because it’s way harder to change now.

#35

@im_uname I’m also very surprised about this attitude of “BCH devs don’t care about what you, the actual user, want or foresee, let’s only work on things that are on fire right now and wait until something new catches fire… oh and please refrain from contacting/lobbying BCH devs about your petty problems in the future, they have more important things to do than read your babble about BCH” (Paraphrased, obviously, but the gist is there)

There is no pressing, urgent need to adjust minfee, a parameter deeply intertwined with 0-conf reliability and general perception of network reliability. Yet node devs who could be spending their time working on hard scaling to stay ahead of congestion - the actual specter that will kill low fee situations very quickly - are socially pressured into reading and participating in threads like this way ahead of any real need.

Solutions that do not free node developers from future lobbying efforts like this, imo, cannot be good solutions.

This is the first time I have my doubts about BCH since the split. Very surprising. Eye-opening.

#36

Both are important. If we have 1TB block limit and actual capability to send and process 1TB blocks, yet only 100KB in transactions per block and $50,000 per coin (~BTC) with transaction fees of 1 sat/b, which would mean minimum transaction of ~$0.20 fee for the cheapest transaction and like $10-50 fees for consolidation transactions, none of that 1TB stuff will save BCH. Both are important, in my opinion.

I can shut up and avoid getting devs “socially pressured into reading and participating in threads like this”, but it won’t change the fact that we need to understand how we’re going to solve this problem when it arises, instead of dismissing it and having this same talk while BCH businesses will be crashing and burning with high fees, while having 99.9% empty blocks. We’ll suddenly have to coordinate an emergency change and emergency coordinate network upgrade with a parameter that’s uber-important.

I seriously thought that “low fees forever” was one of our key selling points. Boy, was I mistaken!

P.S. There doesn’t seem to be a way to “close” this thread, so I’m unfollowing it. That reply was the most disappointing thing I’ve ever read about BCH.