Topic: Bitcoin's transaction fee lowered by 4000% - page 3. (Read 711 times)

SegWit really changed Bitcoin for the better. Compared to 2017, Bitcoin has become incredibly profitable in terms of fee

I've noticed that the transaction fee has been quite low for a year or so, but nothing special about the last couple of days. I am used to seeing that the normal fee is less than a dollar, and priority fee is a bit more than a dollar (when you send 0.02 or so). Yeah, it's a big improvement in comparison with 2017, but it seems to me that it's actually a temporary thing that is explained more by the network not being that busy rather than significant improvements. If the price jumps to $20k again and people get much more active, the same problems will come again... Scalability is still the biggest obstacle to Bitcoin's adoption as money, as for me.

Yes i remember it was right after the price peak of 2017, in January 2018 a low fee transaction could easily take weeks or even a whole month, those days were very crazy, who knows if that also fueled the bear sentiment, and sure certain altcoin promoters have used that excuse ever since.

Still, after around March 2018 such a transfer fee crisis has never occurred again. And then came Segwit etc.

As for coinbase i'm sure i said it back then, it was a very American thing. Elsewhere its irrelevant, but Americans love it for whatever reason.


The other problem i see with transaction prices is that by then many wallets had the "auto detect the optimal fee so it takes n block(s) to confirm". Too many wallets have that enabled by default, so it isn't particularly difficult to provoke a chain reaction that feedbacks it self Its like the attackers have a wiling army of bots worsening the problem.

Yes, once upon a time wallets didn't guess anything, the transfer price was always manually set and things worked fine. But now they all want to "confirm within the next block"...

This is not even Bitcoin's fault but most Bitcoin wallets happily adopted the practice, contributing to the problem. This is why i keep telling people to always force the wallet to use 1 sat/B unless its absolutely urgent. If you plan ahead you can do 99% of your transactions without a hurry, relax and check again tomorrow and for sure your coins will be there, no matter if you paid 3¢ or 1$ in transaction fees.

And when the time comes when we can finally have 0.1 sat/B transactions, I'll switch to manually always use that too.

One welcome side effect of the LN adoption is that it should reduce the onchain traffic somewhat. Again, i would leave that only for exceptional situations (like using a credit card for emergencies only).

Well, it's been a long time since the mempool was flooded in such a dramatic way as it was flooded in 2017-2018 (don't remember the exact time period, just that it's been a couple of years). It's possible that the "spammer" is still creating transactions, but if he does, it's no longer to a degree that causes issues with other people.

There is no real way to ip ban spam transactions. Transactions are broadcasted trough the network, nobody knows who created them. Ip's are not recorded on the blockchain, nor are they transmitted together with a transaction. If you really wanted to ban "spam" transactions, you'd have a hard time, since there is no difference between a spam transaction and a "valid" transaction (spam transactions are valid aswell).

You could ban peers you suspect being the source of spam transactions, but all nodes would have to use the same blacklist (and the spammer can just use a different ip to broadcast his spam, so you'd have to update the blacklist every couple of minutes). If one of the nodes wasn't willing to ban the suspect peer, the suspect would still be able to broadcast to the node that didn't use the blacklist, and this node would still relay the spammers transaction unhindered.
A second thing you could try is to convince miners not to include transactions using unspent outputs funding certain address lists, but nobody knows the complete lists of all addresses belonging to the spammer's wallet, nor would the miners be willing to help you (since they're missing out on income if they do this).

Neither of these options is bulletproof or feasible, and all options would depend on incomplete, centralised "blacklists" that would have to be honored by the complete network (all nodes and all miners), and one option would even cost the miners a substantial amount of income, so it's not likely they would be willing not to include valid transactions that have a higher fee per vbyte just because somebody says it's spam.

If we put aside the assumption most people have about who the "culprit" is, and why he/she spammed the network, only a couple possible explanations could be given as to why the attack stopped:

Either the attack was deliberately, and it stopped because the culprit reached his/her goal, made his/her point or ran out of funds
OR
The attack was unintentional, and the "culprit" found out he was the reason why the mempool was filled to the brim (and the fees were out of proportion) and he/she stopped spamming... Or maybe it was unintentional, and the "culprit" just needed several thousand tx's confirmed, and once this was done he was content.

