Bitcoin Forum

Consensus on IRC seems to be building around a change to the minimum TX fee, reducing from 0.01 to 0.0005 BTC.

See https://en.bitcoin.it/wiki/Transaction_fees for a refresher course on TX fees.

The minimum free TX value would remain at 0.01 BTC.

+.0005

4 US cents is ridiculous.

i can buy that.

I'm in favor, just keep in mind that the txes with such low fees/outputs will probably not confirm for quite a while (limited space per block for "very low priority" transactions).

I thought 'priority' only ranked free tx. I could be wrong.

Priority ranks all txes until they get accepted, however currently only "very low priority txes" have issues as blocks have plenty of space but there is a limited space reserved for "very low priority txes".

This "consensus" talk gives a bad feeling. Prices should be set by markets.

This consensus is among avid bitcoin fans. If even these guys thing the TX fees are too high, then the general bitcoin-wary public will probably agree even more vehemently.

These people are the market. And if they think the TX fees are too high then they will just not use bitcoin. I don't think that's the kind of free-market adjustment that would do the bitcoin economy any favors.

Agreed; that is the longer-term goal.  This is a short-term fix.

Why not have no minimum?  I realize that this will lead to many people spamming the lowest # of bitcoins possible to have a paid transaction, but the market should reset transaction fees to the optimal price.  Am I right?

This is just the default ruleset.

Miners are free to choose their own rules.  I believe luke-jr's pool requires all TX's to have a fee, if an extremely minimal one.

I disagree with his policy, but it illustrates the free market already at work.

If the Mining Majority wants a different ruleset, then the default ruleset won't be worth the paper it isn't printed on  :)

Gotcha - I didn't realize that miners/pools could pick what tx fee they wanted.

So whether free transactions go through is dependent on which miner/pool finds the "winning" block, and whether it allows free transactions or not?

Yes, the pool that finds the block uses their own rules to determine what txs get put in.

This is essentially just choosing the minimum fee in the default btc client.

I would recommend making it completely optional, but explain the length of time it is likely to take before your tx would go through to the user and make them click send anyway or something like that.

has the minimum possible tx fee been reduced?

I see a tx fee of 0.0017028 included in this recent block
http://blockexplorer.com/b/122954 (http://blockexplorer.com/b/122954)

I thought the min. fee was 0.01or was there always a way to do lower fees somehow if you wanted (i.e not zero but <0.01)?

It also sets the relay limit, so if this is set to 0.0005, txes with fee<0.0005 won't be relayed and probably won't end up in a block period (unless they use -addnode to get hooked up to luke-jr's pool).

With 0.0005 BTC fee per 1KB, a 1MB block is going to bring just 0.5 BTC. What about the idea that the fees were going to replace the generation bonus when it will be smaller?

Another problem with the fees is that they govern not only inclusion in the block by also relaying of the transactions. The miners are free to set the fee rules but most of the cost of processing the transactions is borne by relay nodes that get nothing.

Transactions with a fee below the minimum fee set by the relay node are treated in the same way as free transactions so they will be relayed if they meet the free transaction criteria.

And, last I heard, ArtForz's mining cluster is set to accept all free transactions regardless of the standard blocksize limit for free transactions, so it all evens out in the end.

My opinion is that the rule should be changed to drop the minimum fee in the default client and set back the minimum free transaction as well.  The massive growth we have seen recently has moved these limits from really tiny amounts to non-trivial limits, and the growth isn't likely over.

If the fee is realistic, the transaction value shouldn't matter (because it doesn't affect the processing costs).

Why not 0.001 BTC regardless of transaction value?

This fee has the advantage that it is one millibitcoin, and so can introduce users to this term. "Five hundred microbitcoins" is a little less simple.

Yes, but one of the largest motivations behind this was the option to relay transactions which are over the size limit and do not pay a fee and would normally not be relayed.  Remember that this really won't change what ends up in a block much as the very low priority transactions already don't get confirmed until they age.

Please, just abolish this minimum fee. (If you remove this standard fee policy altogether it would be great too ;))

Oh god no, in-discriminant transaction relaying means DDoSing becomes way too easy.

Agreed. .0005 sounds about right, maybe a little low. But if it appreciates more then should be just right.

There should be better ways to identify a spam attempt and deny relaying them. But I see the point, it's much quicker to just reduce the limit.

That got me thinking. If we can come up with a list of likely attributes of spam transactions, perhaps the client could identify the likelyhood of a transaction being spam. Then, if that likelyhood (expressed as a number between 0 and 254) is greater than a random number between 0 and 254, the transaction is thrown out as spam.

