The problem with transaction fees

[marcus_of_augustus]

(Posted on other thread first but more pertinent here).


Current coins in circulation 5.7mill, average 24hr transactions around 200-250K ... or about 1500BTC per block.
http://www.bitcoinwatch.com/
with current exchange rates to "real world" monies that people use to buy mining gear and electricity with it is currently profitable on 50 BTC per block.

So extrapolating out to 21mill BTC in circulation, with similar money velocity as now, is about 800-850K per 24hr, or about 5700 BTC per block on a rolling average. Interestingly, if you assume a sensible round number average fee of 1% you get 57BTC per block for fees in the mature bitcoin economy .... hmmmm.

Recall that due to the deflationary nature of the beast, and the divisibility (2.1e15 satoshis), 800K BTC per day in transactions could represent the combined wealth transfers and economic activity of who knows how many millions of people. So that even a 0.01% average fee (6BTC per block) may easily incentivise quite substantial future mining rigs.

[1713571624]

1713571624

[1713571624]

1713571624

[1713571624]

1713571624

[caveden]

One solution would be to have a maximum block size limit that automatically adjusts itself. It can be made so that it's always "tight", possibly pushing fees up. There's a thread for this: http://bitcointalk.org/index.php?topic=1865.0

Another solution would be to leave solving this problem to the miners, instead of trying to impose layer upon layer of "community generated red tape". What a bunch of control freaks...  

The block maximum size is not only a "miners problem", it's the whole system, since it's a criterion that says whether a block is valid or not.
And this constant will probably have to change one day, if we want this project to scale. And such change will be backward incompatible. And as always, it's damn difficult to organize a backward incompatible change after your protocol has evolved enough to have multiple clients everywhere.

If this backward incompatible change will have to be done one day, why not make it only once (by setting an automatic adjustment rule), and why not considering making it now, while it's still easy?

It's not related with transaction fees only, it's related to the scalability of the bitcoin network as well.

[Gavin Andresen]

If this backward incompatible change will have to be done one day, why not make it only once (by setting an automatic adjustment rule), and why not considering making it now, while it's still easy?

Patches welcome.

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

When we get close to bumping into the block size limitation it will be easy to convince a majority of the network to upgrade-- that's one problem that is obvious and easy to fix.

[twobitcoins]

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

We already assume no attacker has 50% of the computing power.  If we choose an adjustment rule based on median block size, it should be immune from that type of attack.

[caveden]

If this backward incompatible change will have to be done one day, why not make it only once (by setting an automatic adjustment rule), and why not considering making it now, while it's still easy?

Patches welcome.

Great, now I only need to relearn C++!

Sorry, no patches coming from me... but I'm glad you are open for it.

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

For the jerk with a botnet to succeed with this he would need to either pay lot of transaction fees to include spam transactions in everybody's else blocks, or make the spam blocks himself.

If he's paying, well, miners are getting properly rewarded, the jerk is not a jerk anymore, he's rather an impulsive consumer of miners services. Miners will probably make him pay whatever they need in order to sustain such irrational demand.
Honestly, I don't see this happening.

Now, for him to make it on his own, he would need an immense amount of computing power. Having more than 50% of the network is already a way more dangerous thing than spamming, so let's assume he's not that strong.
Let's say that he has something like 25% of total power, which is already a lot.
He could act in two ways:

Stupid jerk mode: He fills all his blocks with spam, refusing everybody else's transactions. This is stupid because he'd be wasting money, by refusing to accept the transaction fees from others. I suppose people running botnets are not that stupid, but sill, what could the stupid spammer do?
Let's suppose the network is already running with a block size limit of 110% of the average needed. Now, the jerk occupies 25% of the space with garbage, forcing all transactions to be in the remaining 75%. That should be 82,5% of the needed space, so such space will get filled and the block size limit will increase. But how much should it increase? It would stop increasing as long as the 75% space not occupied by the spammer is 110% of what is needed. If I'm not lost in the numbers already, this super-spammer with limited intellect would make the block size limit around 144% (one third + 10%) of what it would need to be.
Anyway, what I want to say is that is that the relative damage he could cause is proportional and limited to the computing power he has, since as soon as all transactions are fitting in the space the spammer does not control, the bock size limit would stop growing. (I probably made some mistakes in the numbers above, but I hope you get the picture)
Having 25% is already a lot, and the relative damage for this stupid-mode is not that great.

By picking an arbitrary constant too much higher than the actual needs of the network, we'd probably be giving spammers much more space to spam. Actually, right now, with this 500Kb limit, a spammer with all this power could probably do much more relative damage, making the network download much more than it would need to.

Now, assuming that the spammer is not that stupid and he accepts paying transactions into his blocks, that greatly decreases the relative harm. Actually, his blocks would contain around 10% of spam only, the rest would be true transactions. He would barely move the block size limit, even with a great computing power.

When we get close to bumping into the block size limitation it will be easy to convince a majority of the network to upgrade-- that's one problem that is obvious and easy to fix.

I hope you're right on that. Nevertheless, consider what I said above: a high constant gives spammers much more opportunity, and risks not creating a sufficient artificial scarcity to incentive mining and thus weakening the network. And a low constant would require frequent backward incompatible changes.

