Topic: Should we have a two, or even three, tier fee structure? (Read 545 times)

the problem with that is not all larger transactions are junk. so that kind of takes a shotgun approach to solving some perceived problem and might end up hurting the wrong people. as someone already pointed out, since the transaction fee is based on sat per vbyte, you already have a mechanism that makes people with larger transactions pay more. no need to double down on that.

not to get too far off topic onto ordinals but if people keep rallying and complaining about them too much and try to stop them then people could switch over to something else like Bitcoin Stamps which stores the monkeys in the UTXO set. you can never get rid of them then. you can't prune them or anything. Luckily right now Bitcoin Stamps is a very lowkey project only 65,000 or so of them. Maybe it's best to keep it that way... so yeah you got a point there. invalidating ordinals could mean the monkeys move to something more problematic like Bitcoin Stamps.

Agreed. I think I've cleared out my opinion on soft forking for this limitation (and I've covered the why). But, as standardness is concerned, I'm all in to do that. If there's serious economy behind Ordinals they'll continue surviving as non-standard. If standardness prevents such a thing, then there wasn't a serious economy in the first place.

And yet, there's no manner to prevent someone from deliberately bloating the UTXO set. If your goal is to stop "blockchain bloat", then invalidating Ordinals is the wrong path.

Again, if your goal is avoid treating bitcoin as copyrighted material, then that's not the right approach. As I have already said, Ordinals (and any kind of data) can become indistinguishable from regular transactions, if there's the required demand.

It's also not about what the miners don't "respect", it's about merely about incentives, which I believe OP never truly considered looking at it from the network's perspective.

From OP's viewpoint,


Nothing would change because the miners would still prioritize the transaction that's paying a higher fee than the lower one.

Plus different mempools for financial transactions and dick pics? It would still be the same, miners would remain including those transactions from the dick pic mempool first simply because of the quadruple fees.

What do you mean they don't respect it? That IS how they prioritize transactions they include in their candid block, by computing the fee rate through the transaction weight (ie. what SegWit introduced) and accept the transactions that pay a higher rate.

I understand what you mean, but that's not what I was writing about. Of course each miner/pool can do what they want. But the pool has to take incentives into account. If I create a mining pool with a fee structure which is unattractive for miners, then they simply would use another pool.

So let's reformulate the question of the OP: "Can we have a two/three tier fee structure which all miners would respect in a voluntary manner because they would maximize income from fees if they do, and not if they don't?"

And that's what Segwit achieved: they did something different than simply an arbitrary rule "transaction type X will should be included even if they pay less fees than type Y" (like the priority mechanism was, afaik). Segwit established a rule for miners "you can include more (real, not virtual!) bytes into a block from transactions of category P2Wxxx / P2TR than from 'legacy' P2PKH/P2SH transactions" (because in P2Wxxx/P2TR the witness data is separate and doesn't count for the 1MB limit). So miners would be stupid if they didn't respect this rule, because they wouldn't be able to maximize income from fees.

And to answer the reformulated question: do something similar what Segwit did (like I wrote in the last post).

By the way, thank you for the code snippets from old clients. I wasn't aware of these completely free transactions But yep, you're right this was also a two-tier structure, similar to Segwit's.

Changing fee structure alone, and nothing else, require no forks at all. You can create a new mining pool, and include your own rules. You can build 20-tier fee structure, and your blocks will be accepted. It is all about including transactions into your blocks, a simple binary decision: include or exclude. You can introduce any weird rules you can think about, and require no fees or 10x fees for vanity addresses containing "vjudeu". There are endless possibilities, and for example we already have almost 4 MB Ordinals transaction without any fees, and there was no fork needed to include it.

You want to get a link to some old client version?

Of course. You can check some early blocks, and find many free transactions in the chain, for example check block 170, it has one non-coinbase transaction, and there is no fee. Even in the first released version, there was GetMinFee function:
As you can see, there was at least two-tier fee structure. You can also see usage of this function:
And another place, where it was called:
This model is older than priority-based rules, but by checking different versions, and grepping "GetMinFee" in the source code, you can see how it was changed over time. Today, you can find this code:
You may notice that there is no hard-coded value like "thousand satoshis per virtual kilobyte", because you can change settings in your node, and even allow free transactions, without recompiling binaries. Of course, default settings are the most popular ones, and most pools enforce them, but no consensus changes are needed to change those rules.

