Quote from: o_e_l_e_o on Today at 07:39:53 AM

Which algorithms/user see this, see a total mempool of under 0.3 vMB, of which more than half is paying less than 3 sats/vbyte, and decide pn fees of over 100 sats/vbyte? What a waste of money.

Poorly implemented ones or those that don't know any better and has a fixed fee rate.

Quote from: LoyceV on Today at 08:05:07 AM

Those algorithms are what pushes up fees so quickly once blocks are full. If a block is filled with 1 sat/byte transactions, you could get priority over those by paying only a little more (say 1.1 sat/byte). That could lead to a very slow increase of fees (1.2, 1.3, ...... 2.0), but instead it quickly goes to 10, 50, 100 and more. I don't mind people wasting their money, but they drag others with them too.

If you're in a hurry, it is simply not an option for you to increment fees slowly nor is it for those services where withdrawals/coin movement are time-sensitive. You can't really compromise in this aspect; if your algorithm guarantees a confirmation within the next block, your algorithm should suggest a fee which does exactly that. Slowly incrementing the fees for the algorithm simply won't work and would probably result in far longer wait before a confirmation for most. There should not be a scenario where the algorithm suggests a fee that risks not hitting the target, some services doesn't really have a choice; CPFP makes the TX unnecessarily expensive, RBF is not an option. The penalty for them is unnecessary costs with their transaction and the user has to be the ones boycotting them.

Currently, Bitcoin Core suggests a fee of 1sat/vbyte for a confirmation within the next block. Not all algorithms are flawed.