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.

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)

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

One word.
https://en.wikipedia.org/wiki/Network_effect

Ok I lied it is two words.

That being said I do think either
a) other alternatives will eat into Bitcoins "marketshare"
or
b) Bitcoin will be replaced by something vastly superior.

Most of the lets change a couple variables and call it an alternative will die out though.  They will never gain a sufficiently sized network to be anything of real value (>$1B in money supply or >$10B in annual transaction volume).

Do you know his real name?  If not they you probably will do business with him in the future just under a new pseudonym.  Scammers love marks and once they find a pool they won't stop coming back.  Hell even if you DO know his real name the fact that you went into "business" with a totally anonymous person means you probably will do "business" (wealth transfer from you to him) in the future.

Well can't say this was unexpected.  Still those who are claiming it is all legal to sell $12M worth of unlicensed securities without proper disclosures (a short PPM for a startup is generally 60 to 100 pages) and shut up shop less than a month later I have to ask WTF?

I mean what are you smoking?  Of course it isn't legal.  Then again NO bitcoin based security is legal HOWEVER generally securities agencies really only look for fire where there is smoke.  So if they don't get complaints they don't go looking.  Pretty sure securities agencies in Australia would be pretty interested in a $12M securities sale and company closure within a month.  Still given the history of Bitcoin scammers he may certainly get away with it, but stop with the "everything is 100% legal to steal $12M under false pretenses".


Before someone says "fee shares" aren't securities, don't make yourself look stupid.  They are called revenue share contracts and yes they are securities in just about any country.  http://www.bolstr.com/

I have owned some (not the stupid MCXFee shares real ones in franchises) and they are most certainly regulated.  RealSolid sold unlicensed securities.  That is a crime even if there was no other underlying crime.  The nature of the sale, insider trading, and shutdown certainly indicates it is more than just unlicensed securities but even IF it was just unlicensed securities that is a crime.  Period.   The reality is security laws exist to protect the issuer as well.  If facebook was an unlicensed security in the early days nobody would care.   Who is going to complain when to the SEC when your $1,000 investment is now worth $10,000,000.  However most business ventures fail and when they fail (even legitimately) people are unhappy.  The black and white terms of security offering and disclosure seek to indemnify the issuer against normal business failures (but not fraud).

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.

0 (well technically the 50 BTC in the genesis block but due to a client bug they are unspendable)

Yes that is correct for both questions.

Bitcoins can only be mined in blocks of 25 BTC (was 50 now is 25).  

However most people mine in pools.  When the pool solves a block you get you share.  Most pools allow you to earn tiny fractions of a block and payout in increments as little as 0.0001 BTC.

If you are solo mining it is all or nothing.  You either solve a block that day (25 BTC) or you earn nothing, absolutely nothing.  If the calculator is showing 0.05 BTC per day then another way of looking at it is 0.05 / 25 = 0.2%.  You have a roughly 1 in 500 chance of solving a block each day.

There is no progress in mining so you don't "lose" anything by stopping.

What is incomplete?

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.

Same problem here.  Reported it to Gox support. 

Addresses are not intended to permanent.  Using new addresses is a non-issue.  I have in company walles used tens of thousands of addresses for a single use only. Personally (and I am not the only one) I find the accounts in bitcoind to be next to useless.

I do the following:
1) get new address from bitcoind
2) assign it to a customer account/order (in a database)
3) "look" for payment and credit the correct account (in a database)

Essentially putting all "account" data in a customer database and just use bitcoind for assigning addresses and recording transactions.

I am not sure which clients support re-using addresses and sending change back to the source because it isn't a "feature" I have wanted.

1) You can't.  Your options are to use a patched version of QT client "coin control" or a different wallet

2) You can't. 

3) You can but you need to use pywallet.  There is little reason to delete addresses.  If you delete it and someone sends funds there, they are lost forever.

4) No idea going to need more details.

your link is broken.

Somehow you got a ftp: in with the http:

Come on guys.  The world is never black and white.  Even in centrally planned economies there were some elements of free markets.

The concept is freeer. A perfectly controlled or free market has never existed.  However the freeer the market the more effective it is.

So if 15vDgtGfyenStzEhddGmGfWS8bATu9sysP was your bter deposit address then the funds have been sent there.  If they haven't credited your account you should contact bter. 

Post the tx id?  Based on your vague explanation it is hard to understand what you were doing or trying to do.

Theft is also theft.  I thought you had stolen enough and were leaving for good?