The difficulty target is independent of how many transactions there are in a block. I'm not sure what Steve is getting at - perhaps the fact that adding a transaction involves recalculating the merkle tree? The cost of that is trivial compared to the cost of mining though so I don't really understand the point.

random off-the-wall idea: how about making the minimum tx fee track the difficulty changes?

since difficulty itself is a function of price, albeit with quite a bit of hysteresis, setting min tx fee changes to track difficulty changes via some kind of monotonic inverse-relationship function would automagically set tx fees to reflect bitcoin value, in a one-step-removed kind of way.

(again, just as a stopgap, until better code to 'free the tx fee market' is in place)

it seems you have completely misunderstood the proposal. higher difficulty would result inlower/ minimum fees, not higher ones. just as now we're going from .01 to .0005. I quote, with some extra emphasis added:


yes - but the talk here is not about that at all, but about the 'minimum fee' required when using transactions with small inputs, to prevent dust spam.

no, just indexing the dust-spam threshold to bitcoin value. just as is being done manually with the change from .01 to .0005 in this here RFC.

the fees based on TX volume remain as they are. the anti-dustspam fees are really quite a separate beast from the regular 'transaction volume fees'.

I like this concept, but you still have to have some notion of what an ideal difficulty would be (which should be something that is adequate for protecting the network against attack).  Without that, you wouldn't know at what scale to vary the fee against the difficulty.  That ideal difficulty would also change over time as computers become more powerful (so, block number might also need to be a part of the function).  It would be really nice if someone could figure out how to model the vulnerability of the network based on some kind of observable statistics or patterns.  If you could solve that, it could be an input into the fee structure.

Ok, "as high as possible" is close enough.  So, what would that mean in practice?  The largest sustainable amount of wealth that the community could throw at mining?  The current block award of 50btc is 0.0008% of the total number of bitcoins currently in circulation.  Of course, with lost bitcoins, this percentage is actually higher.  So everyone holding bitcoins is subsidizing mining by this amount via inflation.  That's a drop in value of 0.000008 btc for each btc in circulation.  This percentage declines as the number of bitcoins in circulation rises.

I could imagine normalizing difficulty increases for Moore's law (to get a truer reflection of difficulty increases attributable to increasing bitcoin prices vs difficulty increases due to more computing power available at a lower price).  You could use something like 2^(blkNum/105120) for this normalization (105120 is approximately the number of blocks created in 2 years).  After normalizing for increasing hardware power, you then need to look at the question of how the average block reward should be levered to increasing bitcoin prices (is the relationship between price and difficulty linear after factoring out Moore's law?  i.e. if the price doubles, is the difficulty expected to double assuming hardware prices and power remain constant?).  Assuming a linear relationship between price and normalized difficulty, for a doubling of the price of bitcoins, how would you affect the average block award (in bitcoin terms)?  Cut it by 12.5%, 25%, something else?  I think you'd want to cut it by less than 50% if price doubles...you still want the increasing price to result in increasing block awards.  One the block award is determined, clients could look at the average number of transactions and the current generation award level to determine the minimum fee.  While there is still a 50btc generation reward, the formula could work out such that the minimum transaction fee would be zero.  But when the generation award drops to 25btc, the minimum fee could be something non-zero and based on this function and designed to replace some, but not all, of the 25btc that is no longer being awarded in the generation transaction.

Have no rules and let the miners decide. 


Let the Bitcoin clients check how many transactions are 'in waiting' and what fees they have.

Provide a dialogue that asks the user to specify a fee, calculating the 'expected time till inclusion in a block.'
This dialogue should include a 'suggested' button that autos to the minimum expected fee needed to get a confirmation within an hour.

A warning should be displayed if the fee is too low and the expected time for inclusion is more than 100 blocks.  However, the user can still take a gamble and send the transaction.


The best option is to provide the miners choice of what fees they want to have, and to provide the end-users the option to select the minimum fee they need for their uses.  (some people don't care if the transaction takes a day, but want to minimise their fees).

I think generally, including a transaction fee at this point will always get you into the 'next' block.

After some informal discussion on IRC, it was decided that it is better to phase in the TX fee change over two bitcoin versions. 

As implemented prior to commit 2bfda1be11a079f7b468c79d79a91ddb30369557, transactions created by newly upgraded 0.3.22 nodes may not be relayed (or, at least, TX fees not honored with priority) if the new, lower TX fee schedule is used...  until a sufficient amount of the network has upgraded to the new rules.

So, for 0.3.22, the relaying and block creation code will accept the lower fee schedule (0.0005 BTC), but when creating a transaction, you will be using the familiar transaction fee schedule found in 0.3.21 (0.01 BTC).

This will help ensure that a sufficient amount of the network has upgraded to the new TX fee rules to ensure that transactions created by version 0.4 with 0.0005 BTC fees will be accepted and relayed.

(if you really want to create TX's with the lower fees in 0.3.22, you can still use -paytxfee, but those transactions may take a very long time to confirm)

To be specific, you need a non-trivial percentage to upgrade, in order to relay (at least one of 8-50 connections), plus a fair number of miners to upgrade.  Miners seem to upgrade fairly rapidly, so "not long" ... we hope.