i'm not even sure you understand the proposal. the goal is not to limit transaction fees! it's to set a minimum percentage that doesn't prevent people from paying more it just prevents them from paying less. so if anything the goal is to increase transaction fees for miners so bitcoin can be more sustainable.

miners would pick the transactions with the largest fees much like they do now. the only difference being that they were getting paid MORE. more than under the current scheme.

That makes no sense because the fee that is paid is not to transfer coins, the fee is actually the money sender pays to purchase block space which means it has to be based on transaction size not value transferred.

Well, I strongly agree to your point! Bitcoin's transaction fees has become a bit of nuisance in recent days. With more and more adoption, I foresee that the transaction fees are going to increase based on how busy the network is. Also with each halving, the mining rewards are getting decreased. So people who have invested a shitload of money in setting up their mining operations, will be more and more dependent on the transaction fees, rather than block rewards. So the transaction fees is bound to increase and it might increase to a certain point where it becomes unaffordable to use Bitcoin as a payment processor.

If the Dev can find a way to limit the transaction fees, I think it will only help Bitcoin to remain financially viable to be used as a payment processor. Right now, the bank transfer is way cheaper than bitcoin transaction. Either the transaction fees issue needs to be fixed or we need to find a way to block BRC-20 tokens from the network forever.

thanks. but you don't seem like you understand it.

it makes perfect sense.

that's a backwards way of thinking and we need to move forward from that one dimensional mindset.

it doesn't HAVE to be anything. it's just how it was setup by satoshi. but we don't have to agree with everything satoshi did do we? we can try and offer ideas for improvement.

That's not thinking, that's just describing how Bitcoin protocol works.

Well, that's true. And since fee calculation and generally mempool rules are just preference you can start a PR on the reference implementation repository with the new change and see if people accept it or not...

I'm personally against this and won't run a node with this option because of two main reasons. First is what I explained as it goes against how Bitcoin works and second is the fact that we are not at the point where we need to worry about miners' revenue to need to do anything to increase it for them. Miners are earning enough money and they have additional ways of increasing that revenue as well (like merge mining for instance).

Your idea sounds okay but it might not be applicable based on the setup of the Bitcoin network. I think the focus should be on how to tackle NFTs made with the Ordinals protocol and others. If these attacks on the Bitcoin network are halted, transaction fees will remain low.

Bitcoin transactions are recorded in the Blockchain, so it will be logical and fair to charge transactions based on how many bytes of space it will occupy rather than the value of the transactions. Sending transactions with many inputs or outputs should attract more fees since it will take more space. One can seek ways of reducing transaction fees which include monitoring the mempool for low transaction fees, coin control, lighting network, and transaction consolidation.

If you know the transaction priority, then you sort your transactions by this priority. Which means, that transaction with priority 1,000,000 is put lower in the queue than transaction with priority 2,000,000. Also, as an experiment, you can just grab the current mempool, apply those rules, and see, which transactions are selected, and which are skipped. You could be surprised.

Only because we didn't reach the maximum size of the block yet, when this rule was active. But in general, that kind of rule can be used, for example as a starting point, to see, how well or bad it is selecting transactions.

No fee rules can enforce it. Even if you change consensus rules to enforce fees (which I think is a bad idea, because why miners shouldn't be able to pay zero fees, if they are going to collect those fees in the coinbase transaction anyway?), then still: it is possible to make an artificial traffic, only to meet your rules, and this is probably not what you want. Say, a transaction X would be forced to pay 0.01 BTC. Then, transaction X could pay that, but the miner could send 0.01 BTC back to the user, just to override some stupid fee policy. And it is possible to join those payments, then both will be accepted, or none, so it will be trustless.

Also, we had some altcoins, which were advertised, for example as "feeless". Guess what: people still have to pay: not with coins, but with time instead.

Another case was some exchange, which charged too huge fees. Guess what: it was exploited, when miners sent to them some payments, using a lot of small coins, so the exchange was forced to pay those miners back, when moving received coins.

So, to sum up: you can enforce your own fee policy. But you cannot expect, that everyone will be forced by consensus rules to follow it. The best you can do is making a new "de-facto standard", similar to "1 sat/vb", which we have today.

Then, it will hurt you in the long-term scenario, where you will send a single satoshi, and pay a single satoshi as your fee. Which means: you will be forced to pay 100% fees in that case.

In general, percentage-based fees is one of the reasons, why I stopped using some LN channels. Above some amount, it was just more profitable to pay size-based fees, than amount-based fees. And then, some of my coins simply left LN, because if you have 0.01 BTC, and your fee is 0.1%, then you pay 1k satoshis. While on-chain, with a minimal fee rate, you can get it confirmed for much less than that (I had some batched on-chain transactions, when I paid 80 satoshis per output, and LN was unable to compete with that, because of percentage-based fees in some channels).

Also, your code may explode, where "total_value" will be zero, because then, you will be forced to pay a single satoshi anyway (created out of thin air?). I hope you won't decrement some zero-filled uint64_t, and you won't repeat Value Overflow Incident in that case.

I don't think that's a good idea because the current way of calculating the transaction fees depends on the weight of the transaction.
It doesn't depend on the amount of the transaction. People can send even million dollars for barely few dollars in fees but that would change if your technique is implemented.
I personally think that the current way is the best and should be kept as it is. We shouldn't alter the tech behind bitcoin.

Not arsed to look up old information but plenty of coins have tried to use a fixed fee structure, eithee in coin units or percentage of units. No need for me to tell you that did nothing for sustainability.

Can imagine it also further disincentivises LN channels. Imagine someone willing to fund a channel seeing it dwindling after many on chain settlements.

Still, nothing's stopping you from putting up a proposal.