Bitcoin Forum

'This transaction is over the size limit. Blah blah blah, um bum blady blah. The fee is about a dollar. Would you like to pay us a dollar to make this transaction?'

Here are the well thought out choices.

'Yes' and 'Cancel'.


Seems to me there's an option missing right there.

Uninstall?

If you don't pay the minimum fee when required, it's a non-standard transaction that won't be relayed to other bitcoin nodes or included in a block.

That's great! So if I want to buy a sandwich at subway for a dollar I can do so for the low low fee of....a dollar.

transacting bitcoins is not a desirable act by the protocol and thus is punished

0.0001/kB BTC fee * $1000/BTC = $0.10. You can avoid fees that are multipliers of the minimum by not filling your wallet with only trivial dust payments that are more expensive to spend than to discard.

The option is missing because if it was there a lot of people whould be crying out because their transactions are never confirmed.

Try paying the sandwich with a ton of 1c coins and see how amusing they find that.

Yes we could add "Send with no fee and probably won't get confirmed because miners aren't a charity." button if you like?

Well, you could send the outputs individually without fee. It will just take some time.

It's not that high right now, I think like 7 cents, but still I agree it would be great if we could get it lowered somehow.

This. I only use fees when I need a payment to get through ASAP - i.e., almost never.  That said, I don't deal in dust either.

If the outputs can be of high priority individually and have no problems to confirm without a fee then you don't have to send them individually anyway.
Also one high priority output can label a transaction as high priority even if it includes some low priority ones.

of course i want to pay that. you dont understand the system  :D

You have to do some trick but I would recommend you not to, it will take really long to send the coins...

Paying the fees will make your transaction be confirmed faster. Of course you can choose not to pay a fee, but it's odd how your client is forcing you to do so.

i think Armory can remove the fee but most miners will rightfully refuse to proses your transaction.

You are wrong about the 1$ fee, it is not even close on that!

At MTgox current price the transaction fee is $0.081265

I think people should be happy to support the network and the miners.
Maybe the fee will come down in time, as more transactions are made and BTC value increases.

Fees are supposed to be the incentive to keep miners at work even after the last block has been mined, so they should actually grow.
No fee = no bitcoin.

Yes, but they shouldn't grow so much per transaction, they should grow per block (-> more transaction in a mined block).
We want Bitcoin to be an effective payment system, so fees should be low.

I have a small project I'm working on where people will send .0005 or so btc to an address and they don't care about confirmations, it can take a week really doesn't mater, is there a way for them to send that amount without fees using the QT client?

This.  This is why loitering around "free bitcoin dust" sites is a waste of time and a bad idea.  I remember when I finally had enough 'dust' to do something with, the transaction fee was brutal. But I paid it, because, lesson learned.

Running a p2pool node at a low hash rate (currently below 10 GH/s) also causes this problem. I have about $2000 worth of BTC dust crumbs sitting in a p2pool mining account and the client is asking for about $400 in fees to transfer them out. I think I know how to reduce this by transferring larger chunks into the address and letting them sit for a few months and become candidates for higher priority transactions.

when all 21m coins have been mined, transaction fees will supposedly be valuable enough to continue the act of mining and adding compute power to the network. transaction fees are desirable.

(EDIT; I WAS WRONG WHEN I POSTED THIS AND OVERSTATED FEES BY MORE THAN A FACTOR OF TEN.  I AM DEEPLY SORRY FOR THE TROUBLE THEREBY CAUSED TO EVERYONE. -- CRYDDIT)


FWIW, fee being about a dollar means about 12 "coins" are being used.

If you're only trying to spend a dollar, this means you must be paying in dimes and nickels.  

So you're looking at your wallet and it says you have X available;  but because it's in nickels and dimes you'll burn half of that in tx fees when you try to spend it. So you probably only have about 1/2 X that can actually be used.  The rest will be blown on fees.  Aaaand, that kinda sucks.

If you were paying with a ten-dollar bill, your tx fees would be about 7 cents.

The thing that most don't get is that this doesn't depend on how much money you're trying to transfer, as it does in a sane world; it depends on how many individual coins you use.  So spending a ten dollar bill *and* a penny will cost twice the "sales tax" of spending just the ten dollar bill.  

I'll have to look at the code, but it may be even worse than that.  If this size coin is also the only thing you have that you can use to pay your tx fees, you'll be making your transaction twice as large when you add coins to cover tx fees; so the client may be wrong here and your $1 transfer will actually be a nonstandard tx until you sink $2 into fees.

I think that bafflement on this point is one of the problems with the interface.  The wallet should show the actual *spendable* amount (the amount that will be left after paying the tx fees to spend it) rather than some imaginary amount you won't be able to actually use.  It would banish a few illusions about how much you're actually being paid by sites that pay out in these tiny tiny coins.

Translate all amounts above into Bitcoin of course.  Instead of "dollar" I mean "about .001 Bitcoin" and instead of "nickels and dimes" I mean "txouts worth .00008 Bitcoin or thereabouts."  "pennies" or increments of .000001 bitcoin truly *are* dust; they cannot normally be spent without incurring more in transaction fees than they are worth in money.

EDIT;  I WAS WRONG WHEN I POSTED THIS AND OVERSTATED FEES BY APPROXIMATELY A FACTOR OF TEN.  SEE PAGE 4 OF THIS TOPIC FOR A DETAILED CORRECTION.  --CRYDDIT.