[caveden]

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

We already assume no attacker has 50% of the computing power.  If we choose an adjustment rule based on median block size, it should be immune from that type of attack.

That's pretty much the tl;dr version of my previous post.

[casascius]

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

I almost would welcome the jerk - the jerk would help us make the network strong while the window of opportunity is as open as it's ever going to be.  The jerk would be doing us a favor.  He should be charging for the favor.  It's a "stress test".  Everyone knows the current version is non-scalable and will HAVE to be fixed.  So why not fix it sooner than later?

Just like the jerk who exploited an overflow bug in 0.3.9.  We're now stronger because of it.  It was far easier to get a few early adopters to upgrade, than a mass of five million users.

There is a huge amount of non-consensus as to what will happen when the going gets tough.  It would be far better for the longevity of the system to have it happen experimentally than have it turn off a whole influx of users.

A jerk who spams our block chain may very well give us the motivation to start working on scalability promoters like making blocks prunable, or allowing people to run "full nodes" versus "minimal nodes" etc.

No matter how much spam one jerk can produce, real transaction volume is eventually going to eclipse it... that is, if the system will scale to support it.

[MoonShadow]

What about keeping the hard limit, but adding an occasional exemption, say every retarget block can be as large as necessary to clear the backlog. (or ten times as large, or 100 times, whatever)  That way, the longest delay that a cheap/free transaction is a couple weeks, and the clients without much bandwidth only has to deal with an oversized block occasionally and on a predictable schedule.

This way. the near term scarcity that would drive transaction fees in the future would still be present, and donations won't languish to unrealistic terms.

[deadlizard]

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

We already assume no attacker has 50% of the computing power.  If we choose an adjustment rule based on median block size, it should be immune from that type of attack.

At this point that is not a safe assumption.

O.K lets do the math
Network total - 0.506 Thash/s  = 506Ghash/s = 50600Mhash/s  / 600 = 85 (5970 cards) * 699 (RRP) = $59415 / 2 = 50% of the computing power of the network would cost $29707.50

I forgot where I was going with this ... oh right, I'm sure ATI sold a few more than 85 "5970" cards so it's deffinetly not a safe assumption.

[casascius]

O.K lets do the math
Network total - 0.506 Thash/s  = 506Ghash/s = 50600Mhash/s  / 600 = 85 (5970 cards) * 699 (RRP) = $59415 / 2 = 50% of the computing power of the network would cost $29707.50

I forgot where I was going with this ... oh right, I'm sure ATI sold a few more than 85 "5970" cards so it's deffinetly not a safe assumption.

506 GHash/s != 50600Mhash/s

Off by a factor of 10

[marcus_of_augustus]

Would someone mind specifying the 'max block size' limitation is tight, well-defined systematic way? Is there a link to the problem definition, e.g. bug report?

I'm getting the gist of it only through the passing comments but hard to get a grasp on the complete animal that way.

[Jim Hyslop]

O.K lets do the math
Network total - 0.506 Thash/s  = 506Ghash/s = 50600Mhash/s  / 600 = 85 (5970 cards) * 699 (RRP) = $59415 / 2 = 50% of the computing power of the network would cost $29707.50

Leaving aside the factor-of-10 error pointed out by cassacius, wouldn't an attacker have to double to size of the network in order to control 50% of it?

In other words, suppose the current hash power of the network is xMhash/s. If the attacker adds 2 / x Mhash/s, then the total network power is 1.5x, and the attacker controls 0.5x, or 1/3 of the network.

[MoonShadow]

O.K lets do the math
Network total - 0.506 Thash/s  = 506Ghash/s = 50600Mhash/s  / 600 = 85 (5970 cards) * 699 (RRP) = $59415 / 2 = 50% of the computing power of the network would cost $29707.50

Leaving aside the factor-of-10 error pointed out by cassacius, wouldn't an attacker have to double to size of the network in order to control 50% of it?

In other words, suppose the current hash power of the network is xMhash/s. If the attacker adds 2 / x Mhash/s, then the total network power is 1.5x, and the attacker controls 0.5x, or 1/3 of the network.

Yes.

[MoonShadow]

Would someone mind specifying the 'max block size' limitation is tight, well-defined systematic way? Is there a link to the problem definition, e.g. bug report?

I'm getting the gist of it only through the passing comments but hard to get a grasp on the complete animal that way.

The max block size is currently a hard limit of one megabyte.  The current fee structure is designed to make hitting that limit prohibitively expensive, by limiting the free transaction section (to 20 kilobytes, I believe) and an exponentially increasing set of required fees for transactions to be included above certain arbitrary soft limits.  I don't recall the actual fee schedule, but a block larger than half a megabyte would be very profitable for the miner that solved it.

[sdmaxx]

It is true that the current BTC transaction fee depends on the actions of miners at the time and the system volatility at the moment in BTC netowrk, currently BTC transaction fee is floating around $10-$16 which is not a reasonable fee for low amount transactions. This might decrease the people' s interest on BTC transactions and that may affect for decreasing the demand for BTC. This might affect very badly for BTC network and total crypto world as BTC is the king in the crypto world !

