Do you want to pay the fee?

[DeathAndTaxes]

so how much should I pay for a fast transaction of 5 bitcoins? or even 2 bitcoins at a time because ill be splitting up all of them out of 28 bitcoins. What will my transaction fee be??

The fee is per kB.   0.1 mBTC per kB should be fine for inclusion in the next block.  Most tx that are waiting are <0.1mBTC, free, or have unconfirmed outputs.  The amount of the tx is irrelivent. 2 BTC or 200,000 BTC what matters is the physical size of the transaction.  Most tx are <= 1 kB.

[PenAndPaper]

What's your basis for this assertion? The miners act to safeguard transactions against double-spends, so shouldn't the cost of mining come from those making the transactions, and not from everyone?

Miners don't act to safeguard transactions or anything else whatsoever. They mine for profit and securing the network comes as an effect for that. You can't force people to behave in a way you only predict how they 'll behave. Give them profit and they 'll the the network for you.

[AnonyMint]

Thanks for this detailed information. I had't read that yet if it exists on the wiki.

It is my understanding that there is nothing in protocol that can enforce that calculation and thus that the calculation is merely the recommended behavior for mining?

Some comments...

This is a fully correct procedure for determing the fee owed in Bitcoin transaction.

If it is not enforced by the protocol, it can't be the "fully correct" procedure.