Actually I think they'll be considerably higher than that considering what I anticipate the value of Bitcoin to be at that time. Mining fees will need to be reduced considerably for Bitcoin processing to remain "cheaper than alternatives" when Bitcoin goes north of US$10K, or the per-coin transaction fee will be 80 cents.  Even for smallish purchases there are usually at least 3-4 txid's involved, so is a "usual" transaction fee of $2.40 or $3.20 per transaction entirely reasonable for processing each and every one of your daily purchases?  Bearing in mind that today credit card companies are doing it for a nickel or so plus 1% of the transaction amount?

So save that dust; if they do reduce transaction fees in the future, it may become spendable again.

Is the minimum bitcoin fee arbitrarily set in the system? Is there even scope to lower it substantially in the future?

Currently yes. There is a plan to create an other fee system that will choose an appropiate fee within the next bitcoin-qt update.

Fees are for the health of the bitcoin network, and serve to ensure that transactions cost enough that transactions are not used for flooding the network with activity by attackers, and are actually used for non-trivial money transfers. Enforced minimum fees have been reduced before when the real-world value increased beyond simply "transaction disk space should cost something".

It is set arbitrarily by consensus in the software that all Bitcoin users use - every node has a no-relay policy for non-minimum fee transaction, effectively blocking communication of transactions without it. The 0.0001 BTC minimum for relay has been in place for 2.5 years, even when mining required more. Fees are required only for certain transactions, such as if any amount spent is less than 0.01 or if the coins being sent are recent to the wallet.

Pools can include whatever transactions in blocks they want, but minimum fee blocking rules have only been knowingly altered by one pool. With the network as busy at it is now, it is best to set the optional fee above the minimum anyway if you want your money reliably sent quickly.

You cannot simultaneously complain about:

* Why do we pay fees?, it should be free for me,
* Why doesn't my transaction confirm? and,
* Why does the blockchain of all transactions take so long to download.

Well, you can acknowledge that these are pain points that anyone considering a new design should try to minimize.  But for Bitcoin as it exists the relationship between these are a thing that cannot be changed without radically changing the design.

If you want to create an altcoin that actually contributes something to human knowledge and capability, provides new capabilities that might be taken up into Bitcoin, and isn't just  some derivative farting around, pump-and-dump crap, find a good design solution to those three (or even any two of those three) problems and test it thoroughly in an alt-chain.

We should be striving to fix the design problems in Bitcoin, if we truly want it to dominate.

No fee no bitcoin, no fee no bitcoin
I remember when we use to pay...

Who's going to want to pay an extra $0.10 every time I buy something from a shop? I might aswell use cash as its free to transact, I see this is as a core problem and a big barrier to bit coin adoption. Fees should be a % of the total transaction or at least on a partial gradient as small day-to-day purchases already are uneconomical and are only going to become more uneconomical in the future.

When i go to a shop they charge me a 21% of taxes, no product is under 5c and i never go to a shop to buy less than 50c in total, make your maths, bitcoin have the cheapest taxes in the first world.

Using bitcoins would not avoid sales tax. What B!tC0in said is very simple: You walk into a sandwich shop, a sandwich costs $3 (includes sales tax), you can buy it for $3 in cash or for $3.30 in BTC (assuming BTC price has risen more). You would be stupid to pay in BTC.

The merchant may offer a discount for electronic payment. Cash handling costs (counting it, bringing it to bank, fear robbery if too much cash, ...).

Consumer may not want to carry around cash, but carries the phone anyways.

How much do you think about getting a snack, a coffee, or a drink? Don't tell me you are going to care about those <10 cent.

The fee is OK. I don't mind it and always pay it. This is the way we support the system.
We are all here using Bitcoin and we should be positive towards it. Paying the minimum fee, advertising the system, implementing it to our websites (for webmasters). Like this we all can benefit in the the long run.

Please excuse if this has been asked before but quite a while back I mined 1.10024 coins through pools over a period of several weeks receiving payments on average  of 0.01xxxxxxx to 0.02 coins.
If I want to send a payment of say 0.5 coins to someone am I going to have to pay a fortune in fees because my one whole coin is comprised of lots of little bits?

If the seller have to pay this ----> http://www.mastercard.com/us/merchant/pdf/MasterCard_Interchange_Rates_and_Criteria.pdf he would pay also de bitcoin fee

