Lower the default relay fee, create a fee estimation algorithm

Technical
#1

I’m really glad that we are done with killing the 50 transactions unchained limit, which was my main concern 6 months ago.

Here’s my biggest concern now: the 1sat/b fee. (My next concern: UTXO commitments)

I know that this is a command-line argument, not a consensus thing, but the default settings and communication from BCHN and BU is really important. Right now the default thing to do (and the message to wallet developers) is “pay 1sat/b you’ll be fine”. I think this needs to be changed, both as a default setting and (as a consequence of that) as a default message to wallet developers from node developers.

What’s the big deal?

Bitcoin (BTC) had a great raise in 2017 and this year, but it had really killed its own momentum when the fees rose (due to the network congestion)

BCH might (and actually inevitably will) find itself in a similar situation. The fee will kill the adoption momentum.

In case of an explosive growth in usage and price (50x isn’t that crazy to imagine, especially if SmartBCH suddenly takes off), the fees will jump from the current low of $0.0062 to $0.31 (that’s the CHEAPEST thing you can do, so in reality we’re talking about people paying $3 or $30 for more complex transactions).

If we’re talking about being the world money ($500k - $5m per coin) - we’re talking about 350 - 3500x increase in fees ($2 to $20 being the cheapest option for the simplest transaction!) It’s still far from BTC fees, but it’s still terrible.

Am I being too optimistic with 350-3500x? Well, Dogecoin got 5922x in 6 years from its all time low (and mainly just due to ONE GUY). For BCH the same increase from the ATL would mean 370x from the current price = $2 minimum fees.

Even when the fees will reach $0.05 (this is just ~5x from here), the adoption momentum will start to slow down. If you live on $1/day, paying $0.05 is huge, paying $0.50 for a slightly more complex consolidation transaction is just nonsense.

  1. It will kill the price rally. I don’t care much about the price, but price increases bring lot of fresh blood faster than ANY onboarding efforts so far. I’ve got into Bitcoin in 2013 because it doubled the last month. I bought in, then I started figuring out what the heck did I just buy… If the fee at the time was $1 and I had a choice of thousands of coins with lower fees, I would have probably immediately switched to something else. Here I am 8 years later, brought in by a price increase AND low(nearly zero) fees.

  2. $0.50… $5… It’s CRAZY expensive for the world as a whole where 50% lives on less than $5/day and 10% lives on less than $2/day.

  3. This will instantly kill services like read.cash and noise.cash, since most of our transactions are a few cents. It will kill all tipping everywhere. Also, any games that could use it as in-game currency, etc… Probably even stuff like juungle.

  4. It will probably start blocking smartBCH from taking off. Or vice versa, people might move all of their economic activity to smartBCH, making BCH look kind of like dumbBCH.

What about zero-conf?

Yes, zero conf is great, but we’re also talking about the relay fee here. Your transaction with a lower fee won’t even reach another user’s wallet or any of miners mempools.

What should we do?

It’s a hard question. I don’t have any definite answer, so I’ll put some thoughts here.

The miners are spending electricity to validate these transactions. Right now, I don’t think miners will even care if transactions were $0.00, the majority (like 99.999%?) of their profit comes from the block rewards. This will probably be the case for the next probably 10-20 years (we’ll still have considerable block rewards). At the moment I think it’s safe to assume that if $0.003 for a normal transaction was ok for miners for the last few years, it would be ok for them in the next 10-20 years (after that we could adjust).

However, the blockchain itself knows nothing about the price… yet the price definitely can kill the adoption. Yes, you pay 1sat/b in 2021 and in 2031 - the blockchain doesn’t care, but at the same time it might be a difference of $0.006 and $6,000 in the real world.

Somehow we need to make blockchain aware of the price. It’s possible to do it directly or indirectly.

  1. Directly. For example setting the default node relay/mining fee in US dollars and using the US dollar price feed like CoinGecko or AnyHedge price oracle. This adds quite a bit of trust and centralization, so ideally it should use multiple feeds and take a median price to avoid any party messing up with Bitcoin Cash transaction fees directly by manipulating its feed.

  2. Indirectly. Basically, using the relation between included transactions and their sat/b (kb/mb) pricing. Something that maybe looks at the mempool… I don’t know. It’s much more “blockchain-way”, but at the same time I have no idea how to do it.

Can’t we just trust miners to set the price?

In my opinion, no, because the miners act on their greed, of course and as mentioned above - they don’t even care about the number of transactions they include - they aren’t a part of their income in any measurable way for now. That means they might set the minimum inclusion fee to $1000 and not care. At the same time the other side (users) also don’t care about miners that much, they will just leave for another coin.