It makes more sense to limit this concept to on-chain transactions, for me. (Otherwise we could include several more tiers, like sidechain, pegged chain, trusted offchain ...)

You can still insert more "real" kB of Segwit transactions in the block than using legacy.

So while we have a unique "virtual" measure to create a "single virtual tier", if using "real" bytes it's a two-tier structure.

The reason is obviously the different data structure, where the witness data is located outside of the 1MB "window". If we were to introduce a third tier, a similar method would have to be found to reduce the weight of the new transaction type even further, which would be challenging if we are limited to a soft-fork scenario. It would be perhaps easier to introduce an intermediate tier between Segwit and legacy, for example limiting the current Segwit discount to simple script types. (Allowing a hard fork however, everything would be possible).

IMO a quite interesting way to do this without hard fork would be the use of rollups and its inclusion into the major Bitcoin apps (Bitcoin Core, Electrum), albeit they need some protocol changes. With rollups, simple transactions could be bundled, and thus would consume far less space. Of course rollups are a "partly offchain" method but the relevant data are onchain.

Can you elaborate or provide me a link? Were there transactions which were completely free? (I've found this but it's not well explained.)

The priority mechanism seems to me also quite different from the "witness discount": miners could abide or not, and as less and less miners used it, it was finally completely disabled. While the witness discount is different, as due to the data structure differences, a miner simply can stuff more Segwit transaction "real kB" in his block, so he can charge less fees for them without losing money due to opportunity cost.

This is true, but Lightning always benefits the honest party by its timelock rules. So in the end I think security would be higher if Lightning closures could get a "special treatment" as the lowest-fee/highest space allowed tier. Wormhole attacks afaik aren't primarily a security threat but a malicious technique to raise income from routing fees, but given the low general level of routing fees (which according to threads I read some time ago isn't expected to rise substantially even in a high-LN-usage scenario) I guess incentives for this kind of attack should be quite low.

There would be of course side effects, for example people could find transaction methods which use the same scripts like a LN channel closure but aren't, to benefit from the lower fee. Thus it would be a challenge to prevent spam attacks, and thus the weight discount for this transaction type can't be too high.

How could it work? Or how could it be a better option?
For example, transaction with 1 input and 1 output is 109 vbytes in size while transaction with 1 input and 6 outputs is 264 vbytes in size. If I will have to pay triple or even more in transaction with 3 outputs, definitely I'll send three transaction, each 109 vbytes in size.
And in this case I think tier fee structure should look something like this:
1 input - 1 output = 10 sat/vbyte
1 input - 3 outputs = 20 sat/vbyte
1 input - 6 outputs = 30 sat/vbyte

You can calculate it other way, change input numbers and so on but this is just a brief and clear example.

Transaction with 1 input and 6 outputs will cost me 8K satoshi and six transaction with 1 input/output will cost me 6.5K satoshi. Also, I think, this kind of fee structure will scare bitcoin users.

Looking at things from this point means that you can say we have three-tier fee structure, if you include Lightning Network. However, fees for witness are not another tier: they are combined into a single value, by using transaction weight. So, in practice you can see a single parameter: satoshis per virtual kilobyte. And based on that, you don't need to know, how many bytes are in witness, or in legacy. You just know that some transaction has 1234 satoshis per virtual kilobyte, and you can place it in the block, based on that single value (so there is no additional tier needed).

If in the end it will all end up in a single value, then it will still be a single tier. For example, there were old rules for transaction priority, also called coinage. How many tiers can you see there? Also, can you see the difference between free vs non-free transactions in the past, and the current model, where there are no strict borders, and everything is more smooth?

If it would be only priority-based, I would say there is only one tier. But because it was explicitly splitted into free and non-free parts, there were two tiers in this model. Also, you can read why such model failed, and how people abused free transactions. This is also a lesson, why having a single tier is better.

Fees can be changed without touching consensus. You can create a mining pool with any new rules, and then they will be enforced, proportionally to your hashrate.

It would also bring more attacks into LN. Just instead of a regular, on-chain attack, you will see more LN-based attacks instead. Another thing is if more attackers will move into LN, then when forming a route, you will see more than one attacker's node in your path, and that means more attacks like Wormhole Attack. Because every stick has two ends: if closing channels is cheaper for regular users, it is also cheaper for attackers.