but what if it isn't spam?

If in doubt, client could display a capcha  ;D

Since it's not deterministic, it's likely that unless it's almost certainly spam, some nodes would relay the transaction. They could take into account transaction fees, the size of the transaction, the number of recently seen transactions, etc.

0.0005 sounds about right to me. At any rate 0.01 is now too high and it should be at most 0.001. (Of course in the long run fees should be a matter of individual policy, but there's nothing wrong with defaults.)

I'm not sure what conclusion you can really draw from luke-jr only accepting transactions with fees.  When there are no longer any generation rewards for a block, miners would all clearly benefit if they all only allow transactions with a certain minimum fee, however for any individual miner, they would have an incentive to accept any transaction so long as there is some fee...no matter how small that fee is.  This will drive transaction fees down to the point where miners start shutting down and the network becomes more vulnerable to a powerful miner.  Despite there being a strong collective reason for miners to charge some minimum fee and despite the clear benefit to all users to pay a fee to ensure a sufficiently robust network of miners, I think there is a real risk that miners will want to scoop up all transactions paying anything and for users to pay the bare minimum fee (a satoshi I guess).  This is the tragedy of commons argument people make.

This is also how I think the spam problem should be solved for relaying. A drop probability should be weighted by fees and priority. If the transaction is important, it will be resent.

Why does this keep coming up?

No, not all miners have the same incentives, and not all will be motivated solely by direct profit (i.e. mining fees).  Some will have an indirect motive to mine, making transaction fees a secondary revenue stream.  You can search for my "Wal-Mart" posts related to this subject.

Because it's actually a problem.

You think that miners with not for profit motives are going to be able to maintain a robust, attack resistant network. Others disagree.

I can see this working if people voluntarily pay tx fees. If there are millions of users then they each wouldn't need to pay much to incentivise a strong network of block generators, and indeed, a culture of this sort may emerge. But is is a tragedy of the commons like situation.

In another post, you highlighted the fact that there is a transaction acceptance policy encoded in the main client which prioritieses transactions with fees, forcing fees out of merchants needing speedy confirmations, but there is no reason to believe that the mining pools of the future will maintain such a policy when there are fee paying transactions going un-harvested. Luke-Jr, to me, exemplifies the natural dynamic of transaction acceptance policy: accept txs with fees, don't accept txs without fees.

I know you understand this dynamic, however, you haven't made a compelling case as to why bitcoin will work anyway. In any case, I hope you're right. Although, I wish intelligent people on this forum would acknowledge this problem instead of stifling debate.

Others are wrong.   :P
No, this is where this error keeps coming up.  It's a commons, but not a 'tragedy of the commons'.  The collective security of the blockchain is the commons, but the incentives for senders to add a fee are different from the commons resource incentive.  The fees are competing for a time limited resource, inclusion in the next available block; while miners are competing for those fees.  Those are not commons.

I have made such a case, it's the 'Wal-Mart' post.

That's the user common. There is also a miner common.


The space in a block will/should be unlimited and the cost of inclusion negligible.


And nobody claims they are. Which brings us to the miner common: the willingness of users to pay substantial fees.

Seems like a bit of a stretch to claim that a state of mind is a public good.

Why? It translates to the payment of actual fees. If miners self-interestedly accept all profitable transactions that willingness will fall through the floor and with it the actual fees. That's normal competition and how all market prices work.

But call it "the transaction fee level" if you like. Same thing. Cartels are hard to create and maintain.

Negative. The last thing we need is blockchain spam.

If fees fall, mining will become less profitable, some miners will stop mining, difficulty will decrease, and mining will become more profitable. So?

Difficulty will decrease a lot, leaving Bitcoin without protection from attacks. (Unless users voluntarily donate fees way above market equilibrium, which they well might (http://bitcointalk.org/index.php?topic=6576.msg96789#msg96789).)

One of the the major selling points of Bitcoin is low transaction fees.  I few days ago I decided not to tip someone .1 btc because it required a .01 fee.  The minimum fee needs to be much lower,  .0005 sounds about right.

[citation needed]

This seems to assume that most of the network's power will come from dedicated miners who are operating just above profitability. I don't see any reason to believe that this will be the case.

So the network's power will come from miners operating at a loss and this whole transaction fee thing - intended to incentivise block generation with profits - is unnecessary?

Oh come on, you don't believe in everyone volunteering their time and resources for the common good?  Isn't that what socialism is so good at?   ::)

If miners are accepting all transactions with fees, then fees are not competing for a time limited resource; They'll all get included in the next block. Why would a miner leave a fee paying transaction for the next block?

+1.
Bitcoin should not rely on that.

I don't see how the block size could ever be unlimited, I would think this is what actually costs money, big blocks? Transaction fees will naturally strive to optimize the block-size as a side-effect.

Millions of spam transactions today is no different from millions of legit transactions tomorrow. If the blockchain cannot handle spam today, how could it handle large transaction flows?

Because sometimes they will have to.  There is a set of rules that limit how large the block can be based upon the largest single fee.  Currently this "fee schedule" is so harsh that hitting the 'hard' blocksize limit of (currently) one megabyte is functionally impossible.  Off the top of my head, a block more than a third of megabyte would almost certainly have more bitcoin in fees than the block reward.  If the minimum fee, the max block size, or the fee schedule were to change in the near future (which I think is likely) then that is also likely to change.

Pull request created:

     https://github.com/bitcoin/bitcoin/pull/218

I get the fact that the transaction limit will eventually create competition for space in a block and that might help.  But the 2000 limit seems to place an arbitrary limit on transaction scalability.  One issue here is that the cost of mining (securely recording transactions) is associated with the block rather than the individual transactions.  This creates a free rider problem (or at the very least, a very heavily subsidized rider problem).  What if the hashing was done for each transaction in a block and the network enforced a minimum total block difficulty and a minimum transaction difficulty.  The total block difficulty wold be calculated based on the combined difficulty of the transaction hashes.  The minimum block difficulty ensures blocks still only get created once every 10 minutes.  The minimum transaction difficultly would be some ratio to the block difficulty (if it were 1/2000, it would mean that there is no incremental transaction cost until you exceed 2000 transactions...at 1/100 it would 101st transaction that would start to add incremental cost. 

Miners would rank the transactions based on the fee and always include the highest paying among them.  For the 101st (assuming a 1/100 difficulty ratio), the miner would have to weigh the additional hashing cost (which effectively slows down the miner or pool's generation rate) against the fee associated with the additional transaction.  At some level of fee, it would consider the cost to exceed the fee and not include the transaction.  Lower fee transactions would tend to get processed by the network during off peak hours.

There could also be an allowance for really old transactions to be included without meeting the minimum hashing requirement...and maybe a few other special rules to prevent spammy looking transactions.

Note, I'm still not sure whether this creates a situation where difficulty wouldn't start falling to dangerous levels...this would just deal with the free rider problem.  In the absence of a concern over the integrity of the network and without generation fees, the optimal difficulty level with the lowest costs per transaction would be 1.  Mining would trend toward the most efficient miners or the subsidized miners and drive out the miners with higher costs.  And eventually the power would be devoted to good connectivity and the power needed to handle the transaction volume rather than hashing.  Until of course people realize just how vulnerable the network is due to an attack.

Somehow, I think there should be a model of how vulnerable the network is at any given moment and for the network to factor that into difficulty adjustments and perhaps minimum transaction fees (where nodes don't propagate unless those mins are satisfied).  But I'm not sure how you'd do that algorithmically without someone actively trying to attack the network (where the network could somehow detect attacks and adjust transaction fee requirements higher to create the incentive to bring more mining power to bear).

Maybe, the problem of optimizing mining activity for integrity can't be solved algorithmically...perhaps insurance is the key.  Insurers could sell bitcoin systemic failure insurance to people for some premium (settled in, I dunno, gold or some other currency).  A portion of this premium would finance mining operations by injecting very high fee transactions into the network (with the objective of making mining profitable enough to sustain a certain difficulty level they deem sufficient to mitigate the risk of a powerful miner attack).  Businesses operating secure wallet operations might offer such insurance with their service.  Dunno...just some random thoughts.

Pulled into upstream.

I did a test transaction using the new rule: see http://blockexplorer.com/tx/f5c5b178fe876c291eb691616c58022166d8505fe6ebf6fca2b94cd5b748fa6a (http://blockexplorer.com/tx/f5c5b178fe876c291eb691616c58022166d8505fe6ebf6fca2b94cd5b748fa6a).

These are artificial limitations on the miners. As you say, the fee schedule will change in the near future: Miners will accept a transaction if the fee covers the cost of electricity to process it and reject it if it doesn't. Do you disagree with this?

Give the above supposition, there is no time limited resource! fees will converge to zero. (actually the cost in electricity to process, which itself converges to zero with hardware improvements)

Your argument rests on the assumption that miners will maintain a set of artificial limitations on fee acceptance policy for which they have no obligation or incentive to abide.

Adding the additional transaction does not slow the hashing since only the 80 byte header is hashed.
I would think any fee at all would make it worth including in the block.

I don't disagree, but I suspect that there are more factors than the obvious ones.

I was recently doing the business plan for a double-spend insurance firm. The firm would charge merchants who need protection from double spends and can't wait for lots of blocks a fee and in exchange would guarantee transactions. It's rates would be tiered based on delay, so there would be a fee for 2-sec guarantee, 5-sec guarantee, 10-sec guarantee, etc.

The costs for such a firm would depend heavily on the number of double spends, so it would seek to minimize them. The more double spends happen, the more money it would be willing to spend on double-spend defense. One of the measures it would do is to pay miners for guaranteed inclusion in their blocks. If double spends happen more, it would pay more miners more money, if double spends happen less, it would pay less miners less money.

Note that such a company would also watch very closely for network takeovers, as it would have to carry potentially significant costs if somebody takes over the network and starts double spending or rejecting transactions.

I think this is the missing feedback loop that connects mining income with network security.

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?

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.

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.

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.

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

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.

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.

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

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

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.

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-

Have no rules and let the miners decide.  ;D


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

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.

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

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)

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.

I'm thinking more of the network has already upgraded than you think. I did a few transactions that required fees today using the 0.0005 fee and they went through right away.

Most likely they were simply considered free transactions.

Ah, I suppose with the amount of blocks found today there was more than enough room.

I'll try a transaction under .01 BTC and see how long that takes. (if it even does take...)

just to clarify, i believe the minimum transaction size is still 0.01 btc

are you referring to this instead?
 - doing a transaction that will likely be considered "low priority" (e.g., 0.01 btc)
 - have -paytxfee specifically set to an amount below the 0.01 btc threshold but at or above the new lower bound (0.0005 btc or higher)?

My first test last night was successful. Broadcast through 38 nodes, a .0005 transaction was successfully blocked after 42 blocks.
http://blockexplorer.com/address/1ELvLsDRCaN8zSpZ8ZktAeM56tpfZ3E4kG

Honestly, if this is the worst case for a well-connected node when there are only, what, 100ish nodes on the RC, I think it could be pushed right out.

Isn't it possible to introduce some automatic downloading & adjustment of current fees depending on BTC prices comparing to other currencies from bitcoinwatch, bitcoincharts or something ?
Of course, if none of the servers respond quickly, then the default fee will be taken.

I know this is not the best solution, but surely it has to be better than fixed fee.

Couldn't you almost instantly have a "non-trivial" amount of the network converted by just getting [Tycho] and Slush (and maybe a couple other 500GH/s + pools) to have committed to being updated? And perhaps check with Vladimir or a couple of the other big solo players?

With how centralized people have chosen to have mining be, I think it should make this sort of update quite simple.

Also, on a side note, I would personally like to see the ability to include smaller transactions in general included in a release very soon (at least 3 decimal places, preferably 4 especially if that is the transaction fee limit.  I think one should be able to see and work with those fractions of coins in other ways as well if they can be used for fees.)

That's my .0005 BTC.

No, because you're probably not directly connected to those pools, and the nodes you are connected to will drop transactions if they don't include the 'right' fee.

Bitcoin already supports showing and sending less-than-0.01 BTC amounts.  It is just smart and only shows 2 decimal places instead of always showing lots of extra zeroes.

By the time the next-next version is officially released, we're probably going to want a minimum transaction fee of 0.00001. A rolling fee update like this would be okay if we were getting a new release every two weeks, but at this rate it's just way too slow.

Minimum relay TX fee changed from 0.0005 to 0.0001, in git.

That's still about three cents. Why not 0.00001? 0.01 was fine when we were at 0.3, why is 0.00001 too low when we're at 30?

We should make the min fee 0.00001  ;D

We just should not stop any transaction fee, if it comes in places ahead of last zero. That will start transaction market.

It's about a third of a cent...

D'oh you're right. Sorry.

Maybe i am missing something important. Did anybody was looking in problem of mass zero fee tx on modified client ?
I am understand that, this kind of tx will be refused by nodes, but how that will affect them ?

As transaction fees are reduced and minimum transaction sizes also decrease, the client should be adapted to display varying decimal places.  To early adopters with several thousand Bitcoins, a few bitmills may seem trivial, but those who come along down the road may be very interested in them at least starting out.  It seems as though there could be options in the client to display anywhere from full Bitcoins down to the singular Satoshi unless I am missing something obvious.