You could say that miners care about usage… but at the same time, I think we’re at tragedy of commons here. Miners won’t care about the fact that users leave for Bitcoin X or Bitcoin Y, since they can mine any of them. HathorMM not mining any transactions is an excellent example here.

Who decides then?

This means that economic participants of the BCH ecosystem and node developers need to decide on the transaction price / relay fee, because we’re the only ones interested in keeping fees at an absolute minimum (miners don’t care about this, random new users too - they have lots of cheap coins to select from). Also the long-term coin holders, who plan on keeping using the coin for some long time.

This means that we can’t just toss this to miners and ask them to choose a reasonable fee. We need to add a downward pressure at least (and miners will maybe start to add an upwards pressure in return).

What to do?

Again, I don’t know and I’m inviting people to propose ideas.

My personal suggestion would be to use multiple USD price feeds and set the default relay fee to be $0.003 for the 220 bytes transaction, so like 1.36 cents per KB.

Then start communicating this to wallets.

Maybe add a RPC call that returns the current minimum fee. That way maybe a service could be built that polls the nodes for their fees

Maybe add this minimum fee to the block template, so that the node software can communicate the current minimum fee so that wallets can watch it.

Maybe something else.

I really hope that people smarter than me can propose something.

I see it as the biggest current problem that will prevent mass adoption and we’re the ones who should be solving it now, before it becomes a real problem.

5 Likes
Coin Days Destroyed used as part of priority - exploring the utility as a basis for further decisions
Pre-release of a new CHIP-SubSatoshi
#2

Check this task:

#3

I think that before we worry about fee estimation we should think about creating an ability for miners to broadcast their minimum fee levels to the rest of the network (i.e., wallets) on-chain. It would be incredibly helpful to future fee estimation to have access to the fee schedules for different miners. At that point, it becomes much easier for a wallet to accurately calculate fees necessary for different levels of transaction processing priority. All they would have to do is look at the minimum sat/byte fee levels posted by miners in recent blocks.

To Tom’s point, I am assuming that miners care only about transaction size here. That may or may not be valid. Perhaps miners do care about coin days destroyed or the ratio of inputs to outputs. If I was a miner, I would personally care only about fee per byte. However, it certainly would make sense to ask. I do believe that coming to a general consensus around the variable(s) of interest to miners when setting fee policies will be extremely helpful to the network in the long-run. Once we figure out what variables they wish to use to target fees, it becomes easier to come up with workable solutions for communicating miner preferences, assuming that’s something others also think would be valuable, and fee estimation for wallets.

Whatever we do, I hope we do not mimic BTC and attempt to calculate fees based on mempool and block inclusion statistics. BCH intends to keep the block size cap above the level of normal transaction volume as long as its sustainable, so such inaccurate modeling of likely fees as what is done on the BTC network should never be necessary. Users should never be (directly) bidding against other users for inclusion in any given block. They should be negotiating a fair price with the miners.

#4

It is a difficult problem, I agree, because it it at the intersection of code and economics, and requires coordination as we know to keep 0-conf working well.

That said, I want to put some of my unrefined thoughts about this out here, since we are pretty much in the brainstorming phase on this matter.

And many, many voices should be heard.

  1. The most reliable data we have, is that of past blocks.
  2. It is very difficult to relate some fiat numbers to anything stable. For example, a currency like USD. The choice is arbitrary, these currencies can hyperinflate, we should not put too much stock in those numbers.
  3. Miners have always and will continue to pick what transactions they include, or even relay, since they do not have to accept any code we propose.
  4. That said, we can only hope that BCH miners are on board with the plan of keeping transactional capacity far above demand, and keeping BCH ultra-competitive when it comes to payment system competition.
  5. I’m hoping can use fee data from past blocks to lower the relay floor, with a built-in protection of a minimum floor (substantially lower than current 1000 sat/kilobyte, maybe lowered initially by a factor of 100)
  6. This introduces some kind of statefulness since the active floor is higher than the ultimate safeguard, and so nodes (and wallets) have to somehow find out what is the active floor. Nodes can (mostly, but not guaranteed) look at enough pasts blocks to work it out. SPV wallets cannot easily, they need to trust other infrastructure, or get some kind of proof via commitments, which we have not thought about. So how to communicate this active floor remains a difficult problem overall. I don’t have a satisfactory solution yet.
  7. We can’t just blindly trust nodes which are vulnerable to sybil attacks.
  8. I think some people have described what we’d be trying to do, as bringing minimum fees into consensus. It’s hard to argue against that point. I basically agree with them. Is is even a smart thing to do? I’m not sure about it, as this could perhaps be a volatile area and most certainly new point of attack.
  9. We (full nodes) almost certainly cannot react quick enough to market changes in coordinating such changes without automation in the protocol. This has basically been demonstrated in BTC (ok, partly wilful but it still took months if not years to fork), ETH, LTC, XMR (remember that long high-fees period?), now DOGE, … so some kind of consensus-level mechanism seems unavoidable.
  10. Any kind of downward fee floor ratcheting mechanism would need, and get, wide discussion, and must be analysed for unintended consequences. We should think also on other conditions, like measured utilitization of block space, when moving this fee floor. And then we need to consider its interaction with other scaling efforts, such as perhaps increasing the max block by several factors etc.