We have already a two-tier fee structure. Segwit introduced it: we pay more fees for legacy-style (e.g. P2PK, P2PKH) transactions than for Segwit-style (e.g. P2WPKH, P2TR) transactions.

We always have to take into account that miners will always want to include the transactions in their blocks which net them the most fees. The way Segwit's two-tier structure has been achieved is the clue how a more advanced fee structure could be implemented without the miners' consent - miners will follow the new structure purely by incentive.

The principle would be very simple: give different transaction types different weights. This means in reality: allow more block space being occupied by a group of transactions, according to their type.

For example, one could, without problem, allow a higher amount of block space for simple transaction types which only allows the traditional OP_HASH160 OP_EQUAL structure, creating a third "fee tier" behind Legacy and Segwit. All transactions with more complex scripts stay with the current fee structure. That would incentive using Bitcoin only for simple BTC transfers, and disincentive e.g. Ordinals inscriptions. But it would also disincentive other kinds of contracts.

This is only an example, we could for example also benefit Lightning channel openings and closures with a lower weight/allowing more block space.

I don't know if I would agree with such a change. There are however some interesting variants of this concept to think about. Benefitting Lightning closures with a lower weight however could be an example which would add more security to LN, because in the case of a massive attack by a malicious node, this would allow channels to be closed earlier and thus make the attack more difficult. So I think this could be an interesting long term idea. But it's not something I would want to see implemented in the short term.

I'm talking about different ways of limiting different ways to attack Bitcoin. Sometimes it is a hard limit by making something invalid (eg. 100 byte limit above) sometimes it is a soft limit by making something non-standard. But in both cases we are preventing attacks and abuse of the system but with different approaches.

In case of standard rules, sometimes they are applied because we want to leave the protocol open for future expansions. Like witness version 2+ being nonstandard.
Sometimes they are applied because there was a flaw in the protocol that needed to be "fixed" without needing a fork. Like restricting the dummy data used by OP_CHECKMULTISIG(VERIFY) operations.

The actual problem as I have said many times is that people are abusing Bitcoin. The extra fees is the side effects of that abuse. There are a handful of other negative side effects of this types of attacks, including but not limited to: blockchain bloat, the UTXO bloat with dust outputs, extra cost of running a node, possible legal issues involving the content of this attack that could give some malicious governments the excuse to put pressure on businesses and individuals using bitcoin, ...

I know you hate nft/ordinal/BRC-20

but they are simply being used as a non transparent way for fees to be boosted.

The top five pools make 87% of the blocks.

As a small commercial miner I do not have enough hash to solo mine.

I have to use one of the top pools to be paid often enough to pay overhead.

Ie 5000 kwatts a day is about $250 a day for 5 cents power.

That is $7500 a month. If I do a smaller pool and it has two pool months in a row I could fall behind in payments for power.

So miners with decent amount of gear like myself have to mine at the top five pools.

We are pretty much a captive audience. You need a lot more gear then I have to mine solo.

3eh is enough which is about 3000 s19s.

This leads to my point the danger is not ordinals/nfts/BRC-20

The danger is 87% of the hash is at five pools.
For all we know the ordinal/nft/BRC-20 is all their work in an effort to hide that they have boosted fees close to 30sats a byte.

My guess is they will eventually make 80% of a block available at 30sats or 40sats or 50sats a byte and the rest at whatever. As rewards shrink those pools have to boost fees

6.25  + 0.75 = 7
3.125 + 0.875 = 4
1.5625 + 0.9375 = 2.5
0.78125 + 1.21875 = 2.0
boosting the fees lowers the ½ pressures

the 0.78125 + 1.21875 = 2.0 is only 2032 not very far

A block today is about 7 coins with fees say 183,000
A 2 coin block in 2032 at 100,000 a coin  means the block is worth 200,000

mining model could hold up at those numbers.

Realistically 2032 will be when fees first average higher than rewards.

Jet Cash’s tiered fees could work.

It's not just a bad idea, but if a person truly got how Bitcoin actually works, entertaining the idea or merely asking about it, would never have entered the person's mind. I'm sorry for sounding a little arrogant, but it's true, and I'm not claiming that I know everything about Bitcoin either. It's just the way I understand Bitcoin is that, decentralization only works when the participants in the network are honest. And they are kept honest through incentives.

