Thanks for the replies. I do realize that it is not realistic to expect this will be incorporated into Bitcoin. I might implement an alternate chain at some point, since there are several other ideas I'd like to test out as well. However, I don't have that much time right now.

As far as the fixed block size goes, as I understand it this is intended to be increased at some point. However, since it is not adjusted dynamically (like the difficulty is), it does not seem that this would both allow for the capacity to increase with demand and also impose enough competition between transactions to increase fees, in general.

Anyway, this may very well turn out not to be a problem in practice. It's unfortunate that this won't be tested until Bitcoin has been around for many years (until the block reward decreases to a small amount).


That's an interesting idea.

It may increase or decrease, but this will not be a result of the block reward changing.

Fundamentally, the reason for this is that the block reward change is predictable (we already know it is going to happen). Suppose that the effect of the block reward halving was that the price would double. Then people would buy bitcoins now in anticipation of this - and as a result the price would go up, until it reached double the price now, before the block reward halves. But of course, we've known this would happen since the start of Bitcoin, so in fact no such sudden change could ever occur as a result of this predictable event. Any changes in the value of the Bitcoin must result from events that are unpredictable by at least some part of the market.

I think this is arguably a better idea than hashcash. The reason is already given: since different devices have different efficiency in computing hashes, using hashcash would make it too expensive to send emails from, e.g., a smartphone (or if attackers used specialized hardware, then it would become too expensive to send emails even from a desktop). In contrast, this would allow you to send emails almost instantly, and even a small fee would act as a sufficient deterrent to spammers.

However, I don't think this will take off, for the simple reason that spam isn't much of a problem these days (given the existence of Bayesian filtering). If my inbox was overflowing with spam, then I would be prepared to go along with this, but, as it stands, it really doesn't seem necessary.

On the other hand, it might be useful in other similar situations - for example, a one-time fee to create forum ids, which would act as a sufficient deterrent to spammers (who would quickly be banned and hence lose the fee). And then we wouldn't have to make 5 posts before being allowed to use the whole forum.

Hello everyone. I'm an anonymous Maths and CS student. I have an interest in Bitcoin, both the practical (it's use as a currency), and the theory (the generic idea of a block chain, and the possible things that could be built on top of it).

I'd like to ask a question about transaction fees. I've read at http://bitcoin.stackexchange.com/questions/876/how-much-will-transaction-fees-eventually-be that transaction fees are not set in an effective way by the market (in particular, they would be too small), and that this could be a problem once new bitcoins are no longer generated. I have an idea for how this might be solved, but I am not sure if this is already a known idea, or whether it will actually work.

The problems described at the above link is that there is a "race to the bottom": miners will always want to add "one more" transaction to their block if has a non-zero fee attached, even if it is too low of a fee to cover the cost of mining (since the cost of mining is largely fixed with respect to the number of transactions in the block). As a consequence, people sending transactions wouldn't have an incentive to set a "reasonable" fee. It is an instance of the tragedy of the commons.

My proposal would (maybe) fix this. The idea is: each transaction would set a maximum fee, and the miner would set a fixed fee for the block (per byte). The miner would be allowed to include any transaction such that the fee per byte times the size of the transaction is less than the maximum fee set in that transaction. All of the transactions would then be charged the same fee (per byte), and the remaining amount for each transaction would be sent to an output specified in the transaction.

In this case someone wanting to send a transaction could not make their fee arbitrarily small, since then no miner would ever want to include it (since they would lose out on the fees from other transactions). Additionally this seems more "fair" in some sense, since everyone would pay the same transaction fee.

On the other hand, I have no idea what the equilibrium fee would be under this system. Also, of course, this would be a major modification to the protocol, and so may be difficult to implement in practice.

EDIT: To clarify, my actual question is whether this system has been considered, and whether it would work/what problems there might be with it