Topic: Discussion: optimization of mempool fee levels (Read 581 times)

Why not? The idea of adding more decimal / allow smaller fraction of Bitcoin has been suggested for years, even though most people would wait until Bitcoin price is very high.

But since it requires hard-fork, there are better & easier alternatives such as make default minrelayfee on Bitcoin full-node client become 1 satoshi.

Exactly, I think psychology and our limited brain resources would prevent us to use an "optimal" fee strategy (which would be, in this case, to always chose a fee exactly 1 satoshini per byte higher than what we think our competitors would chose). But it could have a small effect.

Apart from that, 8 more decimal places would enlarge transactions - not by that much, but significantly. Simply chosing "sat/kB" instead of "sat/Byte" seems a better strategy.

Decimal Places.

People start at the lowest and work up. Normal non-spam users would linger in the lowest levels. Why not.

What would happen if - just hypothetically - Bitcoin had 16 decimal places and not 8 ?

1 satoshini was 1*10^-16 BTC.. transaction fee priced in satoshini / byte.

I think fees would come down, but not by as much as 8 decimal places.

I like pooya87's idea of an "increased granularity" (being able to set fractions of a satoshi per byte). However, Core afaik already is using BTC/kB with a granularity up to a single satoshi (and not sat/B) as the default unit. And afaik you also can always select an absolute fee amount.

But lots of wallets and websites continue to use the "sat/B" unit. The reason is probably that this is the unit "most easily digested", with numbers currently of 1-10 in low-fee periods, 10-200 in mild congested times and 200-1000 in highly congested times. If in the last block the average fee of confirmed transactions was, say, 5 sat/Byte, it's reasonable to pay 6 sat/Byte if you want the tx to be confirmed soon, and not 5001 sat/kB.

So increased "fee granularity" in wallets with sat/B as the default option would certainly be desirable, but the impact would be probably not too high. But as there are no risks associated, I certainly would support this kind of measure.

The OP's proposal, however, would probably not work. It over-estimates the "tx relaying power" of non-mining nodes. It gives incentives, instead, to simply connect directly to nodes that you know that they're mining. This will probably become the default behavior if such a mechanism was implemented, as gmaxwell writes.

@franky1: A "priority-based" tx inclusion by miners like in early bitcoind versions would be certainly interesting, but I struggle to understand how this could really be enforced. Maybe like the "weight" calculation in Segwit transactions? However, I've read some time ago that some miners are sometimes selectively preferring to include non-Segwit transactions over Segwit-type ones. If this is possible (and not punishable by the protocol), then it's probably not reliabily possible to really enforce priority-based tx confirmation. (And I'm sure the reason why the priority mechanism was abolished in newer Core versions has to do with that problem.)

If it's possible to enforce, priority-based calculation would certainly lead to lower fees, because it would incentive people which aren't in a hurry to confirm to pay only a very low fee.

this topics idea is no better than current state of affairs.

firstly if using the scenario of say 20mb(WU)(5mblegacy) mempool size where
5sat is priority(0-4mbWU(0-1mb leg)) next block,
4sat is less priority(4-8mbWU(1-2mb leg)) second block,
3sat is less priority(8-12mbWU(2-3mb leg)) third block,

a spammer pays 5sat, gets confirmed then instantly throws that utxo into a new tx of 5 sat and is instantly in the priority nxt block listing.
meaning those that paid 4sat are not guaranteed to be in the second block as the spammer is in the second block too

this, like current status just leads to games of everyone just paying ever increasing amounts, until people give up and the price then eventually resettles until people realise it settled down to then play another round of ever increasing amounts

what needs to be done is bring back a fee formulae that is a consensus rule (have to abide by) which actually has options.

EG if a tx is only 1confirm deep its 'score' is lower than someone with 144 confirms. so the spammer(1confirm) has to pay more to raise its score to be given priority.
this way it actually makes spammers pay the price, where as occassional spenders are not affected by th price. and by using the score based system its not a everyone is hit by a premium due to a few users.

this way it actually make spammers who multispend daily having to pay more, then become more incentivised to spam less or use offchain solutions. while the occassional non abusive user is not paying out alot but getting their transactions noticed by miningpools collating transactions

to explain better

Segwit's not doing a good job of "ignoring most transactions", because most transactions are not segwit. That was how this little debate started. you saying segwit failed due to low uptake.


You're a big fan of non-sensical arguments:

• segwit ignores most transactions
• most transactions ignore segwit

both those things are true, depending on which version of "everything is segwit's fault" you're trying to argue

Well any block size change based on any bitcoin transactions (not just some new transactions that you want to force everyone to use) would have worked.


so....

• mempool full: because segwit
• mempool empty: because segwit

uh, ok