Topic: What will keep transaction fees up? (Read 15442 times)

I just saw a blog that stated that the tenX wallet dont charge any transaction fees for BTC transactions.

After i tried it, i can confirm there are no fees. After transfering 1USD my friend recieved 1USD.  

How ist that possible?

This was posted when I was away from Bitcoin for a while. I've just been referred here by another thread.

A miner or group of miners with >40% of the hashing power can mine more than their fair share of blocks under very reasonable expectations. Someone with 46% of the hashing power can win 51% of the blocks. I now call this strategy "hostile mining".

Recent post here https://bitcointalksearch.org/topic/m.99312

ByteCoin

Oh, thank you!  And your quite welcome.


Although there is nothing wrong with anything you said in this post, bear in mind that the act of securing 50% of the generation is no small task even for a cartel with nation-state resources, and maintaining that majority is vastly more difficult.  I won't say that it is impossible, but I would say that the odds that any single nation or private group acting in concert could maintain such an escalating 'generator war' against not only the existing and/or future bitcoin community, but also the generating capacities of nations or other private/political groups who have something to gain by opposing the desires of the cartel/nation attempting the takeover would be somewhere close to the odds of a verifiable bitcoin address collision within my lifespan.

Which is to say, slim to none.

@creighto, in general thank-you for sharing your excellent understanding of economics!  It is well appreciated, by myself, and I'm sure many others on this forum.

On cartels:

There will never be a problem with a cartel that has less than 50% of the generation power.  The problem lies with a cartel that has significantly more than 50%.  Any block that accepts transactions that the cartel rejects (i.e. low fees), would be orphaned by the cartel, and in a short time later, the cartel will have developed a block chain much longer than the chain developed by the so-called 'scabs.'

The only way I can foresee the free market correcting for the cartel, is for the people conducting the transactions (as a large group) to ignore the cartel's block chain when they behave badly, and only accept the (shorter) scab chain that isn't accepted by the cartel, until the cartel gives up and accepts the chain with small transaction fees.

The problem for bitcoin is that when this 'war' / standoff between the people doing the transactions and the cartel happens, there may be a good 20 blocks of uncertainty before a winner is decided.  It really is all about 'my gun is bigger than yours.'  This could mean that there would be a good 2h of time where transactions will not be secure from double spending.  However there is nothing stopping a smart client from checking both chains.

Some clients may have a default fee amount, but I doubt that those will survive in the marketplace.