Bitcoin's incentive structure/fee market already works. There's no need to play with it.

Change the current incentive structure, and you cause a domino-effect that might make the behavior of the participants to be more unpredictable. It's better to keep it simple and conservative, just my two sats.

And I have repeatedly told you that this is simply false. Not always. Sure, block metadata is very limited, but transaction metadata is virtually not. It's entirely valid to send 0 coins to the Bitcoin whitepaper, represented as an OP_RETURN. This has always been the case. Sure, the Bitcoin network marks most of these as non-standard, but you're not arguing for standardness but for validity.

And, as an emphasis to the title of this thread, the "problem" with Ordinals isn't that they're using the network as cloud storage per se. It's the extra buck "genuine Bitcoin users" have to pay to gain priority. If that wasn't the case, I'm pretty sure y'all wouldn't care the slightest of what these people do. You just don't think it's "worth" the extra buck to have them on the chain, but I'm honestly curious if you acknowledge this way of thinking can be imposed on your activity as well.

That's true but that has always been extremely limited to prevent exactly this type of abuse that turns bitcoin blockchain into a cloud storage. For example the coinbase scripts where you can store "metadata" and Satoshi used in Genesis block has always been limited to 100 bytes (0.01% of total block size) and you can only have one of them per block.

But we already have the liberty of choosing the fee structure and depending on how much a user is spending per transaction also decides their transaction speed. So it all come down to one fact that whether user want high speed transaction or slower transactions. For example, if user is spending priority fees per Vbyte then its obvious miner would be more than happy to confirm it faster thus both ends are happy.

On the hand if user has paid low fees per vbyte then miners would give them least priority and anyways their transactions will be stuck on the network for very long.

Creating your layer of fees could make it complex or easy depending on how users and miners use that system.

Ordinals isn't a Bitcoin feature per se. Abusing the possible mistake you've outlined isn't a feature, it's indeed unintentional. However, including metadata in a transaction has been a feature since January 3rd, 2009. The manner which will happen isn't, but the fact is that you could always include non-monetary data in a transaction.

No, we didn't, at least not in a sufficient scale. Legacy addresses are still usable, while they're very inefficient compared to native Segwit, first and foremost. Uncompressed public keys in Segwit were never standard to switch to non-standard. Inefficiency is inevitable in backwards-compatible software.

Who does what?

I think I was just throwing up a possibility to try to avoid the hijacking of an extremely advantageous medium of exchange by purveyors of rubbish. Their aim seems to be to disrupt the Bitcoin concept, and to scam the gullible users of the system.

I think maybe, Jet Cash got the proposal backward.

---

Either way, I don't think it is possible to implement what the OP is proposing.

It is important to remember that the "mempool" is just a localized set of valid transactions that are not yet confirmed, according to a node's current understanding of the blockchain. There is no historical mempool, although there are some projects that store some historical information about the status of their nodes' mempools.

If the maximum block size is nkb and there are nkp worth of valid transactions in a pool's mempool, it is reasonable to expect the pool to confirm all transactions in the mempool, even if there is a wide variety of transaction fee rates among transactions. So if there was a requirement for pools to include certain valid transactions prior to accepting other valid transactions, it would not be possible to validate if a particular block is valid after the fact.

Except that it is not a feature, it is an oversight. A mistake that the developers who introduced the new Witness Version 1 protocol (commonly known as Taproot) made when defining the consensus and standard rules that restricted this type of attack.
A mistake they did NOT make when introducing Witness Version 0 protocol and placed appropriate restrictions that prevented this type of attack.

We did do that!
After Witness Version 0 (commonly known as SegWit) soft fork using uncompressed public keys became non-standard and you won't be able to get such transactions propagated through the network.

Not everyone
We also did increase the block size since block size hasn't been 1 MB ever since 2017.

I don't understand how one can determine whether person is clogging mempool or not and how will they have to pay financial penalty.
In any way, if someone wants to abuse fees, they'll succeed. You can't set fixed transaction fees because price is very volatile, will be unfair and will do nothing good. Even if you set tier fee structure, how is that gonna help you? I'll make dozens of small transaction fees and will enormously increase transaction fees for low tier transactions that will push high tier fees to rise.

---