I wonder if the spam attack still happens or is it reduced? Been long fees went up that high.
I wonder exactly how that was fixed(assuming it has been fixed). IP ban? Or through some other means?

The 3 causes for the high fees were the spam attack, the constantly big change in price (triggering various bots) and the lack of batching.
I remember that Coinbase and other "friends of Roger Ver" were accused to cause quite a problem (some have telling numbers of 70% or so for the transactions) by refusing to implement batching.. or at least delaying it.

Off-topic #1. BCash narrative is still sometimes based on "cheap fees" exactly because of this.
Off-topic #2. I don't know why bitcoiners still use Coinbase when they were known for favoring BCash and working against Bitcoin.


But I have to agree that excepting the spam attack period the mempool had its cooldown periods (sooner or later).
Even now a big variation in price causes a spike in fees, but it's smaller and it's usually getting absorbed within a day. We'll see what happens in the next FOMO bubble.

No, the number is not the same a the peak in 2017



https://www.blockchain.com/en/charts/n-transactions?timespan=all&daysAverageString=7

Those 50k transactions mean everything.
You have a maximum capacity that is not used currently, there are still blocks that are not full

617358   1.234.954 bytes
617357      753.964 bytes
617356   1.306.193 bytes
617355      943.467 bytes

When that capacity is reached fees will go up, and it all depends on how much the capacity might be exceded.
If it's only by 1% then people it won't affect the tx too much, just that some will start batching their transactions and stop spending dust, if it goes to 100% then expect an increase to the same levels as 2018. Although that would also come with more LN adoption.


Yeah, it was even worse for a brief period

The fee does not depend on the amount of BTC you're sending. It depends on the size of the transaction.
The size of the transaction depends on the number of inputs, the number of outputs, which kind of addresses were funded by the inputs and which kind of addresses you're funding with the outputs.

A transaction using 1 input with a value of 100 BTC creating one output of 99.9999 BTC will be a lot smaller (thus cheaper) than a transaction using 100 inputs of 0.01 BTC to create 99 outputs of 0.01 BTC (eventough only 1 BTC was transferred in total, vs 100 BTC in the first case). In this example, it doesn't even matter if the second transaction was between segwit wallets, or batched...)

Correction by mocacinno
Basically it somehow depends on the amount of BTC you are transacting with, that's why it could reach up to 20 dollars at that time, plus, if the market is congested, transaction fees could significantly increase. That is why it is advisable that if we transact, we should make sure that the market isn't congested too much because the amount of transaction fee might be high. So, if we are transacting using batch and with the technology that Segwit could offer, our transaction will be more efficient.

Segwit and batching aren't responsible for a 4000% drop, i guess you're just comparing the fees of a large transaction in the middle of the 2017 spam attack (that fueled bidding war for fees) and the fees of a normal transaction right now.

A couple years ago, somebody was just spamming the mempool with thousands of transactions, so in order to have a decent chance of getting your transaction into a block, you had to outbid all those spam transactions... The fees were insane, but the attack only lasted a couple of months (if memory serves me correctly), before and after the attack the fees have always been very reasonable.

I probably start with a question, have you noticed the decrease in transaction fee of average bitcoin transaction of today?

In the past 2017, the demand for bitcoin is nearly the same for today. And according to this resource, the bitcoin's average fees today is $0.50 dollars in comparison to $20 dollars wayback 2017.

Moreover, the reason behind this decrease and improvement we have is the SegWit and payment Batching. Before, it seems that SegWit isn't providing the best solution to solve the problem of huge transaction fees. But for today, we can see its effect since the transactions of this time is somehow the same with 2017.


In relation to the news concerning bitcoin-related searches, the demand for bitcoin seems to increase significantly over time. I just not sure if SegWit could handle an all time high and huge amount of transaction since we are near to a serious event of bitcoin halving.

There's no doubt that most of the cryptocurrency enthusiast are now suggesting a transaction using SegWit wallet address and since we now have the information regarding its effect on the bitcoin's transaction fees. I don't think we still have a reason to stay with the traditional bitcoin address.