such inaccurate modeling of likely fees as what is done on the BTC network should never be necessary

I agree, I don’t think that would be needed as long as we manage to keep block space supply up enough.

Users should never be (directly) bidding against other users for inclusion in any given block

In the sense that there should not be any losers, yes, but in the sense that miners always can have a cut-off and do, realistically, have a cut-off … we need to accept realities here and there are some that stare us in the face (currently):

Miners on BCH do not make use of the maximum block size of 32MB at all. They are very conservative. Maybe this is due to what @jtoomim has pointed out, that 1 sat/byte is already so near the marginal cost of adding transactions, that they are not incentivized enough. This is one fine line to tread, I’m not sure how any mechanism we come up with here, will manage safely treading this line. Definitely a lot more thoughts and inputs are needed.

1 Like
#5

Thanks @tom @gotamd @freetrader for your opinions. Trying to think some more about this.

I don’t think that consensus is the best way to solve it, since that means we’ll have one fee level for everybody, whereas some people might sell their space far cheaper than others.

I think one of the biggest problems right now is that people don’t even set that setting at all. Maybe we could improve that by setting the default relay/mining fee artificially too low (1sat/mb?), which will force miners to set it. That way maybe we could develop an algorithm that looks at the distribution of previous blocks and fees and gives the user an estimate of how fast (likely) his tx will be mined with a selected level? (i.e. 123 sat/kb will be mined with 100% certainty in the next block, while 1sat/kb has only 5% certainty and will probably require at least 5 blocks, because only 20 out of last 100 blocks included these transactions?)

1 Like
#6

This could work if we automatically calculate relay TX fee based on First Quartile of X last blocks.

Let’s say if the Q1 (25% lowest) fees from last 100 blocks is 10 sat per MB, then we set relay fee automatically to 50% of that, meaning 5 sat per MB.

Mined blocks should ultimately provide somewhat reliable data about real world environment and it is probably the only kind of data that is not prone to sybil-attacks.

Of course that would be the default settings, miners and nodes could change it in configuration files.

#7

Yes, I had a similar mechanism in mind. Though perhaps not with such a radical lowering, but more gradual.

We would just need to define how often this calculation is done and what the maximum rate is at which it should be able to lower the relay fee rate (e.g. lower up to 50% over the course of a day or 144 blocks)

It is also a problem for pruning nodes which may not have this fee data for all the blocks. I think they might need to be equipped to retrieve the full blocks from other nodes to verify the fees in those blocks in order to do the calculation. Of course when they have done this once for a block, they can cache that information easily.

This still leaves us with the problem of the mining fee minima.
Mining nodes apply their minimum fees they want for mining a block. There should be this option to make that automatically track the calculated relay fees.
If miners set their fees higher, then overly greedy wallets might be putting out transactions that get relayed, but not mined.
We would have created a “dead zone” between what gets mined and the (lower) relay fee. Clearly something we’d want to avoid, right?

The good thing about relay/economic nodes calculating their relay fee rates from past blocks is they could easily advertise that info, and SPV wallets could just have a look at a range of nodes (perhaps with some sanity checks) and calculate a “realistic” fee rate (perhaps double the minimum?) that should get mined.
However, this is all still blue-skies thinking that has not considered possible attacks.

#8

Since I wrote the task about a year ago I have been giving this some thought too.

First and most important part is that fees are an artificial spam-protection invented by Core. Yes, we had fees before, but our main weapon against spam was always days-destroyed. A concept that Core removed.

My thinking about this is that fees make sense in the BTC world because they want high fees. But we don’t. Our goals are very different. Fees exist as a fallback only. Other metrics that can not be be faked make much more sense to use. Now, don’t get me wrong. Fees are still going to be a concept we have. The point is that miners should be able to say “Hey, I want to get paid $10000 per block. The blockreward plus fee-paying transactions make up 5MB, and after that I fill up the block with another X-MB worth of high priority, zero-fee transactions”

