Topic: Solution to high rates? Maybe not, but it's an idea... - page 3. (Read 344 times)

This solution already exists. You can create a 23 sat/vB transaction, broadcast it, and then use ----> https://mempool.space/ speed up service in order to speed up obtaining confirmations. Then you can use your bank card, gift card, or other payment method in order to speed up Confirm the transaction.

In short, the mining pool can choose any order of transactions it wants and accept them for a fee of 1 sat/vB, but why would they do that? They already earn an average of 1.0299 additional BTC/block with each block mined, so why should they settle for 0.3 Bitcoin? If someone told you that the price of Bitcoin is high and it is better to fix the price at $10,000 so that everyone can buy, would you agree?

The problem is that there is no such thing as "the mempool", every node has its own mempool with the transactions it received. A transaction may be in a mempool of one node and not in other node..

In my opinion,  The problem isn't the economy of the ecosystem  , the incentive of the miner or how they chose the transactions thay goes into blocks.  Those things should not change, as they work in a very delicate equilibrium.

Ordinals problem should be faced directly imo. They should move to l2 solutions,  or l2 solutions should be improved so everyone could use them. I don't think LN is enough,  as it is still hard to use imo.

Ordinals in LN would be amazing for everyone.

Since the increase in the ideal percentage of blockspace has birth to having the numerous capacity to contain more than one transaction leading to layer 2 protocols and reduced in thebrate of mempool congestion, this same available space after the increase of block eize to be able to accommodate more transactions leads to how the ordinals swindles it way forward into the increased blockspace for efficiency but now turni the whole network into a competitive survival of the highest bidders between the normal users which are the bitcoin transactions and Ordinals.


We may not want to decrease the blockspace anymore because it has already solved the problem of delay in transaction confirmation time and mempool congestion,none thig I Know is that the mempool cannot be always thst busy, there will be times it will be more less congested and the fee rate could be as low as less than $3 during weekends or weekdays, in such regard, we cannise viabtc to accelerate our transaction, or make protocols the priotize bitcoin transactions first over Ordinals, but onna real sense the Ordinals are paying more than the host are for their transaction confirmation to be fast.

A lot of debate has been ongoing regarding the high fees in Bitcoin transactions lately. Many ideas have been suggested: blocking Ordenals or the massive use of Layer 2, while others propose increasing block space. In short, numerous ideas have been put forward, lacking unanimous agreement but fueling discussion and analysis.

I would like to present another idea, perhaps less popular than the previous ones, but which I consider to be minimally viable. This idea wouldn't significantly alter the current functionality; rather, it would serve to ensure that all transactions can be processed in a timely manner.

The idea is as follows: Ensure a percentage of space in the blocks so that older transactions, regardless of the fee amount, can be processed.

I'll try to explain. Imagine that 10% of the block is allocated to process transactions that are over 48 hours old, regardless of the fee used. Similar to the current process, transactions still enter a queue, arranged from the highest to the lowest fee. However, an additional element is introduced to create the queue: the transaction date. In this way, if a transaction is not processed after 48 hours, it enters the queue based on its release date. From that point onward, the blockchain will process the oldest transaction first, regardless of the fee.

For example: imagine that when a transaction is sent, the average fee to be processed in the next block (approximately 10 minutes) is 80 sat/vB. However, the sender only includes a fee of 50 sat/vB. The network continues to operate normally, and after 2 days, the transaction is still not processed. At this point, it enters a waiting queue where the oldest transactions are processed first, in sequential order. Since there are still 100 transactions ahead of it, it will have to wait for several more blocks to be processed. In the end, the transaction is processed, for instance, 52 hours after it was originally sent.

Now the question arises: won't everyone start using 1 sat/vB since they know transactions will be processed in a minimum of 48 hours? Yes, that's a possibility. However, we can consider two factors: if there are many transactions at 1 sat/vB, it might take significantly more hours for them to be processed; secondly, even within the system, rules must exist.

For instance, if two or more transactions have the same date, which one takes precedence? The one with the higher fee.
What if there are thousands of transactions at 1 sat/vB? They will still have to wait their turn, potentially taking many days, similar to the current scenario.

One could also establish a minimum for a transaction to enter the queue based on the waiting time. For example, calculate the average fee of all transactions in the queue after 48 hours. Then, process transactions above this average fee first, maintaining the principle of prioritizing the oldest transactions rather than the highest fee.

This is just a different suggestion to try to minimize the impact of high fees. It provides a minimally viable perspective for ensuring that a transaction doesn't linger for weeks waiting to be processed, even with a reasonably acceptable fee. This approach allows everyone to plan their transactions more effectively while retaining the freedom for each individual to set their fee. The only difference is that there is a probability of the transaction being processed more quickly than in the current model.