So excepersive!~ >:( >:( >:(

So you need to send a fee on every transaction correct? Like what if I wanted to import a paper wallet of 28 bitcoins. do I pay a fee to import it on blockchain? then when I want to split those 28 bitcoins into separate paper wallets, lets say 2 bitcoins in each paper wallets. I would have to pay a fee? How much is standard fee on 2 btc? or is it automatically set on blockchain? is it true your transaction may never get sent through??  & is it possible that a hacker can steal all of them as they go through the blockchain?  BTW do I press import or sweep?? whats the difference???

While people that shop with credit cards and whatnot get charged a fee, those that shop with cash don't. Point is, while I can see the need to pay a fee for a cross-city or cross-country transaction, it's really unreasonable to pay the fee for a transaction you made to the clerk in front of you.

EDIT; I WAS WRONG WHEN I POSTED THIS AND OVERSTATED FEES BY APPROXIMATELY A FACTOR OF ONE HUNDRED.  I WAS OVERSTATING THEM BY ABOUT A FACTOR OF TEN OTHERWISE BUT I FAILED TO MULTIPLY CORRECTLY WHEN I WAS DOING THIS AND GOT AN EXTRA FACTOR OF TEN.  --CRYDDIT


If you want to spend 0.5 Bitcoins, (say, $500) and that takes you 30 to 50 of the size coins you've got, you'll be paying 25 to 38 dollars in transaction fees.  That's more reasonable than the situation the OP is faced with, but still damned annoying.  

 :o WHAT!? I thought blockchain had super low fees for transferring money?  So if I went on blockchain right now and transferred a paper wallet with 28 bitcoins and I wanted to put 5 bitcoins each per 1 paper wallet I would be nailed with a $30 fee?? I was watching max keiser the other day and he said it was like 80 cents to send a million dollars? -__- wth? or is this fee just for people who use wallet clients installed rather then the actual blockchain website itself??

You confuse "not ASAP" and "never for all intensive purposes" :P

The blockchain *did* have super low fees for transferring money, but those fees were denominated in Bitcoin, which, as you may recall, has gone up a hundredfold in the last couple of years. It isn't such a very small tx fee any more.  This is one of the reasons I'm anticipating a change in tx fees with the next soft fork.

Other than that we're having some miscommunication about the way we're using words like "bitcoin" (a unit of monetary value) and "coins" (single txouts of whatever value that go into a transaction).  

Most people have individual "coins" or technically "unspent txouts" in their wallet of denominations of 0.1 Bitcoin or less.  "Bitcoin" is a measure of actual value and "coins" is the number of spendable txouts that comprise that value.  

If you have a wallet with 28 bitcoins, but you got that amount in a single lump (ie, you have a single "coin" with a denomination of 28 bitcoins) then your transaction to transfer 5 bitcoin to another wallet will have tx fees of about eight to 24 cents depending on a few things.   On the other hand if that 28 bitcoin value is an accumulation of "coins" worth 0.01 bitcoin each, then you'll make a transaction of 500 inputs to transfer 5 Bitcoins of value, and it'll cost you something like $40 in tx fees.  

CORRECTION ADDED LATER: I WAS WRONG WHEN I SAID THIS AND EXPLAINED MYSELF LATER; SEE PAGE 4 OF THIS TOPIC FOR A CORRECTION TO MY MISTAKEN EXPLANATION.  THE ACTUAL TX FEES ARE 'FREE' AND 'UNDER $2' RESPECTIVELY. --CRYDDIT

 ??? so I can't put 0.0005 in the fees when I transfer 5 btc's into a new paper wallet?

Guess you cant o_0.

It is a major downer.  I hope problems like this do not kill the currency.  I for one really believe in it, but I can also foresee some real scams coming out.

Imagine you have a wallet with 10 BTC.  These 10 BTC are made up of 1,000 parts of 0.01 BTC.  You could show someone this and "sell" them the wallet address for money.  When they try to transfer this to their own wallet, they'll be shocked to find that the TX fee was over 10%. 

Hopefully fees can get lowered again, but if fees get too low once the miners are done mining coins... could be the end of bitcoin as we know it!


Also imagine once lifecoin runs out of coins, and they realise everyone stops mining?  Will that news automatically kill bitcoin?

Wait a minute, Do I get charged a fee for importing the balance into blockchain??!!  What if I only sent small amounts such as keep 12 at a time in my blockchain wallet and only 2 at a time to a paper wallet? why can't I get away with only pay 0.0005 in fees like it was  before??? or maybe it was 0.005 (whatever it was)

So much bad information. Why do you make these things up?

It's really not that difficult. Detailed info for the reference client here:
https://en.bitcoin.it/wiki/Transaction_fees

mintxfee has historically been lowered to be less than $0.1

So if bitcoin rises to 10k USD, people paying 10 dollars for something will have to pay a 1-5 dollars in fees??
I don't think bitcoin will survive very long unless these payments happen off the blockchain...

 ??? so can someone clarify this 0_o Is it a 0.0005 fee 70 cents or whatever it is or what??

Bitcoin wouldn't survive with off-the-chain transactions neither.
The current, simple payment system is one of bitcoins strengths and it has to work for bitcoin to be successful.
An intermediary between user and blockchain would make a simple and strong system complicated and weak and took away the original reason for bitcoins existence.
But I think we will see urgent changes in the protocol in the next months. Hopefully.

Such a complicated topic.  I wish I was more studied on these aspects of computing.  People out of the loop will be the last to know when bitcoin runs into trouble, and we won't be able to sell our coins before it's too late and the price has crashed to 0.  This, ofcourse, is assuming that things and fees can't be fixed...

Minimum fee in the reference client will likely be lowered everytime the the exchange rate rises. Minimum fee: <blink> less than $0.10! </blink>

A typical transaction only pays minimum fee. In some cases (I would call those expert use), the fees may be higher (one time fees for consolidating balances).

Miners can make their own rules. That means they could include transactions with lower than minimum fee or even no fee. The price of bitcoin is based on supply and demand, and so is the transaction fee! Make it worth it for the miner to include a transaction and it will be included.

could there be a situation where bitcoins which has a shorter history are worth more than ones with a longer history?

Like you say the OP is fucked basically and in my scenario nearly fucked as I doubt I would have used all that electric to mine had I known, I believed the "minimal fees" hype that everyone was flouting. It appears to me that Bitcoin is running into the realms of a currency of the wealthy ie. those who can buy whole coins, which will no doubt deter new users coming into the fold.
Could it not be built into the system that small fragments that are kept in a wallet for a certain length of time after x notifications are coalesced into larger units?

Trouble with those wiki articles is they are written by people who know bitcoin inside out and make little sense to someone with no technical knowledge.

(NOTE:  THIS POST HAS BEEN CORRECTED!  ALL THE PEOPLE WHO AFTERWARDS SAY THAT IT GAVE WRONG INFORMATION WERE RIGHT AND I WAS WRONG.  I HAVE EDITED THIS TO BE CORRECT SO THAT IT WON'T MESS PEOPLE UP IN THE FUTURE. ALSO SEE THE TOP OF PAGE 5 FOR THE CORRECT PROCEDURE TO DETERMINE FEES WITHOUT THE RANTING ABOUT POOR DOCUMENTATION I DID BELOW.)

Let me see if I get this:

First you have to figure out how big your transaction is, using a formula that the wiki never tells you.  It took hours of reading and guessing and searching the wiki to figure out what the formula is.

I will tell you now, but it took the rest of this post to figure it out.  It's 12 bytes, plus 204 bytes per input, plus 32 bytes per output. If it's more than 256 inputs or outputs, add one byte.  If there's anything even a little bit unusual about the "scripts" involved for any input or output, this formula is not valid. Remember that your transaction usually has at least one more output than is visible; this is because you don't usually have exact change, and the transaction must split at least one of your coins (and may consolidate others) to come back to you.

Second, figure out your transaction's "priority" using a stupidly complex formula that they don't tell you how to calculate.

The formula is given as priority = sum(input_value_in_base_units * input_age)/size_in_bytes.

But I use input value in millibitcoins instead, to save the bother of dealing with five unnecessary decimal positions.

In order to figure out what it means for a given transaction, you must first multiply the value of each input in millibitcoin times the number of days since it was paid to you, add all the products together to get a sum, convert the number of inputs/outputs in your transaction to size_in_bytes, then divide the sum by the size_in_bytes which they did not tell you how to calculate.

Your transaction is "free" if all of the following are true.
 * it's smaller than 10,000 bytes. (but they didn't tell you how to figure that out)
 * All the outputs are 0.01 BTC (currently around $8) or larger.
 * priority is greater than 576. (and you couldn't know that without being able to figure out the size)

(Note: when dev guys talk about "priority" they'll add five zeros onto the end.  I've simplified the formula so you don't have to).

Your transaction is also "free" if its priority is higher than the priority of all other transactions in the block except for enough other transactions to make 27,000 bytes (BUT YOU HAVE NO IDEA WHETHER OTHER HIGHER-PRIORITY TRANSACTIONS ARE GOING INTO THIS BLOCK, AND THEY DON'T TELL YOU HOW TO CALCULATE THE SIZE IN BYTES OF YOUR TRANSACTION OR GUESS AT THE SIZE IN BYTES OF OTHER TRANSACTIONS OR TELL YOU WHAT IS TYPICAL NUMBER OF FREE TRANSACTIONS YOU'RE COMPETING FOR SPACE WITH).

Now, if your transaction qualifies as "free" it will be propagated across the network without fees.  But the reference client will not spend more than 15,000 bytes per minute on propagating such transactions (AND YOU HAVE NO WAY OF KNOWING HOW THAT AFFECTS RELIABILITY AND SPEED  WITHOUT KNOWING WHAT THE TYPICAL TRAFFIC IN FREE TRANSACTIONS IS AND/OR HAVING THE RESULTS OF EMPIRICAL MEASUREMENTS).
  
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, round it up to the next even multiple of a thousand, then multiply the result by 1 0.1 microbitcoins.

And the final gotcha: if you have to add another input, or more than one other input, in order to cover the transaction fee, then the size of your transaction in bytes has changed, and you must start over and figure out your fee again.  And if you get your fee even one Satoshi wrong, then most clients will just drop your transaction on the floor instead of propagating it and you'll have absolutely no benefit from the fee you did add. If your transaction confirms at all it may take days, and the fee will have been a complete waste of your money.

********** STOP READING HERE UNLESS YOU WANT TO KNOW HOW I FIGURED OUT HOW TO FIND THE SIZE OF TRANSACTIONS *******

Does that about sum it up?  Clear as mud?  What's that?  Still have unanswered questions about the size of your transaction which was the first thing you had to figure out?  

Okay, going to https://en.bitcoin.it/wiki/Transactions, we can start to figure out how to find the size of a transaction in bytes.

it is 8 bytes, plus the size of the input count, plus the size of the output count, plus the number of inputs times the size of an input, plus the number of outputs times the size of an output. Nice and simple, right? questions answered, right?

oh, wait; THEY DON'T TELL YOU ON THAT PAGE WHAT THE SIZE OF AN INPUT OR THE SIZE OF AN OUTPUT OR THE SIZE OF THE INPUT COUNT OR THE SIZE OF THE OUTPUT COUNT IS.  

Okay, going to https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer we find the size of the input count and the size of the output count.  You're going to laugh.  If the number of inputs is less than 0xfd it's one byte.  Add another 2 bytes if the number of inputs is more than 0xfd and *another* two bytes if the number of inputs is more than 0xffff.  The number of outputs is given the same way.  For those who don't speak Martian, those numbers are 0xfd=254 and 0xffff = 65536.  Because Martians count in base 16, that's why.  

For any "normal" transaction, call that 12 bytes plus the number of inputs times the size of an input plus the number of outputs times the size of an output.  But if you're using "dust" (more than 254 inputs) it can be 14 bytes rather than 12, so keep that in mind.

The size of an input is given at https://en.bitcoin.it/wiki/Transactions#general_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin.
It's 40 bytes plus another Martian number plus the size of the in-script.  

The size of an output is given right below it.  It's 8 bytes plus another Martian number plus the size of the out-script.

And the size of the Martian numbers depends on the size of the in-script and the out-script. BUT THEY DON'T TELL YOU ON THAT PAGE HOW TO FIND THE LENGTH OF THE SCRIPT.  

Okay, it looks like scripts are almost universally less than 0xfd long, so the Martian numbers are going to be one byte long unless there is something really weird going on. That makes inputs 41 bytes plus the size of the in-script, and outputs 9 bytes plus the size of the out-script.

Going to https://en.bitcoin.it/wiki/Script, we find that the "standard" script consists of

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG.  all of the OP_whatever are 1 byte, so this is 4 bytes plus the length of a pubKeyHash which is 20 bytes.  Total is 24 bytes.

And it doesn't say ANYWHERE I can find whether this is the standard for an in-script or the standard for an out-script.  You really need to know in order to figure out how big your transaction is in bytes. According to their example however, which I can read because I can read Martian, this has to be the standard for an out-script.  So each "output" of your transaction, if it's a normal transaction, is 32 bytes - a nice round number, in Martian.

Now, an in-script is mentioned nowhere in the whole damn wiki, except on the page that says you need to know how big it is to figure out the size of your transaction and then doesn't define it.  However, back on the Transactions page in an earlier link, it says that the "ScriptSig" is the "first half of a script" and that's the only mention of a script anything in the inputs of a transaction so it's pretty much got to be it.  It also says that a "ScriptSig" consists of a signature and a public key.  Okay, great.  The size of an input is 41 bytes plus the size of a signature plus the size of a public key.  Going back to the protocol specification, we find out that the size of a signature is two 32-byte integers plus a prefix 04 (presumably one byte).  So, probably 65 bytes.  But it can be given in a "compressed form" where one of the 32-byte numbers is replaced by a "sign" telling whether it is even or odd.  The "sign" is 0x2 or 0x3 - again presumably one byte, so the compressed form is 33 bytes.  So a signature is either 33 or 65 bytes, and we don't know which, making our input 74 or 106 bytes plus the size of a public key.  I couldn't find anything on the wiki defining the number of bytes in a public key, so that's a dead end.  However, there is a transcript of a Martian conversation on the protocol specification page that actually mentions a scriptsig and says that it's 139 bytes long.

139 plus either 65 or 33 bytes is 204 bytes or 172 bytes.  Neither of those is a particularly "round" number in Martian.  Nor does it tell in English anywhere which of them you should use.  But, when I searched for "33" there was nothing interesting on the wiki and when I searched for "65" I found the page https://en.bitcoin.it/wiki/OP_CHECKSIG with a transcript of a Martian statement where it actually checks an input signature, and that signature is in fact 65 bytes long.  Taking that as the norm, we conclude that each input is then 204 bytes long.  

So, after a lot of chasing and assumptions and guesswork and reading in Martian where it's not given in English, the formula for the size of your transaction is the following:

12 bytes, plus 204 bytes per input, plus 32 bytes per output.  

I'd put this formula into the damn wiki, except they want me to pay ten bucks for the privilege.

Okay, not spreading "misinformation" any more.

User Cryddit has been posting some misleading responses, using terminology that is not used to describe transactions. There is no such thing "coins" like he is describing, and there is no "whole coin" or bitcoins are "too expensive".

Read, understand:
http://we.lovebitco.in/how-bitcoin-works/transactions/

A transaction is composed of inputs, also known as unspent transaction outputs - individual previous payments that were received by a wallet, either to the same address or to multiple wallet addresses.

Those previous payments are then used as needed to fulfill the balance of a payment you may want to send. Here is a some examples of real transactions, demonstrating how large a transaction may be, based on the number of inputs it uses:

• 1 input: 257-259 bytes  - 1x minimum fee
• 5 inputs: 976-980 bytes - 1x minimum fee
• 8 inputs: 1514 bytes - 2x minimum fee
• 39 inputs: 5848 bytes - 6x minimum fee

Lets make the most extreme example possible: you signed up for some scam-faucet that paid you what we would call "dust", useless payments of 0.00006 (nearly the minimum allowed to be sent, a few pennies). Then the fees would be a significant portion of a payment:

• 0.00006 x 39 = 0.00234
• minimum fee 0.0001 * 6kB =  0.00060

You can see that even dust is still spendable. For transactions that aren't bloat-by-design, the minimum fee will not be a multiplier of the minimum or a significant amount.

To answer the question, users can manage and consolidate their own coins. When you send your next payment, you can add another recipient, yourself, and send the balance of your wallet back to a new wallet address to solve the dust problem in the most efficient manner.

I can see fees becoming a scammers dream.

Imagine "for sale 0.8 BTC , $US at Mt. Gox rate, you pay fees" and your'e buying hundreds of bits of dust.

This is incorrect. Even if the transaction is from many txouts in the sender's wallet (and they have to pay a larger fee), you will be receiving a single consolidated payment for the amount.

The only instance where "buyer pays fees" may be services where you withdraw a balance from your account on an exchange or pool to your wallet. Professionals manage their wallets so amplified fees don't occur.

WAIT A MINUTE.. so can I still get a fast transaction with sending 12 btc's to a paper wallet with only a 0.0005 fee? or 0.005??   ???   Now why do you all come up with $40 fee charges? people are sending 1 million dollars of bitcoins and they pay a 1 dollar fee?? I don't understand? when you say 0.005 fee does that actually mean 0.005% they are charging   you out of your 12 bitcoins????????????????

Fees are needed to pay miners for their work in securing the network.
If miners don't work, transactions won't ever confirm anymore.

So you just have to pay miners enough for them to keep on confirming transactions.
0.0000001 or 0.05, all depends on what the miners think is acceptable.
If you don't agree, just mine and setup your own fee policy.

/thread.

(NOTE: I HAVE EDITED THIS.  IT GIVES CORRECT INFORMATION NOW)

Okay,  first thing:

12 bytes plus 204 per input plus 32 per output is not misinformation.

And it's also pretty much obscured in the so called documentation so nobody can get it without chasing down multiple pages and obscure clues.   That isn't misinformation either.

And I used the term "Coin" because "unspent txouts" is Martian and I was trying to explain it to non Martians.  And I explained it the first time I used it and when someone confused it with value in bitcoins I explained it again.  I will not call that misinformation.

For everything except for my immediate previous post I was speaking approximately DEAD WRONG and ignoring the free transactions that people whose wallets are full of dust won't get anyway. You could call that misinformation if you want to but people who try to spend dust will find it close enough to true that they can't tell the difference. WAS APPROXIMATE AT BEST, IGNORED RULES THAT GOVERN FREE TRANSACTIONS, AND OVERSTATED FEES IN MOST CASES BY ABOUT A FACTOR OF TEN.

And in the post right before you accused me of lying I laid it out accurately WRONG BY A FACTOR OF TEN and in great detail.  

So I'm a little bit upset about the accusations and I won't repudiate the advice I gave DEAD WRONG ABOUT FEES AND DEEPLY REGRETFUL FOR ANY ANXIETY I HAVE CAUSED.  You can I WILL go through and make the figures exact if you want to AS PENANCE FOR MY STUPIDITY but don't call anyone a liar unless you provide the complete truth.

If less people are mining, will the difficulty go down?  And if the difficulty goes down, does that mean that fees become more profitable for miners?  Shouldn't that equal things out?

how many confirmations are usually needed on blockchain for bitcoins? like 2 btc's or 12 btcs moved to a paper wallet??

Dude, you missed it where he said "you pay fees" was part of the deal. 

That's a dumb deal to accept, and highly nonstandard, but Deesome is absolutely right.

So theoretically if I have a wallet loaded with a small balance say 1.2 btc comprised of dust transactions, I could re-download the bitcoin client with a new wallet address and start mining with no fees then send myself the 1.2btc.
Would that consolidate the dust into one Bitcoin transaction?

Thanks Cryddit, the scenario I was imagining was newbies with not a lot money to invest wanting to get into Bitcoin.

(NOTE: THIS HAS BEEN CORRECTED.  IT GAVE INFORMATION PREVIOUSLY WHICH WAS WRONG BY A FACTOR OF TEN.)


Okay, I've been accused of misinforming DID IN FACT MISINFORM you so let's step through this.  

You have 28 bitcoin in your wallet and you want to transfer 5 bitcoin to someone.  

First scenario: your wallet contains 1 coin, whose denomination or value is 28 Bitcoin.  This is a straight-up transaction with one input (your 28-BTC coin) and 2 outputs (your friend's 5 BTC coin and whatever you get back from the transaction.)

The transaction size is 12 bytes, plus 32 bytes per input, plus 204 bytes per output. It could have been free based on its size.

But one of the inputs is worth more than 0.1 bitcoin, so it isn't free.
THE INPUT IS WORTH MORE THAN 0.1 BITCOIN SO IT CAN BE FREE.  

(CORRECTION FOLLOWS.  BECAUSE I WAS WRONG ABOUT THE ABOVE THE PRIORITY OF THE TX IS RELEVANT.)  
The priority of the transaction is value in millibitcoins of the input, times age of the input divided by the size in bytes.  The size in bytes is 452 bytes, the value in millibitcoins of the input is 28000, so the priority is 26216000 divided by the age of the coin in days.  This is over the threshold of 536 if you've been holding the coin you're spending is more than 1/4891 days, which is a bit less than 2 seconds.  So we're going to guess that it's well over the priority needed to be a free transaction.


So this is in fact a free transaction.

(END OF CORRECTION REGARDING PRIORITY)

Total transaction size is 12 + 32 + 408 = 452 bytes.  Round it up to the next multiple of a thousand, so it's considered as 1000 bytes. You need to multiply the 1000 times 1 1/10 microbitcoin to get the fee, so you'll pay 1 1/10 millibitcoin.  Based on 750 dollars a bitcoin, that makes your transaction fee about 7.5 cents 3/4 of a cent.  I said 8 to 24; so I was wrong, it was a little bit below what I thought was the minimum of the range.  But considering that you're transferring 750 x 5 = 3750 dollars, 7.5 cents 3/4 of a cent isn't such a bad fee. AND FURTHERMORE YOU DIDN'T HAVE TO PAY IT BECAUSE IT WAS A FREE TRANSACTION.

Second scenario:  You have 28 BTC in "coins" denominated 0.01 BTC each and you want to transfer 5 BTC to someone.  

The transaction size is 12 bytes, plus 32 bytes per input (and you have at least 500 inputs) plus 204 bytes per output (and you'll have either one or two outputs).  12 + 16000 + 204 bytes is 16216 bytes.  And you have to add another 1 byte = 16217 bytes because more than 254 inputs.   That's not a free transaction.

Okay, based on size 16216 bytes, you round it up getting 17000 bytes.  you multiply that by 1 0.1 microbitcoin and you get a fee owed of 17 1.7 millibitcoin.  Your fees are 17 1.7 millibitcoin, so you have to add 1 more input to cover it making 517 501 inputs.  That changes the size of your transaction.  you now have 12 + 1654416032 (inputs x 32) + 1 (for having more than 250 inputs) + 204 (for 1 output).408 for 2 outputs because you need to get change.  Your transaction size is now 16567 16453 bytes.  Because that also rounds up to 17000 bytes, you don't have to add any more inputs changing the size of your transaction again.

Now, you multiply the 17 1.7 millibitcoin fee times the 750 dollars per bitcoin and you get $12.75. $1.275 In this scenario your fee for transferring the same 3750 dollars is 12.75. $1.275  When I was guesstimating I told you it would be something like $40, so I was over by $27.25 $38.75 because adding inputs is cheaper than IS FAR CHEAPER THAN I thought it was.

So this is the truth that someone who called "misinformation" did not provide; you transfer your 5 BTC and if you have in your wallet a larger-than-5-BTC coin or a whole bunch of 0.01 BTC coins, it costs you somewhere between 7.5 cents FREE and 12.751.275 dollars.  

(NOTE, I HAVE EDITED THIS.  IT GAVE WRONG INFORMATION PREVIOUSLY.  EDITS ARE MARKED WITH STRIKEOUT AND CAPS. )


You're someone else I've been accused of misinforming, so let's step through it; I was considering per-input tx fee to be about 7 or 8 cents, so I thought bitcoin ten times as expensive would mean that per-input tx fees would be 70 or 80 cents.  

Let's reconsider:  
Bitcoin transactions of 1 input 2 outputs (the 3-address transaction I was thinking of) actually occupy less than 1000 bytes, hence can qualify to be free.  If all inputs are less LARGER THAN than 0.1 BTC and its priority is 57600000 or higher, (by the devs formula with the 5 extra zeros) it can be free.

Okay, current scenario for transferring $5 in value with bitcoin at $750:  $5 is 1/150 of a bitcoin, so it's a good bet that all inputs are less than 0.1 bitcoin (currently about $75).  

SO THIS ISN'T FREE AND THE PRIORITY IS NOT RELEVANT.
If the priority is 57600000 or higher it can be freeCOULD HAVE BEEN FREE EXCEPT THAT THE AMOUNTS ARE TOO SMALL.  You're trying to transfer 0.006666.... of a bitcoin, so if you've got exact change the priority is 666667 (the value in satoshis) times the number of days you've held the coin you're spending.  So if you've had this txout unspent for more than 864 days it's a COULD HAVE BEEN A free transaction.  If you've had that txout unspent for less than 854 days it isn't a free transaction.  Do you actually know how old your unspent txouts are?  I'll assume you've held it for less than 2 years and go on.

Anyway, the transaction is under 1000 bytes, so you multiply the 1000 times 1 0.1 microbitcoin and you get 1 0.1 millibitcoin or 7 0.7 cents.  On a $5 transfer.

Now consider the future scenario I mentioned, with bitcoin going north of $10K and you're still trying to transfer $5.  The amounts are 1/10 what they were before so it passes DOES NOT PASS that test, the size is still exactly what it was before so it passes that test, but the priority is less than 1/10 what it was because the coins are smaller BTC denominations, so it fails the last test unless you've been holding the coin for more than 11387 days. That's 31 years and a bit over 11 months so I'll assume the coins aren't that old and therefore this transaction is definitely not free.

But the fee is still based on transaction size, and transaction size is exactly the same, so the fee is still 1 0.1 microbitcoin.  Except in this scenario the microbitcoin is worth $1 SO YOUR FEE IS A DIME.  that's a bit more expensive ONLY ABOUT 2/15 OF than the 70 or 80 cents I guesstimated, but SO I was WAS NOT in the right ballpark.  $1 seems a bit steep for a $5 transfer, doesn't it?

You know what?  I *DID* misplace that decimal.  It's 0.1 microbitcoin, not 1.0 microbitcoin.  So, yes, this scenario actually owes 1.7 millibitcoin or (currently) about $1.75 rather than $17.5 as I thought.  

Quite a difference to say the least.

Okay, time for a public apology to everybody:  I've believed that fees are a factor of ten higher than they actually are, and I have in fact been giving misinformation.  

This is difficult. I need to apologize especially to deepceleron, who called me on my mistake, even though he didn't provide the specific information to correct it. I was wrong and you corrected me and I got mad at you.  I'm very sorry and deeply embarrassed.

And a special thank you to anth0ny, who DID provide the specific information to correct my mistake.

I would not have noticed this mistake except that anth0ny corrected me on a specific point showing exactly where (and why) I'd gotten it wrong.  As I already said once, if you're going to call someone a liar you have to specifically provide the truth.

Next post, I'll put the REAL fee calculation formula, because I can't go back and correct the one I already posted.  I will delete it though so that it doesn't lead anyone wrong in the future.  

It turns out that I was allowed to go back and correct my previous posts.  I have done so so that they will not lead people wrong in the future.

It is of great character to admit when one was wrong. We all do mistakes, my biggest one was selling 5 BTC last year and now having only less than 0.09... I'm looking forward to your correct post because I agree that this transaction fee stuff is very unclear to many people and needs some better explanation so that people do not get burned. You might want to add the tips regarding consolidation of dust into such a post.

Kudos to Cryddit for admitting a mistake and more so for attempting to educate us less knowledgeable users.

@ anth0ny , thanks for the offer of exchange but I think I'll hang on to my bits for now lol.

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

Step 1: Determine the size of your transaction in bytes.  It's 12 bytes, plus 204 bytes per input, plus 32 bytes per output. If it's 255 inputs or more, add one byte.  If it's 255 outputs or more, add one byte.  Likewise if it's 65536 or more inputs or outputs, add another byte. If there's anything even a little bit unusual about the "scripts" involved for any input or output, this formula is not valid. Remember that your transaction usually has at least one more output than is visible; this is because you don't usually have exact change, and the transaction must split at least one of your coins (and may consolidate others) to come back to you.

(NOTE:  It has been pointed out that because a key in the input can be 41 rather than 65 bytes, an input may take 180 rather than 204 bytes.  The person who pointed this out has not yet provided any way to tell whether an input takes 204 or 180 bytes.  Therefore treat the above as an upper bound and 12 bytes, plus 180 bytes per input, plus 32 bytes per output as a lower bound. 

Some definite method to tell exactly will be provided as soon as I absolutely know how to tell exactly how long that key is.  )

Step 2: Determine your transaction's "priority." The formula is given as priority = sum(input_value_in_base_units * input_age)/size_in_bytes.
But I use input value in millibitcoins instead, to save the bother of dealing with five unnecessary decimal positions.

Your transaction is "free" if all of the following are true.
 * it's smaller than 10,000 bytes.
 * All the outputs are 0.01 BTC (currently around $8) or larger.
 * priority is greater than 576. (note that developers use the number 57600000; it's 576 because I used millibitcoins rather than satoshis above)

Your transaction is also "free" if its priority is higher than the priority of all other transactions in the block except for enough other transactions to make 27,000 bytes but you can't know that when you're figuring out fees.  If you don't pay fees the transaction may be indefinitely delayed by higher priority transactions. Anyway, if your transaction did propagate across the network, there will eventually be a block with room to put it into that 27000 bytes. It may not be the next one or the one after that, but it'll happen.

Now, if your transaction qualifies as "free" it will be propagated across the network, though maybe somewhat slower, without fees.
  
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.

And the final gotcha: if you have to add another input, or more than one other input, in order to cover the transaction fee, then the size of your transaction in bytes has changed, and you must start over and figure out your fee again.  And if you get your fee even one satoshi short, then most clients will just drop your transaction on the floor instead of propagating it and you'll have absolutely no benefit from the fee you did add. If your transaction confirms at all it may take days, and the fee will have been a complete waste of your money.

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.

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.

What is incomplete?

I'm not making any statement about IF the network is worth securing or if the User who pays the Transaction fee 'deserves' to pay it or not.  But if you want to go their, then yes the Hoarder should pay for security, it is after all the future USABILITY of his own coins that are being protected by that security.  Is anyone under any illusion that if the network weakened and allowed double spends or transactions took forever that the person just holding coins would lose value because confidence in the coins generally would be lost.  The level of entitlement among BTC holders is just beyond comprehension sometimes.

Now my point is just that Transaction fees slow down ALL commerce, period.  Their are going to be transaction that would otherwise happen, but don't because of the transaction fee, be it a Tax or a credit-card fee or what ever you can imagine.  Therefor you want transaction fees as low as possible all other things being equal.  Obviously the current design has undesirable (possibly even fatal) trade-offs but that's not the point I'm making.

And as for the need to send every transaction, yes it is still their in the form of the block download, the every user needs to record of transactions to use the system as it was designed aka not putting trust in anything but the block-chain.

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

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.

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


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


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.


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.


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

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

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 (https://bitcointalk.org/index.php?topic=322058.msg3717707#msg3717707).

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

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

What $8 fee?

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.



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

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.

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.

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.

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.

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.



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

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.

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

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

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.  


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?

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)
 


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.


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)

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:


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.

Good riddance Bitard.

It's gonna be fun a convoluted mess. ;)

Any one who has shipped million user software preaches K.I.S.S.

You are asking for complexity devolution.

The answer to your question is complicated. But leaving out the math,

If your wallet has been made by you receiving payments of 0.001 BTC at a time, there is no way you can make a 5 bitcoin payment in one transaction because your transaction would exceed the limit on the size of the block.  

If your wallet has been made by you receiving payments of 0.01 BTC at a time, your fee would be 10.3 millibitcoin (or about 80 cents US at current prices) but might take a very long time to confirm because its size is huge in bytes.
                      
If your wallet has been made by you receiving payments of 0.1 BTC at a time, your fee would be 1.1 millibitcoin (or about 8 cents US at current prices)

If your wallet has been made by you receiving payments of 1 BTC at a time, your fee would be 0.1052 millibitcoin  (about 0.8 cents US at current prices). But this transaction will be free if you owned at least 5 coins with an average age of at least 2.77 hours before you make this transaction.

If your wallet has been made by you receiving payments of 10 or more BTC at a time, 0.1 millibitcoin (or about 0.8 cents US at current prices)
But the transaction is free assuming you got at least one of those payments more than 1.4 hours before you make this transaction.

In each case the transaction fee your client asks for may be lower, down to about 9/10 of the above estimate depending on rounding errors and the key size your client uses in the transaction inputs.  As far as I can tell there's no way of knowing this.

That's something "blockchain.info" could compute. There's a list of Mt. Gox transactions not confirmed for 2 hours (http://skanner.net/MtGox/mtgox_tx.php), which indicates that the fee required to get a transaction through in less than 2 hours is at least 0.001 BTC.