Topic: [RFC] New TX fee: 0.0005 BTC - page 2. (Read 16338 times)

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

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

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.

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

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-

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.

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

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.

Awesome idea.

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

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?

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:


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.

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.

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

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.

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.

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.

Small note here. Relating hashing power and transaction costs in BTC, i.e., MHash per BTC and MBytes per BTC might be introducing unnecessary confusion.

These costs, hash power and transactions, are actually more closely fixed in other currency units (for now) and with rapidly changing valuations e.g., BTC/U$, fixing those computational costs in BTC is always going to create moving targets for the 'relevant' size of fees.

Yeah, that sounds a bit like the plan I was proposing for people to submit their transactions directly to a miner without broadcast. The attached fee would pay for a certain amount of hashing, eg 0.01 BTC per 100 gigahash of work done. The more hashing you pay for, the faster your transaction gets buried in the chain.

One problem with my proposal is that "gigahash of work done" is a very technical unit that is difficult for people to understand in terms of business risk. Insurance measured by the second is a much more elegant approach because the insurance company can do all the work of finding out how hard it is to rent black-market reversal rigs, how likely that is to occur for any given client, etc. The merchant just has to find an acceptable premium from a free market of insurers.

In other words, I think you nailed it. IMHO this is worth a separate thread, how about we split it out and discuss it further there?