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.

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?

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

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.

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.

They increase the market capitalization, but they do so without trading, so the market remains very thin and relatively small sales can still make it move a lot, just as though it were a much smaller market capitalization.

It is traders, not hoarders, who increase the effective market capitalization.  It is trading speculation (ie arbitration), not hoarding speculation (ie buy and hold), that provides a service by keeping the markets efficient and reducing market inefficiencies.

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.

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.

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.  

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

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

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.

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

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

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

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.  

You realize that someone who wanted full current value for his coins (and sanity for the bitcoin economy itself) would not kill the price; he'd just stop the price from rising quite so fast.  Offer a bunch of coins at $1000 setting up a "wall" there that takes a week or so to break, even with newbies getting in as fast as they can, then let it roll for a little while and set up another "wall" at $1200, etc.  People with that kind of money can choose to just plain *stop* the price from going hyperbolic (and then crashing) when mainstream adoption kicks in. 

And that may be what they're getting ready to do.  We've been with the highs and the crashes for years, but we're not the mainstream yet.  The mainstream would be terrified to get into something and *then* discover that it's as volatile as it's been for us.

Anyway, someone with this kind of coin can do a lot to dampen volatility.   

You'll be spending time and effort and, as the above poster said, possibly online reputation, on it.  We haven't yet seen an altcoin launched with a million-dollar advertising campaign, but launching an advertising campain while there are hardly any available coins would be at best problematic and probably contribute to the worst kind of pump-and-dump, with the price crashing hard again immediately after the ad campaign concludes.

I would say the odds of launching an altcoin ever becoming financially profitable are at best small unless you are either scamming or  have a credible solution for a problem that Bitcoin itself doesn't solve.  Right now Bitcoin is weakest in micropayments (due to high tx fees) reliable rapid clearing (slow block/confirmation times) and for full nodes, setup time/costs (for downloading the enormous blockchain).  But these three things are related such that you cannot make any of them better without making one or both of the others worse unless you come up with a better fundamental design.

I would advise against both Scrypt and Bitcoin-style proof-of-work.  If your coin is ever listed on exchanges, both will attract mining behavior that works like an attack.

Possibly the best thing you can do for your altcoin's long-term value is putting up a commerce site where you actually sell stuff taking the altcoin as payment and put some kind of very easy to install client on as an ultra-simple one-click download.  Whether you can do that profitably or not I don't know. 

Something my dad used to say, except he spelled it wrong...

"Beware false profits!"

I had a cool grandpa who corrected his spelling though.

When we bought in, I did as much analysis as I could and told my wife "The odds right now are too low to put more than 3% of our portfolio in, but I think there's three, maybe as much as five, orders of magnitude in this."  I usually give a five year outlook like 40% or 30% so "orders of magnitude" was a whole new vocabulary.  She looked at me like I was crazy. 

But at this point we've already got two (when it hits a thousand in December), and given recent hearings/legislation/other good news I'm confident of the third (the 10K) by the end of 2014 now.  And holy crap this isn't just 3% of our portfolio anymore...  but I am *NOT* reapportioning for diversification at this point. 

Whether we're going to see the fourth ($100K) and the fifth ($1M) orders of magnitude it's still too early to tell.  I would say the odds on the fourth order look good by 2016, but the fifth order ...  is as yet unknowable.  Nice to think about, not terribly unlikely, but unknowable.