[RFC] New TX fee: 0.0005 BTC

[just_someguy]

Each transaction has to have a hash computed...so each additional transaction would add to the total amount of hashing required (since there is a minimum difficulty associated with every transaction).  The minimum for the whole block just means that up to a certain number of transactions, there is no additional cost.

Are you saying the difficulty target changes for a block increases once it has a certain number of transactions in it?
I wasn't aware of that... and if that is the case I'm struggling to understand the reasoning behind it.
I thought you only had to calculate the merkle root. Yes that does mean you have to do a handful of extra hashes when building your block but it is such as small number that the effect would be immeasurable. Especially if it is done 'offline' before you are even finished working on the current block.

[1714860646]

1714860646

[1714860646]

1714860646

[1714860646]

1714860646

[Mike Hearn]

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.

[Steve]

I guess I'm not explaining it well.  Forget for a moment that you have to find any special hash at the block level (whatever hash the block has when constructed, the network will accept).  But, imagine the network does require the hash of each transaction to satisfy an imposed difficulty.  In that scenario, a miner has to find a hash the network will accept for every individual transaction.  It would then never be cost free to add additional transactions and the free rider problem would be eliminated.

*note: this is oversimplified to the point where it wouldn't work as described here, but in my earlier posts I describe the additional details that would make it work...also note, since you are adding a nonce to each transaction, the system would need to add this nonce to the structure of a transaction since clients would need the nonce to verify the hash of each transaction has an appropriate difficulty.

This would eliminate the free rider problem, but as I mentioned earlier, I'm still not sure the difficulty still wouldn't trend lower due to competition.  The more I think about this, the more I start to believe it will require changes to clients to require certain minimum fees that are substantial enough to create the incentive needed to sustain a certain difficulty (whatever difficulty is judged sufficient enough to protect the network as a whole).  If the min fee structure was based on some model and adjusted every 2016 blocks (with the change in difficulty), that would be the best scenario.

Now, if there is a sufficient volume of transactions, miners will start to place their own cap on the number of transactions they'll put into a block (regardless of artificial limits), and that might rectify the problem, but that is dependent on sufficiently high volumes of transactions (and ever increasing volumes due to Moore's law).

[nanotube]

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)

[SgtSpike]

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)

I don't think that would be a good thing.  If the tx fee resulted in more bounty than it costs in electricity to mine, then you're essentially saying, "Keep buying mining hardware, because the transaction fee will keep increasing to match."  It could/would get to the point of no one wanting to make any more transactions with fees because the minimum fee was so high.  At that point, mining would collapse on itself.

The best way to deal with fees is already being used.  By forcing a scarce supply of transactions, it can force people who need their money transferred quickly to post a fee.

I think the biggest issue with it is that some transactions are waiting days or even a week before being completed.  That is too long, and a detriment to bitcoins as a payment system.  I think it is extremely important that NO transactions, free or not, are waiting to be completed for more than 24 hours.

[nanotube]

I don't think that would be a good thing.  If the tx fee resulted in more bounty than it costs in electricity to mine, then you're essentially saying, "Keep buying mining hardware, because the transaction fee will keep increasing to match."  It could/would get to the point of no one wanting to make any more transactions with fees because the minimum fee was so high.  At that point, mining would collapse on itself.

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

monotonic inverse-relationship function

The best way to deal with fees is already being used.  By forcing a scarce supply of transactions, it can force people who need their money transferred quickly to post a fee.

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.

[SgtSpike]

I don't think that would be a good thing.  If the tx fee resulted in more bounty than it costs in electricity to mine, then you're essentially saying, "Keep buying mining hardware, because the transaction fee will keep increasing to match."  It could/would get to the point of no one wanting to make any more transactions with fees because the minimum fee was so high.  At that point, mining would collapse on itself.

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

monotonic inverse-relationship function

The best way to deal with fees is already being used.  By forcing a scarce supply of transactions, it can force people who need their money transferred quickly to post a fee.

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.

Ok, but if tx fees are inverse to the difficulty level, then aren't you defining a limit to the number of miners that are economically viable to be present?  Wouldn't that be a bad thing, considering there are people out there who would love to compromise the network with more than 50% of the mining power?

[nanotube]

Ok, but if tx fees are inverse to the difficulty level, then aren't you defining a limit to the number of miners that are economically viable to be present?  Wouldn't that be a bad thing, considering there are people out there who would love to compromise the network with more than 50% of the mining power?

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'.

[Luke-Jr]

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

Awesome idea.

[Steve]

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

Awesome idea.

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.

[nanotube]

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

Awesome idea.

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.

'ideal difficulty' is 'as high as possible'

the basic idea is, the higher the difficulty, the higher the value of a bitcoin, therefore the lower the min fee has to be to discourage dust spam. that's all. we don't really need to know about 'ideal difficulty' and things like that. e.g., just say, starting from now, for every X% difficulty increase, minimum tx fee will go down by X% (or some such).

[Steve]

'ideal difficulty' is 'as high as possible'

the basic idea is, the higher the difficulty, the higher the value of a bitcoin, therefore the lower the min fee has to be to discourage dust spam. that's all. we don't really need to know about 'ideal difficulty' and things like that. e.g., just say, starting from now, for every X% difficulty increase, minimum tx fee will go down by X% (or some such).

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.

[markm]

How about computing how long it took on average for a block to be generated and if that average climbs so does the minimum transaction fee?

That way if miners wanted to manipulate the (default) minimum fee higher they could all slow down their mining, resulting in the clients sending higher fees to try to bribe the miners to mine faster.

But if the miners mine fast, the (default) minimum fee relaxes.

The target being 10 minutes per block average time to make a block.

(If it ends up taking a full two weeks on average to make one block, maybe quite a high fee could be called for to replace all the mining gear some worldwide disaster presumably must have destroyed or something? )

-MarkM-

[da2ce7]

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).

[carbonpenguin]

What's really needed is a website with a regularly updated chart that has estimates of, given current conditions, how long it will take for your transaction to go through with X transaction fee (perhaps even a simple browser-based calculator). That would allow people to rationally decide how long they're willing to wait for their transaction to go through and would allow for a proper tx fee market in which the players would be operating with adequate info.

[eof]

What's really needed is a website with a regularly updated chart that has estimates of, given current conditions, how long it will take for your transaction to go through with X transaction fee (perhaps even a simple browser-based calculator). That would allow people to rationally decide how long they're willing to wait for their transaction to go through and would allow for a proper tx fee market in which the players would be operating with adequate info.

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

[carbonpenguin]

Indeed, but it as it grows, there will be the need to figure out the approximate time it will take for no tx fee, a 1 satoshi tx fee (which I believe should be the default browser setting), or a .01btc tx fee. That way, people will be able to bid clearly based upon the balance between their need for a speedy transfer and their desire for a cheap transfer...

[xf2_org]

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)

[error]

How long does it take for a majority of the network to upgrade?

[xf2_org]

How long does it take for a majority of the network to upgrade?

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.