The thought process here is:

  1. A miner including 1MB or 10MB of transactions should be no difference in cost whatsoever.
    Those numbers go up over time as better tech is rolled out.
  2. Block-rewards and fees pay the cost for the miner. The miner has a stable cost and many competing miners. Any individual miner can demand huge fees, but as long as other miners mine low fee transactions this will have no other effect than simply giving that high-fee demanding miner less income.
    Result: Miners can’t artificially push up fees above cost, other miners will outcompete them and steal their income.
  3. As our technology gets better and we can mine bigger blocks, our available block-space will grow faster than the requirement for having a profitable mining business.
    Result: miners require a certain amount of fees. The amount of transactions paying them is irrelevant.
  4. Given the fact that a miner got paid after N-MB and they have Y-MB of free space to fill, they want a way to determine the best transactions to include which ensure the highest health of the system. Higher health means more payout from the coins they earn.

When we follow this thinking we get to the point where we have the basics to build a good solution on. And my suggestion is to indeed turn the fees into a secondary point. Fees are just the bottom layer of a miners “Maslow’s Hierarchy of Needs”. As we grow we know that those miners will get paid. So lets start with the top of that pyramid and see what is useful.

  • We can fight those pesky 1 in 300 out transactions that deposit dust in many addresses by setting a score on a transaction based on its inputs vs its outputs. A tx with 1 → 300 gets a deep negative score which means it now has to pay a large fee to overcome that.
  • users that combine massive amounts of inputs into one (hello read,cash!) can benefit from that same rule by essentially getting their transaction for free. No fees needed.
  • People that use BCH for normal shopping will end up with enough UTXOs that are a week or a month old and paying with those can be counted in number of blocks, we can determine that older coins being moved gives people a higher priority to get included.
    This means that the core argument from OP where those living on $2 a day will effectively have zero fees. (assuming enough financial activity happens from people that can pay).
  • Services that have high-transaction throughput and chain transactions in the same block get a negative score on the UTXO-age. And they need to adjust this with either combining lots of inputs, or by paying fees.

This is a balance that leaves those that are going to be using BCH as actual simple money to have fees which are effectively paid for by those that use BCH as a financial instrument. The rich are paying for the security that the poor can use for free.

Edit:
ps. this scheme also means we can drop the dust-limit or at minimum severely lower it. Again making the system more accessible to those less off.

5 Likes
#9

Notice that BCHN inherited this feature from Core who’s intention of having massive fees is distinctly diffrent from ours. The quesion is if you really want to keep the relay-fee in the client.

The design that Satoshi built was that transactions were rated on priority and zero-free transactions were rate-limited.

This requirement falls away when DSProofs start being used in apps receivers use.

#10

Relay fees are not used in Core to drive up fees.
It is an anti-DoS mechanism, we would be unwise to scrap this entirely at this point.

#11

I didn’t claim that.

Our main weapon against spam (AKA DOS) was always days-destroyed. A concept that Core removed.

I also didn’t suggest that.

2 Likes
#12

I think @tom has a great idea.

Free transactions for most people (you are paying “spam” fees with days destroyed), and fees for high-frequency transactions - that would be pretty freaking amazing! I think that’s also the case for many areas, where high-caliber users basically subsidize all other users (think advertisers paying to keep YouTube free or like a tax system, where high-income earners pay more and people barely scraping by don’t have to pay anything). I think cryptos like Nano, IOTA where users have to pay no fees have a huge selling point.

And again, days-destroyed are protecting us from spam. You can’t easily fake it. Or at least we could think of an algorithm (or recover Satoshi’s one if that was good enough) where you can’t flood the system because you’re spending a scarce resource (days destroyed)

3 Likes
#13

WOW, I actually thought this code is still in.

Did Bitcoin Unlimited also remove it?

I am not sure about removing relay fees - this seems like a groundbreaking change so it needs more thinking, but I certainly think we should return Days Destroyed to the codebase immediately. It is a great spam discouragement mechanism, best of all probably.

There is just no logical reason why Days Destroyed shouldn’t be used as a spam discouragement mechanism again.

1 Like
#14

^ Your remark above is what made it seem to me like you were suggesting to remove it from clients.

If it was a general remark, including a suggestion to remove it from Flowee, then I don’t understand why BCHN is being referenced here - other clients have this minrelaytxfee (or similar) feature too… e.g. BCHD.

#15

A healthy network will in future require a large volume of transactions, paying many small fees. Transitioning gradually from block reward to this is the future that Satoshi proposed.

We do NOT want to drive away users or use cases that have a need for more frequent transaction. They would already pay proportionally to their use.

A system where they subsidize the majority of other users seems to me to

(a) be unstable in the long term (what happens when the subsidizing “rich” decide BCH is too expensive and go to some alternative?)

(b) shift the minrelaytxfee question to a “coinage days setting” (or even more complicated machine) configuration question

(c) unintended side effects on peoples’ spending behavior, possibly inhibiting natural growth of the system

Additionally, I think there is a lot of wishful thinking/armchair economics in the comments. Miners will NOT just include a bunch of MB’s of free transactions because of <insert complicated thought process>.

5 Likes
#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