Btw everyone here is against the increase of block size but I don't know how do they imagine bitcoin that has two times, four times and even more number of transactions daily. But to my mind, lighting network looks very cool and promising.

I think that adding any fee structure to the protocol is a bad idea.

One problem is that it could backfire. For example, your fee structure would encourage splitting up one large transaction into several smaller transactions that would take up more space overall.

The problem with this is that, first of all you have to define what's "clog", secondly, you have to enforce that definition to a decentralized network, and thirdly, you have to figure out what the penalty will be (and I'm pretty sure any such penalty will be chosen arbitrarily).

Sounds a terrible idea. To begin with, that disincentivizes doing coinjoin, because it is purposefully large in size. But besides that: you can penalize someone from broadcasting a large transaction, but you can't penalize them for dividing it in separate small transactions, because there's pseudonymity. So, the result will be much more smaller transactions, with minimum-to-zero "clogging" prevented.

I would like to be referential in relating my reply to this post with a comparison to how most centralized financial banking platforms use this different tier fee structure to accommodate the users transaction fees based on the volume per ratio amount to be transacted or that is usually transacted.

The idea on a decentralized system might be better too, as it will free up congestion on the network thus speeding up transactions.
I would rather it isn't left to the miners, unless having two mempools is too much work for you.  It might get confusing at first to new users and some old users who has grown accustomed to the former, but once an update in software app automatically directs an account to the best suited fee charge per the volume to be transacted via the network tier fee structure, one would enjoy the ease per transaction speed and efficiency, I can assure.

I'm with what @pooya87 said: fix the loopholes in Taproot which make Ordinals and BRC-20 crap possible. We would still have the OP_RETURN data storage ability but that's not as convenient as the current loopholes.

For the miners there's no real benefit to stop or control the mempool clogging. They benefit from clogged mempools as timely important transactions have to pay the premium fee to top existing waiting transactions. And people have to learn to observe the mempool state and choose reasonably suitable fees, unless you don't have to care about overpaid transaction fees for whatever reason (but that's kind of throwing coins out of the window into miner's pockets).

It sounds like looking for a central decision.

Today fee could be used as a 'priority' marker, if all the fees would be fixed, how would you estimate when transaction is going to be processed?
Talking about ordinals - yes, we may say that after years of improvements how to make transactions smaller finally someone proposed something opposite but at the end it is a feature and possibility, so why not to use it? If we focus on efficiency we would have to say that for example we should stop processing outputs from uncompressed addresses as there was enough time to switch to something more efficient.

That's like saying girls should ionly become a little bit pregnant.

I think they should be able to properly define what spam is in order to identify and reject them.
Spam in Bitcoin context is simply Irrelevant & unwanted transactions that come in quick succession or in multiple amount in a given time. A transaction has to be relevant to the purpose of the Blockchain to be accepted otherwise it may be rejected alone or must be rejected if found to be spam.

Blockchain is purposefully designed for financial transactions or light data.
Heavy NFT or other heavy stuff could be allowed once in a while on a Blockchain but rejected when they became common/frequent.

It depends on what you mean by "smaller and larger".

* If it is purely based on size of a transaction then it must not be implemented at all because a transaction with for example 20 inputs is considered a "large" transaction, but actually this type of transaction should be encouraged not discouraged because it is consolidating outputs which actually helps improve scaling of bitcoin by optimizing the usage of the limited block space. That is a single tx with 20 inputs is smaller than 20 tx with 1 input each.
That means if the fee of such transaction is to be higher according to your question, they would be forced to create multiple transactions with smaller number of inputs to pay a lower total fee which would increase the total size they waste.

* If it is based on the "garbage" data they insert into the transaction using exploits in the protocol like what the Ordinals Attack is doing these days, then this method is not useful because we are talking about a vulnerability in the protocol that is being exploited, doing anything other than fixing the exploit itself is just wrong!

once before just suggested here there would be an "oxidation fee" on coins which remain untouched for many years. so the whole consensus / security providers of Bitcoin blockchain (miners) that keep safe these coins for an account could get paid by the account owner..

this was just an example for the importance of having more tiers of fee structure - big like!