* priority is greater than 576. (note that developers use the number 57600000; it's 576 because I used millibitcoins rather than satoshis above)

This is discouraging a higher velocity of money V.

M x V = P x Q (a proxy for nominal GDP)

Thus this discourages the size of the GDP Bitcoin can adopt.

If your transaction is not "free" you had better add a transaction fee. To figure out the transaction fee you need to find the size of your transaction in bytes (see step 1 above), round it up to the next even multiple of a thousand, then multiply the result by 0.1 microbitcoins.

Thus the nominal tx fee is always increasing in dollars when BTC is. Yet the ATM debit card transaction fees are in some cases a fix amount, thus eventually Bitcoin becomes more expensive than the existing system.

so how much should I pay for a fast transaction of 5 bitcoins? or even 2 bitcoins at a time because ill be splitting up all of them out of 28 bitcoins. What will my transaction fee be??

The fee is per kB.   0.1 mBTC per kB should be fine for inclusion in the next block.  Most tx that are waiting are <0.1mBTC, free, or have unconfirmed outputs.  The amount of the tx is irrelivent. 2 BTC or 200,000 BTC what matters is the physical size of the transaction.  Most tx are <= 1 kB.

When the finite block size overflows then that can't remain true.

[AnonyMint]

I would like to point out that from a purely economic standpoint, transaction fees are a dead-weight loss to the economy.  ANY alternative revenue collection method would be economically superior for paying miners, be it a flat per year fee on every address, perpetual mining or a demurrage system as in Freicoin.  

Now I know their are arguments about message spamming but that's a technical argument and one that is ultimately going to need a radical technical solution because a Peer-2-Peer network that needs to send every transaction to every single user (with no incentive for doing so) is NOT going to scale to a worldwide basis.

And if transactions fees are significant, the system is subject to the Transactions Withholding Attack.

The issue of transaction spam is really not much different than DDoS prevention. You must rate limit and you need the mini-block chain design. Indeed I am beginning to see we should eliminate the transaction fee entirely.

[Barek]

And if transactions fees are significant, the system is subject to the Transactions Withholding Attack.

The issue of transaction spam is really not much different than DDoS prevention. You must rate limit and you need the mini-block chain design. Indeed I am beginning to see we should eliminate the transaction fee entirely.

The fee system as as fair as it gets. If you want the miners to perform a service for you (include the transaction in the block), you pay them to do so.

The fact that any miner can include any number of transactions guarantees competition and low fees for the users.

It's really not rocket science.

[AnonyMint]

And if transactions fees are significant, the system is subject to the Transactions Withholding Attack.

The issue of transaction spam is really not much different than DDoS prevention. You must rate limit and you need the mini-block chain design. Indeed I am beginning to see we should eliminate the transaction fee entirely.

The fee system as as fair as it gets. If you want the miners to perform a service for you (include the transaction in the block), you pay them to do so.

The fact that any miner can include any number of transactions guarantees competition and low fees for the users.

It's really not rocket science.

If they don't include feeless transactions in an altcoin where the tx fee is set to 0 by the protocol, then the altcoin dies and they don't get paid perpetual coin rewards any more (worthless bits). Thus the miners of such a designed altcoin have an incentive to include every transaction, if the block size is unlimited in the mini-block chain design as I have suggested.

As for spamming the resources, I covered that already. A lot also depends on the design of the network and how transactions are propagated and how large transactions can be in bytes. I just sketched a rough overview, but much thought would need to go into the specifics.

Yeah it really isn't rocket science

[Barek]

If they don't include feeless transactions in an altcoin where the tx fee is set to 0 by the protocol, then the altcoin dies and they don't get paid perpetual coin rewards any more (worthless bits). Thus the miners of such a designed altcoin have an incentive to include every transaction, if the block size is unlimited in the mini-block chain design as I have suggested.

So you are saying you would rather have a non-decreasing block reward and no transaction fees (miners need some incentive to mine)?

In other words, you would prefer every coin holder to pay for transactions, instead of the person who wants to make the transaction?

Can't have your lunch and eat it, too.

[AnonyMint]

If they don't include feeless transactions in an altcoin where the tx fee is set to 0 by the protocol, then the altcoin dies and they don't get paid perpetual coin rewards any more (worthless bits). Thus the miners of such a designed altcoin have an incentive to include every transaction, if the block size is unlimited in the mini-block chain design as I have suggested.

So you are saying you would rather have a non-decreasing block reward and no transaction fees (miners need some incentive to mine)?

In other words, you would prefer every coin holder to pay for transactions, instead of the person who wants to make the transaction?

Can't have your lunch and eat it, too.

Of course, that is the only way it can ever be a currency, otherwise it is just a ponzi-bubble and all will end up near 0 value. For background proof of that, click my name, then "Show posts" then start learning.

So we get our cake and eat it too. As it stands in Bitcoin, we don't get cake and we don't ever eat. Cash out early before it is too late.

[Barek]

So we get our cake and eat it too. As it stands in Bitcoin, we don't get cake and we don't ever eat. Cash out early before it is too late.

Ooooh, now your replies make sense. Guess it's time to click that highlighted link below your name.

[Barek]

Okay, what if you're not using the reference implementation? Is this a restriction on propagation, or mining, or both, or what? Are these hard limits, or are they just approximations? What specifically happens if you send a transaction without fees with an output smaller than 0.01 BTC? What if you send it to someone running a reference client? What if you send it directly to the miners? Same questions with regard to a transaction 10,000 bytes or bigger. What about the changes which are in GIT to eliminate the 0.01 BTC limit?

What about transactions which are non-standard for reasons other than fees? You can see them in the blockchain, so there must be some miners that accept them. Who accepts them? How do you get them to these miners? How much do these miners charge for them?

I could go on and on. If someone wants to get rid of that $8 fee, instead of complaining about it I'll go fix it. If someone has the power to manually put me in the "trusted" group without paying 0.01 BTC, my username on the wiki is the same as here.

Many of your questions cannot be answered. You might get more useful information if you describe what you want to do.

What $8 fee?

[Barek]

Which of my questions can't be answered? I think I could answer them all myself if I looked into the code.

You asked what would happen if someone didn't use the reference implementation. If someone does their own thing, only that person could tell you.

The wiki says relaying uses the same rules as block inclusion. So TX that do not meet the criteria are not relayed.

Miner behavior. Only the miners could tell you that. You might get answers if you post in the respective threads for the pools. Who knows, maybe they are thinking about offering services for including transactions you directly send to them. I could imagine there is going to be a market for that in the future.

https://en.bitcoin.it/wiki/BitcoinPayment

I wasn't aware. Have you tried "If you have questions or would like help with the process, drop by on #bitcoin-wiki on freenode IRC. Notice that the channel is not very active, so be prepared to stick around for a few hours before you get a response."

[Cryddit]

Cryddit you are still incorrect as the size of inputs and outputs can vary, bitcoin supports compressed keys and it is the default key type for most wallets now.

It is very important when providing corrections to get the data correct.  The data in the wiki is correct.  Not really sure I see the point to providing an alternate explanation which gets material facts wrong and requires three corrections and even then is only 95% correct.

When you provide exact values like 12 + 204 * (# inputs) + 32 * (# outputs) it creates a perception that this is the exact and only value.   Far better to say in aproximations.   Also the client is going to do the work on computing the required fee.  Not sure where you got the 12 from but it is incorrect (or not correct for all txs) and the 204 assumes the use of uncompressed keys which is uncommon at this time.

The objective here is that people should be able to PREDICT what a given transaction will owe in fees rather than having it lie latent and UNKNOWABLE in software until the time comes to pay them, and for people to have truth in order to NOT be misled by misinformation such as that which I myself was spreading earlier in this thread.  If people can predict fees in some kind of definite way, then they can understand, for example, when and why it is against their interests and unsupported by pools and merchants to take payments in "dust,"  when and why and how much bitcoin has a problem scaling to very small payments or vast numbers of transactions, when and why they cannot in fact make a 5.00000 bitcoin payment when they have exactly 5.00000 bitcoins in their wallet (which can save a hell of a lot of miscalculation,  embarrassment, and possibly expense if they have the misfortune to have already agreed to make this payment). 

Therefore it is completely unacceptable that a procedure should estimate too low, and highly undesirable for it to estimate too high; in fact it would be best if fees did not have to be estimated at all.  It is also unacceptable to not know fees until you come to the point of actually making a payment.  It must not lie latent and unknowable in software until that point.  And because it does not correlate with the amount sent, people do not otherwise understand it at all.  So please; DON'T just tell me something is wrong; tell me instead exactly how to correct it.

The wiki was ambiguous regarding the size of keys for inputs.  On the information provided (some of which it was necessary to read binary to find) they could either be 41 or 65 bytes long and I couldn't find *ANYTHING* in any human language that said which value was in actual use on the wiki.  I eventually used 65 bytes because I found a binary dump of a protocol exchange on the wiki that used 65 bytes.  If the 41-byte key form is in actual use, then transactions may be 24 bytes per input shorter.  Is there any way to tell which format the unspent tx in your wallet are?  If this is necessary in order to predict fees then people need to know it.

Another point of variance is the length of the scripts.  I did already say that if non-standard scripts (that is, anything at all except pay-to-script-hash) are in use the above is invalid.

The last point of variance is the length of the numbers that give the input and output counts; but that is fully accounted for in the instructions above.

[DeathAndTaxes]

The data in the wiki is correct.

It's quite incomplete, though. And it costs $8 to add to it.

What is incomplete?

https://en.bitcoin.it/wiki/Transaction_fees

"A transaction may be safely sent without fees if these conditions are met"

"Otherwise, the reference implementation will..."

Okay, what if you're not using the reference implementation? Is this a restriction on propagation, or mining, or both, or what? Are these hard limits, or are they just approximations? What specifically happens if you send a transaction without fees with an output smaller than 0.01 BTC? What if you send it to someone running a reference client? What if you send it directly to the miners? Same questions with regard to a transaction 10,000 bytes or bigger. What about the changes which are in GIT to eliminate the 0.01 BTC limit?

What about transactions which are non-standard for reasons other than fees? You can see them in the blockchain, so there must be some miners that accept them. Who accepts them? How do you get them to these miners? How much do these miners charge for them?

I could go on and on. If someone wants to get rid of that $8 fee, instead of complaining about it I'll go fix it. If someone has the power to manually put me in the "trusted" group without paying 0.01 BTC, my username on the wiki is the same as here.

Most of those can't be answered deterministically.  Remember Bitcoin isn't a single unified system, it is a network of independent peers.

Maybe this should be made more clearly but the reason how the reference implementation is important isn't just that YOU might be using it but the fact that 80%+ of the nodes on the network (both QT clients and clients which follow the same rules as the QT client) are using those rules.

It is pretty trivial to compile a client which includes no fee on 100% of tx of course those low priority tx once they reach a peer will simply be dropped.  Even if you are lucky and say one of eight of your peers are running custom code when they relay your no-fee low priority tx to their peers almost all of them will drop it.   If your tx doesn't get to a miner it will never be included in a block.

As for what miners require?  That can't ever be in a wiki.  It would be like asking what do all companies in the world charge for shipping for all products in all scenarios and keep it updated in a wiki.   I do agree we need more insight on what rules miners use for inclusion in a block.   Maybe a new thread asking for input from major pools and solo miners would be a good start.

What specifically happens if you send a transaction without fees with an output smaller than 0.01 BTC?

It is a very high probability it will simply be dropped (deleted) by all of your peers and nobody on the network will even know about it.

What if you send it to someone running a reference client?

It will be dropped.  Most non-reference clients use the reference client "rules" so they would drop it as well.  A few clients might relay it but even if it works once for you, it may not work for you again in the future (connect to different peers) and it almost certainly won't work for everyone.

What if you send it directly to the miners?

It depends on the miner.  Miners are free to implement their own parameters for including txs in a block however I don't know of any major miner which will include low-priority txs without a fee.  Most miners devote at least 27KB to high priority transactions (with and without fee) but I don't know of any which will do anything but simply drop them.

Same questions with regard to a transaction 10,000 bytes or bigger.

What about the changes which are in GIT to eliminate the 0.01 BTC limit?

It isn't deployed yet.  Once it is deployed the wiki will be updated.  That is why the wiki says "as of 0.8.2".

As for the fee to be an editor.  I have no idea who is in charge of that and while it is a useful anti-spam feature I think the cost should be reduced to 1 mBTC.  If you have a specific change post it and I will edit the page (I paid for editor access a long time ago when it probably was <$0.20).

[Cryddit]

It's quite incomplete, though. And it costs $8 to add to it.

What is incomplete?

Go back to page 3 and read how hard I had to work even to find the first full solution. 

FEES ARE IMPORTANT TO NORMAL USERS!  YOU HAVE TO TELL THEM HOW TO FIGURE OUT FEES!

And I still had to read obscure clues scattered over multiple pages of protocol specification including much that was not even provided in any human language in order to do it!  This procedure, or one more accurate than this, needs to be explained, in full, directly on the page that says "FEES" because when human beings go to that page it's because they want to know EXACTLY how much in fees a given transaction will cost!

If you're writing for human beings, don't write numbers in hex for godssake!  Hex might as well be Martian for all that most people can read it.  Don't make people read protocol specs when they want to predict fees because as far as human beings are concerned protocol specs have NOTHING TO DO WITH FEES!  Don't make people read binary protocol transcripts in binary when they want to disambiguate how long a damn key will be, because binary protocol transcripts are also Martian for all that most people can read them! 

Yours in moderate anger at the disregard paid to normal human beings on your wiki,

Cryddit.

[Cryddit]

so how much should I pay for a fast transaction of 5 bitcoins? or even 2 bitcoins at a time because ill be splitting up all of them out of 28 bitcoins. What will my transaction fee be??

See?!  This is the kind of question a normal human being asks!  And he has no freaking idea how many inputs, how many outputs, how to find the size of his transaction in kilobytes, et cetera.  The current fee structure has NOTHING TO DO with what human beings consider to be the ONLY things relevant to paying fees!  This is why your wiki is incomplete!  There is noplace he can go on the wiki that will give him anything like a straight answer he can understand!

Normal users are vulnerable to misinformation, manipulation, and being cheated because they cannot predict fees!

This is why you have to fix the damn wiki!

Cryddit

[Gabi]

A 10 cent fee is a high fee, soon going back to use credit cards will be more profitable

[Cryddit]

The objective here is that people should be able to PREDICT what a given transaction will owe in fees rather than having it lie latent and UNKNOWABLE in software until the time comes to pay them, and for people to have truth in order to NOT be misled by misinformation such as that which I myself was spreading earlier in this thread.

That's like saying that people should be able to predict how much an item in an eBay auction is going to sell for rather than having it lie latent and unknowable in software until the auction has ended.

No.  It isn't the same thing at all.  In an auction people understand WHY the price is unpredictable, and it has to do with other users and money, which are things they understand.  

There are no set prices in the protocol. All you can do is offer a certain fee and hope that a miner finds it acceptable within a reasonable amount of time.

Any fees set by the client are just guesses as to what fee is safe enough that it's going to give the person using the client a reasonable shot at having a transaction accepted in a reasonable amount of time.

And therefore people cannot do correct planning, are vulnerable to misinformation, can be ripped off without knowing they've been ripped off, can have a completely reasonable situation happen and still believe they've been ripped off, etc ad nauseam.  

If you don't think the fee structure is definite, try sending a transaction with one satoshi less than the lowerbound given on fees.  You have approximately half a chance if you send it directly to a miner or to the controller of a mining pool, but normal users don't know or care which nodes those are so that isn't fair.  Then try sending a transaction with one satoshi more than the upperbound given on fees and see what happens.  Think there's going to be a difference?  

Very strong conventions about fees are set by the reference implementation of the client.  If the fees fall a single satoshi short of what the clients "estimate" they will give absolutely no benefit for the fees actually paid.  Is that something other than a ripoff?!  Don't people deserve to know how the hell this mysterious but important thing is calculated by the thousands of clients out there that they are depending on to propagate their transactions?

[DeathAndTaxes]

Cryddit you are still incorrect as the size of inputs and outputs can vary, bitcoin supports compressed keys and it is the default key type for most wallets now.

It is very important when providing corrections to get the data correct.  The data in the wiki is correct.  Not really sure I see the point to providing an alternate explanation which gets material facts wrong and requires three corrections and even then is only 95% correct.

When you provide exact values like 12 + 204 * (# inputs) + 32 * (# outputs) it creates a perception that this is the exact and only value.   Far better to say in aproximations.   Also the client is going to do the work on computing the required fee.  Not sure where you got the 12 from but it is incorrect (or not correct for all txs) and the 204 assumes the use of uncompressed keys which is uncommon at this time.

The objective here is that people should be able to PREDICT what a given transaction will owe in fees rather than having it lie latent and UNKNOWABLE in software until the time comes to pay them, and for people to have truth in order to NOT be misled by misinformation such as that which I myself was spreading earlier in this thread.  If people can predict fees in some kind of definite way, then they can understand, for example, when and why it is against their interests and unsupported by pools and merchants to take payments in "dust,"  when and why and how much bitcoin has a problem scaling to very small payments or vast numbers of transactions, when and why they cannot in fact make a 5.00000 bitcoin payment when they have exactly 5.00000 bitcoins in their wallet (which can save a hell of a lot of miscalculation,  embarrassment, and possibly expense if they have the misfortune to have already agreed to make this payment).  

Therefore it is completely unacceptable that a procedure should estimate too low, and highly undesirable for it to estimate too high; in fact it would be best if fees did not have to be estimated at all.  It is also unacceptable to not know fees until you come to the point of actually making a payment.  It must not lie latent and unknowable in software until that point.  And because it does not correlate with the amount sent, people do not otherwise understand it at all.  So please; DON'T just tell me something is wrong; tell me instead exactly how to correct it.

Hopefully you find this helpful.  
https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png

I understand your intent although most people have no idea how many inputs they have so it isn't all that useful.  I do agree it would be useful if the client showed the balance and available to spend which accounted for any required fees thus people would know how much they can spend (possibly including optional fees).  My point is if you are going to provide numbers make sure they are right or phrase them as a question.  Bitcoin is very information dense and incorrect values just make it that much harder for new people to learn.  I would recommend blockexplorer.com as a resource for viewing raw tx to see what the inputs and outputs look like.  Be warned though for some reason blockexplorer (and bitcoind) drop some of the length values which makes it difficulty to compare to the map above.

You stated (paraphrased)
size in bytes = 12 + 204 * (# inputs) + 32 * (# outputs)

I believe that is incorrect for a number of reasons.

Disclaimer: this is only for standard "paytoPubKeyHash" (what most users consider normal) transactions which have <= 253 inputs and outputs and lack any complex scripting.

AFAIK this is the structure of transactions:

Header
-------------------------------
Version = 4 bytes
NumTxIn = 1 byte (technically a VarInt but it is 1 byte up to 253 <- note it is 253 not 255)
NumTxOut = 1 byte (also a Varint = same as above)
LockTime = 4 bytes
-------------------------------
Total = 10 bytes

Inputs
------------------------------
TxOutHash = 32 bytes
TxOutIndex = 4 bytes    <- not sure why developers didn't make this a varint would save 3 bytes on most transactions
ScriptLen = 1 byte (technically varint but will be <253 bytes for "standard" inputs)
Script = 106 bytes (138 bytes for uncompressed keys)
Sequence = 4 bytes
-------------
Total = 147 bytes (179 for uncompressed keys)

The input script depends on the requirements set in the output but for standard PayToPubKeyHash outputs it consists of:
Padding & Length values = 10 bytes
Sig r = 32 bytes (random nonce)
Sig s = 32 bytes (signature)
Key x = 32 bytes
Key y = 32 bytes (committed for compressed keys)
----------------------
Total 106 bytes (138 bytes for uncompressed keys)

Output
------------------------------
Value = 8 bytes
ScriptLen = 1 byte
OutputScript = 25 bytes (for standard "pay to pubkeyhash").


Breakdown of output script (standard "pay to pubkeyhash")
---------------------------------------------------------
OP_DUP =  1 byte
OP_HASH160 =  1 byte
0x14 =  1 byte
PubKeyHash = 20 bytes (RIPEMD-160 = 160 bits = 20 bytes)
OP_EQUALVERIFY = 1 byte
OP_CHECKSIG = 1 byte
----------------------------------------------
Total = 33 bytes

So for most cases the size of a tx is:

TxSize (bytes) = 10 + (NumInputs * 147) + (NumOutputs * 33)
 

The wiki was ambiguous regarding the size of keys for inputs.  On the information provided (some of which it was necessary to read binary to find) they could either be 41 or 65 bytes long and I couldn't find *ANYTHING* in any human language that said which value was in actual use on the wiki.  I eventually used 65 bytes because I found a binary dump of a protocol exchange on the wiki that used 65 bytes.  If the 41-byte key form is in actual use, then transactions may be 24 bytes per input shorter.  

It is important to understand that various core data elements (pubkeys, addresses, private keys, etc) have a variety of forms.   The WIF private key form is base58 and indcludes a checksum (to avoid errors when manually copying).   At the transaction level everything is "raw" in binary without any encoding.  For example pubkeys are stored as x & y values thus they will be 32 or 64 bytes (compressed pubkeys ommit the y value since it can be computed).  Although at the user level we may send to an address, since addresses can be converted to pubkeys (and pubkeys to addresses) at the tx level the standard tx is "Pay To PubKeyHash" not "Pay To Address" so the PubKey is used in the output script and that is always exactly 20 bytes.

Is there any way to tell which format the unspent tx in your wallet are?  If this is necessary in order to predict fees then people need to know it.

Yes.  In WIF (Wallet Import Format) the private keys for compressed pubkeys begin with 5.  This is not a requirement of ECDSA as private keys are simply 256 bit numbers it is a Bitcoin standard to allow one to "know" if the resulting pubkey should be in compressed or uncompressed format.  The resulting address will be different.  Since the address is a hash you can't tell from the address alone.  You need either the private key or the pubkey.  Sadly there is absolutely no reason for uncompressed keys.  They just take up more space and make everything more confusing (two pubkey standards).  It would seem Satoshi was unaware of some cryptograpihc "best practices".

If someone wanted to make an improved altcoin (as opposed to pump and dump nonsense) there are a lot of low level improvements which could be done that would simplify the codebase and make it easier to understand for new developers.   

Off the top of my head:
Enforce use of compressed keys only.
Implement PubKey recovery to avoid needing to put pubkey in the tx input (would save 33 bytes per input per tx)
Make fees explicitly part of tx rather than implicit (avoids coins lost to miners in errors)
Use a canonical form of signing and make any non canonical form an invalid transaction (would seal up a lot of subtle security issues)

[DeathAndTaxes]

FEES ARE IMPORTANT TO NORMAL USERS!  YOU HAVE TO TELL THEM HOW TO FIGURE OUT FEES!

I don't think it's feasible to tell "normal users" how to figure out fees. The best we can hope for is to tell the people writing the clients how to figure out fees, and for the clients to then automatically suggest the proper fee to the user. An advanced client could have knobs for "increase fees in order to send this transaction faster" and "minimize fees - I don't care if this transaction takes days to complete". The advanced client can have a way to replace a stalled transaction with too low a fee by increasing the fee. The normal user can then just trust that, and/or shop around for the best client.

This.  Users aren't going to lookup the number of inputs to determine tx size, calculate priority, and determine the fee by hand.  The goal should be making the client perform all this in a transparent manner.  Someone did some mockups of an improved tx confirmaiton screen.  That should be the goal.

It is also important to note that while TODAY there is no reason to pay more than the min fee the min fee wasn't designed to be a revenue generator.  It is a DOS prevention mechanism which raises the cost for a variety of attacks against the network.     It is very likely that the fees to timely inclusion in a block will be diverge from the min fee for relaying and so computing the DOS prevention fee is not sufficient to get the "whole story".  We are already starting to see this.  For the purposes of relaying a high priority tx does not need to include ANY fee.  However you still need a miner to include it in a block and since miners limit the amount of free txs in many cases it makes sense for a high priority tx to pay a fee even though it isn't required.  I have set my bitcoind to pay the min fee on all txs and have not seen a delayed tx in the last couple months.

The complex part is getting all this information to a user in a simple interface.  It can be done but it is more complex then just calculating the min fee.  A future "smart" client would look at the average size of recent block history, the break down of fees for tx in those blocks, the number of tx in the memory pool, the priority of those tx and the distribution of fees paid on those txs.  For tx which are unlikely to confirm immediately a very smart client would anticipate future tx volume (based on historical norms) and increase the confirmation time accordingly (some of those tx being created AFTER the user will be higher priority and/or have higher fee).  The goal would be to perform all that analysis in realtime and simplify it to the user with something like this:

Recommended fee: 0.02 mBTC.

With no fee estimated time to confirmation is 12 to 36 hours with 95% confidence.
With fee of 0.02 mBTC estimated time to confirmation is 1 to 2 hours with 95% confidence.
With fee of 0.10 mBTC estimated time for to confirmation is 20 to 60 minutes with 95% confidence.
With fee of 0.15 mBTC estimated time for a confirmation is next block with 95% confidence.

Alternative no fee option using highest priority coins (will result in 140 Bitcoin Days Destroyed) has a resulted

[Send no fee] [Send with 0.02 mBTC fee] [Send with 0.10 mBTC fee] [Send with 0.15 mBTC fee] [Send alternative no fee]

Of course we are nowhere near that but the goal would be to abstract all this from the user and allow them to make a choice as simple as choosing a delivery option when buying a product online (pay more = faster, pay less = slower).

Two very important improvements to the fee system are safe transaction replacement and a concept called "child pays parent".  With the later some merchants (especially those which don't need immediate payment) may simply tell users to send without a fee and the merchant bundles all the unconfirmed tx includes a single large fee and gets priority access into a block.

[AnonyMint]

So we get our cake and eat it too. As it stands in Bitcoin, we don't get cake and we don't ever eat. Cash out early before it is too late.

Ooooh, now your replies make sense. Guess it's time to click that highlighted link below your name.

Good riddance Bitard.