Thanks

[kiver]

i really think your idea of the miners lowering their transactions will sure increase there profits because the amount of transactions on bitcoin blockchain will increase which will benefit them more than two or three transactions on a high fee price bitcoin became more like an asset you keep these days i self dont make a small transactions with due to the high fee price since there alot of good altcoin with a low fee price and fast network which you can pay with , without any troubles i hope miners would listen to the voice of logic and start acting toward that idea which will benefit the miners and the users ...

[mysacrifice]

It is true that the current BTC transaction fee depends on the actions of miners at the time and the system volatility at the moment in BTC netowrk, currently BTC transaction fee is floating around $10-$16 which is not a reasonable fee for low amount transactions. This might decrease the people' s interest on BTC transactions and that may affect for decreasing the demand for BTC. This might affect very badly for BTC network and total crypto world as BTC is the king in the crypto world !

Thanks

That is the biggest problem of bitcoin actually and I am afraid it is effecting its own future. Many people including me is just using alt coins (at least top ones) to transfer money as btc's transaction fee is becoming unreasonable day by day.

[bitfools]

But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore.

I almost would welcome the jerk - the jerk would help us make the network strong while the window of opportunity is as open as it's ever going to be.  The jerk would be doing us a favor.  He should be charging for the favor.  It's a "stress test".  Everyone knows the current version is non-scalable and will HAVE to be fixed.  So why not fix it sooner than later?

Just like the jerk who exploited an overflow bug in 0.3.9.  We're now stronger because of it.  It was far easier to get a few early adopters to upgrade, than a mass of five million users.

There is a huge amount of non-consensus as to what will happen when the going gets tough.  It would be far better for the longevity of the system to have it happen experimentally than have it turn off a whole influx of users.

A jerk who spams our block chain may very well give us the motivation to start working on scalability promoters like making blocks prunable, or allowing people to run "full nodes" versus "minimal nodes" etc.

No matter how much spam one jerk can produce, real transaction volume is eventually going to eclipse it... that is, if the system will scale to support it.

there are 10k jerks a minute pounding btc right now and you know it, the fact that there are so few failrures and complaints of lost coin is amazing,

u already have the 'bch' fork which never met a mod it didn't like, and then core is conservative, but everybody is hell-bent on breaking core, what happened to if it ain't broken, don't fix it?

problem is u all try to make all things to all people, btc will never scale to be a day-trading platform for ever 2bit jackass on earth to buy/sell 0.0001 btc orders every millisecond, it would be far better to just let the trading exchanges churn that shit and take a cut on the thrash, as the house always wins,

also this notion that every toilet in India/China/Africa should charge BTC for the 1cent shit and that be a transaction, again they already have that in those country's and its called the cell-phone credit ( a form of crypt cash )

BITCOIN is a bank for rich techies, live with it, and then for those not to lazy to have made the +2,000 BTC forks from the orginal code, then there too you can create your 'master-piece', the problem is that u want stuff to scale and run like ORACLE, then the problem is you need a Larry Ellision to run Oracle, and now it ain't BITCOIN anymore, its NSA;

NSA uses Oracle for their database Ellision wouldn't be a billionaire if not for his CIA-NSA biz, and same reason here big demand to scale up bitcoin so it be the NWO currency, but then again, it wouldn't be BITCOIN anymore if it were run by GOV & VISA asshols

Then in time of course GAVIN and all the 'founders' decide its time that they become the next BILL-GATES of BITCOIN, so then its no longer everybody is a equal node, its a few guys aer TRILLOINAIRES and everybody else is a muppet

[Kakmakr]

This could have worked, if the miner with the lowest fees, would have been able to handle all the transactions coming their way. Unfortunately that kind of hashing power would not be possible, and this is why the load is spread over several pools.

If you change it a little bit, say miners X with the lowest fee is at capacity, then the tx's goes to Miner Y, with the second highest miners fees etc. etc. This would make things very interresting.

The problem will occur, where some miners will be priced out of the mining scene, because they will be unable to compete with the bigger miners with the low fees.

[markleal]

Consider a world where mining only pays out transaction fees. Almost all miners charge a transaction fee of t and all users pay a transaction fee of t on their transactions.

One miner decides to increase his profits by charging a smaller transaction fee. He publicly announces his intention and many users reduce their fee to be on par with the new fee he has announced. The miner increases his profits (because he processes more transactions) and the users save money. All other miners are forced to reduce their fees as well in order to make any transaction fees at all.

This process continually repeats itself until transaction fees are reduced to their smallest possible value and very little mining is done. This leaves the blockchain venerable. One solution is continue to pay out a block reward forever. What do people think?

Hi there ptd! Those transaction fee is really a pain in the ass. The solution you said is quite possible, but I just wondering how those thousand of miners could possibly do that. As far as I know, most of the miners are independent, meaning there is no one who could control their decision in terms of those transaction fees. That is one of the reason government want to step into the system to create a regulation about pricing. But most of us, can’t determine if it could produce a positive or a more negative effect.