Sounds a bit unnecessary. Just cut out the middleman and block off the spam transactions in the first place. Problem solved. I think otherwise it would just make people weigh their return profit over their transaction cost loss and spam the blockchain anyway. NFTers are going to scam people for thousands if not hundreds of thousands per NFT. Would a higher transaction fee make them think twice? I don't think it would. Worst case scenario it would only give miners the impression that spam transactions are more rewarding than regular ones. Then those spam transactions turn into priority transactions.

What causes rejections of transactions is when the fee is low and can't carry the confirmation process and most sometimes some of the exchanges needed high fee to process faster,using insufficient before fee is like turning everything upside and it's contradictory to understand.

Maybe they should, but it needs a lot of brainstorming to implement that correctly. I can imagine many things that could go wrong. Currently, we have satoshis per virtual kilobyte system, and everyone can see how it works. Before, there was a coinage-based system: the older your coins were, the higher priority your transaction had. Also I saw some people mentioning UTXO-based fees: the more UTXO you create, the higher your fees are. And if you consume many UTXOs, you make it easier for pruned nodes, so maybe that should be even rewarded with some discount (or some buffer for free transactions to do that kind of UTXO cleanup, but of course it should be designed carefully to avoid misuse).

That way or another, it is possible to change that without any fork. The hardest thing is presenting a better system, and convincing mining pool operators, that your way of handling it is better than the status quo. And of course, you can start with your own full node, then you will see if your local mempool is really handled better, because the first step is to check your system in practice.

No matter what model you will take, it is hard to design a system, where you won't punish transaction batching (and UTXO-based fee model mentioned above also has the same problem). Because if you have a transaction that has one input, and creates hundreds of outputs, it does not mean it is automatically bad. It could be some batched withdrawal from some exchange, and if they for example collect all withdrawals, and produce one transaction per 24 hours, then you don't want to punish them (because replacing all of that with hundreds of small transactions would be worse).

One mempool is all you need. After all, finally you have a single block, and all transactions are placed in a given order. Either you include or exclude something, it is that simple. Of course you can locally make it more complicated, and have 20 layers to filter things, but finally, it will be a single binary decision: you include or exclude some transaction.

This is precisely how the bitcoin fee structure works already. Fees are calculated in sat/vbytes, that is you pay based on the size of your transaction, one with a weight of 1000 vbytes would pay more than one with a size of 100 vbytes.
Size is the important factor in fee estimation.

Nodes can also adjust their mempools to reject incoming transactions which submit a low feerate relative to the network congestion at the time.

- Jay -

No, the fee structure is fine as it is. The only thing changing it will do is add complexity and cause more issues.
Even now people are severely underpaying or overpaying what is needed causing confusion.
Add more tiers and you are going to wind up with about a billion questions of 'why is this a tier 2 it should be a tier 1' and so on.

Take a look at block 791175 someone paid 1023 sat/vB when just about 50 sat/vB would have made it into the block.
Can you picture adding tiers to that?

-Dave

As it stands right now, a miner could already chose to not put those spam transactions into the blocks they are trying to solve.  It would be trivial for any miner to edit the algorithm that's selecting the optimal transaction combination from the mempool in order to fill the block they're trying to solve so that those spam transactions are no longer selected (or only selected if they pay an insane fee).

They chose not to do this, because they're trying to optimize their income.

In order to force the miners into rejecting spam transactions, i'm pretty sure we would require a fork (a fork that would have to be accepted by the majority of the network)... Eventough, as it stands right now, it might be possible they (the miners) are sacrificing short term profit for long term loss since this situation might in the end hinder bitcoin adoption, bitcoin price increase, and eventually their income aswell...

It might be a good first step if somebody wrote a patch for the default node implementation so the pool owners that still run the default client at least have the option of rejecting or at least discouraging those spam transactions??? I don't believe many node operators would chose to run a patched node tough.

I think, to discourage clogging the blockchain, you could implement a fee structure that charges lower fees for smaller transactions and higher fees for larger transactions. The fee validation process would involve classifying transactions based on size or complexity, and validators or miners would verify the provided fee. Insufficient fees may result in rejection or lower priority for inclusion in the blockchain

Should people who effectively clog the blockchain pay a financial penalty. If smaller transactions ( smaller in size, and not in value), were charged a low efficiency fee, and larger ones had to pay quadruple ( say ) fees, then there would be a disincentive to submit so much rubbish on the blockchain. How could this be implemented? Would it require two mempools, or just approval by the miners?