Topic: Do you want to pay the fee? (Read 6894 times)

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

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.

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

You are asking for complexity devolution.

It's gonna be fun a convoluted mess.

Good riddance Bitard.

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)

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?

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

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.

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

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.

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

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

What $8 fee?

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

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.

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.

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

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.