There can be no 'cartel' in Bitcoin, because there can be no monopoly.  The barriers to entry into the generation pool are simply too low, and there is no way that a government could enforce an artifical monopoly even if it wanted to.  If the transaction fees begin to creep up due to consolidation of the generation pool, others will begin to notice and they will choose to participate as the possibilites of a random reward become worth the costs.  This will create a price point that is ever fluctuating, but balanced, as this effect removes any pricing power of any group of generators in collusion.  I would predict that the transaction fees will be somewhere between 0% and 3% on average, but closer to 0%; because 3% is where the credit card companies and PayPal have set their prices, and they do have a degree of pricing power.  If a 'cartel' were to set up a datacenter that could dominate the network, but only include transactions with fees at say 2.9% (PayPal's regular rate), they would be ignoring an entire set of fee paying transactions that only non-cartel generators could capture.  The results being that the network would generally see that 2.9% is the premium price to get one's transaction recorded quickly, but if one is willing to wait until one of the non-cartel generators then there is a budget option (currently that option is free).  The cartel could not be certain that they could even capture the premium fees, so they would have a choice to make.  Either recognize that they don't have the kind of pricing power that they thought that they did, or ramp up their generation capabilities until they do.  The second choice creates an 'arms race', as for as long as the cartel increases their capacity, they must attempt to pass on that cost, but they can only do so temporarily before non-cartel generators see a profit opprotunity to do the same.  Eventually the cartel hits a point that it can no longer continue, and in the meantime the system has benefited from their attempts to corner a market that cannot be cornered.

Of course, anyone with the resources to do any of this is also going to hire people who know the system, who are likely to point out that they can't really do what it is that they want to do.

Bitcoin will look at network conditions and make a guess for you.

Will there be a default fee amount included in future clients, or will be have to guess/check what the average miner is charging to process transactions?

Yes I believe the real potential issue is the 'cartel,'  I'm not worried about the transaction fees being too low, rather too high.  I think that studying this with game theory would be very fun, but, I don't have the time also.

Yes!  This sounds cool.  When generators disagree there will be inefficiency, confusion and confirmation-delays.  It would be useful to mediate agreement among competitors.


Miners could do it now, but the software-capital cost and uncertainty look high enough to postpone it for a while.

Meanwhile, it should be possible to simulate the network.  No need to calculate hashes, just model a population of generators G[0 .. g] pulling hashrates HPS[0 .. g] and having their own rules & motivations, and some clients.

This needs three sets of parameters,

• one to describe generators (effective costs for electricity, existing hardware & incremental hardware purchase) and allowing for resistive heating, gamers' hardware habit as well as hard-nosed corporations etc.
• another to describe 'voluntary rules' used by generators for declaring a block of transactions valid.  We have ideas here, they just need a weighting parameter each s they can be combined.
• finally (the hardest?) for a model which generates transactions among a population of merchants, speculators, hoarders, spammers etc..  Assuming they all know what the 'rules' are at any time, but can only influence them by generating, spending or getting patches accepted and installed.

Might make an interesting student project (one semester?).  I don't have time, sorry.

I suspect the generator rules can vary with time, but to fend off chaos they should be a deterministic function of the content of previous block(s) and not depend on the transaction pool.  I also suspect that if the customers & merchants do not hold a significant fraction of the Ghash/sec, the 'rules' will tend to make a generator cartel with high fees.

That was not my complaint.  One non zero transaction would also only allow for one zero transaction.


I would say so.

I don't disagree that there is a preservation motive to rival the profit motive, but I think that the profit motive is far more prevalent. Only some want to preserve the integrity of the chain, but everyone wants to make profit. As it is, contributing as an honest node is more profitable than attacking the network, but remove the incentive of fees and profit motivated generators become profit motivated attackers. Will the network be strong enough...


It would only take one non zero transaction to cut out the freeloading spammers. A generator could inject one himself, which would force clients to match it or come close. Anyway, da2ce7 has me half convinced that miners should be imposing their own rules on the blocks, forming a democracy. It's not like anyone can stop this anyway: A miner is always free to reject any block, for better or worse, for whatever reason it sees fit. So, I guess the conversation about block rules is moot and the question of how to keep fees up is in the hands of the mathematical (game theory) viability of the protocol. Has Satoshi already figured all of this out, I wonder?

Well that's just fine. if there are no other fee paying transactions, the generator can accept the 0.751 and the 0 and still satisfy the rule, but he can't accept another 0 fee tx. Though, I now believe it is flawed for other reasons.


This is an interesting, market based solution. Generators can stop competitors from undercutting them, by "voting" out blocks that don't adhere to their own customized rules. I'm not convinced that it is sustainable. It looks like a problem for game theory.

If generators get too greedy, accepting all transactions, They run the risk that most of their peers will reject their hard work generating a block. If they reject blocks that their peers have accepted, they'll waste time working on a smaller block chain.

If this sort of thing works, then miners should be doing it now! This will stop the spam problem: If miners start rejecting blocks that are too generous to spamers, we shouldn't need a block size limit. I suppose, though, that the block size limit IS an implementation of a voluntary rule. Though a rather primitive one, it's sufficient for now.

Perhaps miners will converge to using an optimal rule, similar to what I've described and I'm trying to preempt this development. This definitely looks like the problem of finding an "optimal strategy" in game theory.

Not surely, but maybe.  I don't think so because of the preservation motive is nearly as strong as the profit motive, and because there will still be some who can generate at a negligible additional cost, so there is no point at which generation is unprofitable.  The confluence of these motivations will ultimately create a self regulating market with a fairly stable difficulty level.  The real question then becomes, is that difficulty level secure enough to defend against a brute force attack?  That is a question that may never be answerable.


That's the wrong question, because none of us pay our electric bills in bitcoin just yet.  The question should be, how high would the difficulty level be if the reward were worth less than $13?  The answer would be less, but the total value of breaking the blockchain would be less as well.  It's a self-balancing system, almost organic in how it acts; and any risk calculations that could ever be devised would be incomplete due to the human factor.


I was still considering it, myself.  I think that the priority system does much of what you are trying to do except allow the blocksize to stretch; and I have concerns about the bounds of this rule.  Without the priority system, this rule would permit blocksize spamming anytime there were only free transactions in the queue, so there would have to be a minimum allowed average fee, even if that were just .00000001 bitcoins, but then that would prohibit any transactions from being processed at all in the absence of a fee paying transaction even if there was an altruistic generator who won the block.  So there would have to additional rules to permit altruistic generators to help clear transaction backlogs, because there is bound to be more free transactions to process than fee paying ones for the foreseeable future.

I offered a plan before you posted yours, and no one commented upon it either.

I'm very hesitant to support a protocol change that puts any sort of restriction at all on what a miner must put into a block or leave out.  That can and should be something which is decided by the miner itself.  Also, it is possible that the miner node itself can put in all sorts of bogus transactions to fiddle with this sort of arrangement anyway, and that just adds overhead as well as wasted data storage when miners have to deliberately make stuff up to get some fees.  A miner could include a whole bunch of transactions that would "lower" the average TX fee allowing the miner to include some additional "real" fees, if any.

Still, it is an interesting way to set up an algorithm that also puts some emphasis on transaction fees.  I'm sure people who have dedicated miners would love this.  You could also say that blocks of a certain size (current max size or perhaps a bit less) could include more "free" or "cheap" transactions or simply follow the current rules.  There is much to be said about this concept.  I wonder if there is a way to "fix" these problems?

'No more than half less than the average' will not maintain the transaction fees, without other factors pushing up the fees.  The fee will progressively get lower as the low side will get attacked harder than the high side.  In the above example a transaction fee of 0.751 will increase the average very slightly, then the next transaction fee of 0 will lower the average (relatively) much more.

The current breed of stock generators, generate continuously, and only ignore a block if it is deemed illegal.

When transaction fees become the main incentive to generate a new breed of generators will be developed that will maximize the profit made.  One of the features of this bread of generator is that certain 'rules' will be voluntarily agreed upon, some will not accept blocks that have two many low fee transactions, and will wait for blocks that have only higher fee transactions.

The risk of a generator who accepts too many (new) low fee transactions is that the most of the network will ignore and orphan it's block.

I just feel that any motive other than profit, will not be good enough. I agree that profit is not the ONLY motive for generation as you have pointed out, but other incentives are just too weak and will result in too few generators. The network will be too weak and will surely fail.

How high do you think the difficulty would be now, if there was not the 50BTC incentive to generate? I think it would be < 1000.

No one has commented on my idea of placing a rule on fee distribution on blocks to prevent the acceptance of arbitrarily low fees.


This forces clients to compete with each other for the current block, eliminates the need for a fixed block size (ie. fixes the spam problem) and scales to accommodate any number of transactions. If a spammer sends lots of small-to-zero fee transactions, only some of them, if any, will be accepted, because you can only include max 50% fees which are below the average. To include more smaller fees a generator will have to include more larger fees.

Think about it, clients will compete and a stable market rate for fees will be established. Tiny fees, too far below the market rate will not be accepted soon and fees above the market rate will be guaranteed to be accepted in the current block. It's a simple protocol rule for generators which should be computationally cheap.

Do you guys get this? Perhaps I haven't thought it through enough, it's just a proof of concept; the exact details can be refined. Does anyone have a reason that this can't work? Maybe it's just a really crap idea, but I would appreciate SOME feedback, please.

Blocks and transactions have version numbers in them. These are distinct from the client version number, and have always (AFAIK) been 1. Client versions are not included in the chain, but they are communicated to network peers. Version is a signed integer, so the limit is about two million.

There is already a network alert facility. If Satoshi broadcasts a signed message to the network, text will display in all Bitcoin clients of the specified version. Alerts can also disable the JSON-RPC interface, shutting down all sites that rely on Bitcoin until the network becomes safe. A more decentralized scheme would be a good idea in the future, but it's not needed now.

I'm interested in what will ensure clients & generator stay up-to-date (before discovering that transactions are not being confirmed or blocks are being ignored).  Software in general has a really terrible track record of staying recent, perhaps because people are involved, people forget to maintain things, and don't trust automatic updates.


Do the block-generator or transaction-creator record client version in the block?  I see "ver": 1 fields in the raw json of BBE, but what is connected to this?  Is the range of values limited?  (Sorry, I will read the code One Day^TM.)

Making incompatible changes (size params, new hash alg, fee schedule...) at a specified blknum in the near future makes sense because everyone synchronises on the central timestamp.

Daemons & GUIs are sitting watching a stream of version number go past on blocks and transactions.  If they see something new, should they not enquire about likely consequences?  This could be centralised (IRC or project home page) or P2P (like the transactions?).

• e.g. I'm running ver:1 and I see ver:2.  I ask the neighbours and they don't know anything about it.  I consult the project homepage and it says "incompatible change of class coming at " and signed by (hmm, feature request for reputation management) so I inform the neighbours and start nagging the hoomun to do an upgrade before , or face .
• e.g. I'm running ver:50 and I see ver:57 go past.  I know (wired into client) that I can deal with anything between ver:46 and ver:60 so I accept the block and go looking for more info.
• e.g. I see ver:61 arrive.  That's out of bounds.  I could quit; I could refuse the block (and potentially fork the chain).  My options are limited, so it's not clear that the "acceptable version range" idea is very useful...
• e.g. I see ver:58 arrive.  I ask for the changelog, see it's signed by someone I trust and it says I have a security hole.  If I'm sitting on cash, or running on the user's workstation inside the firewall, I might immediately disconnect myself and run offline.  If I have no cash and was configured to know I'm in a DMZ, I carry on and let the sysad worry about security.

They're just ideas...  but without accurate client version stats (linked to the svn revision number?) it's hard to know the age of the transacting & generating populations until something goes bang.

I think your idea of wait will surely happen, but it won't be waiting to release, it will just be waiting to start working. It is actually more elegant the way it is as we get the most difficulty for a given amount of power that way.