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.