Topic: transaction fees (Read 3366 times)

Lot of great info, thanks a lot guys.

I think you are still trying to think of it in terms of value and not in terms of inputs.  It is impossible the the input to not be 1 BTC because the output of the prior tx was 1 BTC.   The tx can be in the same block it won't cause a problem.

Remember there is no such thing as "value" you are simply passing prior outputs as inputs.  Nothing more.  Don't try to think of it as once the network confirms it this output suddenly becomes "worth" 1 BTC.  That is a fallacy.  If you receive a 1 BTC output it is worth 1 BTC.  It doesn't matter if it isn't included in ANY block.    The purpose of blocks is simply to prevent an alternate form of the tx from being accepted by the network.  The block doesn't suddenly make the tx have value.  It just records it to ensure someone can't use that 1 BTC output as an input for a different transaction.

Thanks Danny, this was the magic I wanted to know:


Now I think I can understand this thing. It works like a double-entry bookkeeping system in the background
and the whole blockchain is like a gigantic account of the whole economy, and selected transactions related
to only a specific wallet show the bookkeeping account of that person/organization who owns that wallet --
when (s)he does not have other wallets, of course.  What you call "input" is the "debit column" on the bookkeping
account, and "output" is just te bitcoin name of the "credit column", but basically these things are the same.

Wow!  Did bitcoin unconsciously reinvent Luca Lacioli's ~500 y.o. system?  Or was it conscious...?


But I still have some implementation specific questions here.  In your example, if someone has a 2 BTC input,
and wants to send 1 BTC to someone else, and the standard client creates that hidden address to send the
other 1 BTC to the same wallet...

a)  can I see that "hidden" address with a getaddressesbyaccount ?  (I think I should...)

b)  isn't it a problem that I try to send the other 1 BTC to a third account (I'm talking about the second transaction
in the example that goes to another friend...), but the two transactions may go to the same block, and the "hidden"
address does not have any BTC received until this block is hashed/closed/minted, so if I try to send the second
1 BTC and somehow the two transactions go to the same block, the second will have 0 BTC input, and 1 BTC
output?  (If this goes to a later block, then it's fine.)

It should be pretty easy to use the raw transactions API to implement a "send all".

You would do:
  listunspent --> list of inputs
  Then estimate a reasonable fee (this is the hardest bit, but listunspent tells you amount and #confirmations and you can estimate tx size based on number of inputs)
  createrawtransaction/signrawtransaction/sendrawtransaction

Somebody should write a little python tool we can ship in contrib/

I'm sure there is a way to do this correctly, but a practical solution would be to send all but a bitcent or maybe even just a bitmil. Unless you are destroying the wallet and doing this all the time or something.

I'm ready to pay the transaction fee, the problem is that I don't know how to calculate it in a script.  If I want to move all the coins from one wallet to another, I even don't know how to do it, because there's no coin left in the source wallet, so there's no money to pay the fee.

What I need here is a transaction that tells the client:  please send all my BTC to this address, but I'm fine with the fact that the receiver will get a bit less because of the transaction fee.

I'm not 100% certain, I haven't looked into the the new "sendrawtransaction" API call that was implemented in version 0.7, but I think you can build your transaction that sends all your coins and then make the sendrawtransaction API call.  If you happen to be connected to nodes that are willing to relay the transactions without the fee, such as Lightfoot Hosting's node from the wiki, and any of those nodes happen to be connected to any miners that are willing to include the transaction in a block without a fee, then your transfer should eventually be successful.

On the other hand, you could just pay the tiny fee compensating the miners for assisting you in completing the transaction.

I'm a bit confused now.

What if I want to write a script that automatically transfers all my coins
to another address?  I just cant't do it because of the transaction fee.
I can get the balance from the standard client by calling the getbalance
RPC and try to do a 'sendtoaddress OTHER-ADDR BALANCE' with this
amount, but my transaction will probably be rejected this way. 

Correct.  The client program that some call the Satoshi client, is also called bitcoin-qt.  You also may hear some people refer to it as the standard client.

No it doesn't.  As a matter of fact, it doesn't even list all your addresses that have coins associated with them.  It just gives you a total amount of BTC, and allows you to create simple transactions to send.  If you run it in server mode, you can use command line tools to send specific instructions for various actions, but that certainly isn't very user-friendly.

If you are going to use another wallet program (such as Electrum or Armory), you might just want to send the coins from the old wallet to the new one rather than trying to import the old wallet.dat into the new client.  Of course if your current wallet is made up of a whole bunch of tiny "outputs" that are insufficiently aged, you may have to pay a transaction fee to do so.  I'm not sure about the features of either of those clients, but I don't think either of them give much information about the individual "outputs".
 
If your wallet is made up of a large number of very small, relatively recent, "outputs" (Perhaps from SatoshiDice?) you won't be able to use the bitcoin-qt user interface on the Satoshi client to send them without a fee.  The program has a built in requirement for a fee in that situation no matter what node you are connected to.

I'm not certain, but if you can come by a single large "output", you might be able to include that as an "input" along with several of your smaller "outputs".  This might give you a large enough input total to allow a fee-free transaction?

Example:

You have a wallet made up of 3 outputs of 0.00001 BTC each.  To send them all in a single transaction, they would need an age of approximately 14,400,000 confirmations to avoid a fee (approximately 273 years).

On the other hand, if you receive a transaction with a single output of 575.99997 BTC, and you then try to send the full 576 BTC in a single transaction, you should be able to do so without fees after just one confirmation.

Hi, I was confused about some of this, it kinda put me off slightly tbh as it seems pretty confusing because the client I'm using (bitcoin-qt, which I think is the Satoshi client?) Doesn't really give much info over how aged particular bitcoins are, or even which address has which amount etc...

Is there another wallet program which can use my wallet.dat to give me demo figures, and how do I send transactions without fees as it won't let me, even though I set it to 0 and I tried that addnode thing from the wiki.

This is designed to prevent a very specific type of DDoS attack.  Prior to the creation of this fee requirement, it was possible for a person to set up 2 wallets and write a program to just bounce 0.00000001 BTC back and forth between them as fast as possible.  This would create a huge number of transactions that every bitcoin node would then try to send to every other node.  The effect would make it very difficult for legitimate transactions to get through.  By requiring fees in the described situations, it becomes prohibitively expensive to engage in this sort of DDoS attack, while still making it either free or REALLY CHEAP (a bit more than one half a U.S. cent at current exchange rates) to send most legitimate transactions.

Assuming that these are the only 2 coins in your wallet, then yes, it would generally be true that your 2 BTC transaction would have 2 inputs of 1 BTC each.

It seems you are starting to understand this a bit.  There are some exceptions, but it generally works the way you are describing it.


This is going to depend on how you received those 2 BTC.  Were they both received in a single transaction as a single "output", or were they received as 2 separate transactions each with 1 BTC as an "output"?  It will also depend on how you send them.  Will you send them as a single transaction with 2 "outputs", or will you create 2 separate transactions?

You could have a single transaction that has a total of 2 BTC in its "input" (or "inputs"), and 2 "outputs" of 1 BTC each to a different address.

But consider this example:

You are using the Satoshi client. You receive 2 BTC as a single "output" and have nothing else in your wallet.  You send 1 BTC to a friend with a single transaction.  Then a moment later you attempt to send the remaining 1 BTC to another friend in a separate single transaction.  How many "inputs"/"outputs" are used?

Well first you have the 1 "output of 2 BTC to the address you gave to the person who sent them to you.

Then the program uses that single 2 BTC "output" as an "input" for transaction number 1, creating an "output" of 1 BTC to the address of friend A.
What happens to the remaining 1 BTC from the 2 BTC "input"?  Well, if you did nothing else, the miner that included that transaction in a block would receive the remaining 1 BTC as a transaction fee.  This is how fees work in bitcoin.  You use up as "inputs" a bunch of previously received "outputs" that have a sum that is greater or equal to the amount you want to transfer.  Then you create new "outputs" for each transfer.  If the "inputs" are greater than the "outputs", the miner keeps the difference as a fee.  Since you don't want to pay a 1 BTC fee, what the client does is create a new address that it doesn't bother telling you about, but keeps stored hidden in your wallet.  When it creates the transaction in the first sentence of this paragraph, it creates a second "output" of 1 BTC in the same transaction sending that 1 BTC to the new hidden address in your wallet.

Now when you create transaction number 2, the program uses that single 1 BTC "output" from that new address as an "input", creating an "output" of 1 BTC to the address of friend B.  Note that this is a newly created 1 BTC "output" from the transaction in the previous paragraph.  If you haven't waited approximately a day between the first and second transaction, you will find that your transaction may not be relayed without a small fee.


You generally don't.  If your coins aren't aged sufficiently, the Satoshi wallet program will let you know that a fee is required for the transaction.  If the coins are aged sufficiently, then the program will allow you to create the transaction without a fee if you wish.

Not exactly.  If the coins aren't aged enough, and you are using the Satoshi wallet program, it will generally prevent you from creating a transaction without a fee.  If you choose to use some other program (perhaps one you or a friend have modified?) that allows you to create a transaction with no fee in that situation, then you may find that all the nodes that you connect to refuse to receive or pass along your transaction.

I don't really get it if this limitation is per wallet or per transaction...  but it doesn't matter.  The network is still vulnerable to DDoS attacks, so this whole aging seems to be an unnecessary part.  But I may be wrong because of my limited understanding at this point in time.


I think the key to this is to understand what an "input" is in this case, but I have two ideas about it:

a)  Suppose that I receive 1 BTC, and later another 1 BTC.  Then I want to send 2 BTC to someone.  In this case do I have two inputs, the 1 plus the other 1 BTC I had received?  (And what if I've received 5+1+1 BTC, and want to send 2 BTC?  Then I'll have 1 input if the system cuts out 2 couns from the 5 BTC received before, or I can have 2 inputs if it pairs 1+1 BTC together...)

  or

b)  If I have 2 BTCs, and wanna send 1 BTC to an address, and the other 1 BTC to another address, then these two transactions go into the same block, and they are the two "inputs".  Is this true, or a) was true?  Maybe a third one?

Oh, and how do I know the age of my coins?  Or do I have to care about it at all?  As far as I understand things I can send bitcoins as fast as I want, the only drawback can be that the coins will travel slower to the destination if I send "too young" coins.

The Satoshi client has rules designed to protect the network from Denial of Service attacks.  Most nodes and miners will enforce these rules although they aren't technically a requirement of the protocol.

The input (not to be confused with the amount "spent") of a transaction must have roughly 1 Bitcoin day to avoid being considered low priority.  Low Priority transactions must include a fee or they will be not be relayed or included in blocks by nodes following the rules used in the Satoshi/Reference client.  

So "how long" depends on how large & old your transaction inputs are.  

If we assume you wallet has a single unspent transaction and thus your new transaction will only have a single input:
144 BTC @ 1 confirmation ~= 1 bitcoin day.
12 BTC @ 12 confirmations ~= 1 bitcoin day.
1 BTC @ 144 confirmations ~= 1 bitcoin day.
0.1 BTC @14,400 confirmations ~= 1 bitcoin day.
0.01 BTC @144,00 confirmation ~= 1 bitcoin day.

The exact formula is available in the wiki link above but the rule of thumb of "1 bitcoin day" is generally more practical.

https://en.bitcoin.it/wiki/Transaction_fees
scroll down to Technical info

Thanks for the answers.


Sufficiently aged coins??  That's something totally new for me.  Are you talking about the confirmation that the transfer was real, or it's something else?  How long is this aging process?  Hours?  Days?  Weeks?  Where does it come from?

Unless bitcoin fails and dies, the blockchain will never be "solved".  I believe you are referring to "after the block reward drops to zero".  But keep in mind that long (decades?) before the reward is zero, it will be tiny and no longer act as much of an incentive.  Slowly over time, the money made by miners will be more and more from fees, and less and less from the block reward.

The extra cost of including a transaction in a block is miniscule and not much of a deterrent, so as long as there is room in the block and there aren't enough transactions with fees to fill it, there might always be some miners that will be willing to fill the extra space with free transactions as a service to keep the system healthy.  During times of high transaction volume, the block may become full with transactions that paid a fee.  This could cause "free" transaction to be ignored until the transaction volume drops off a bit, creating a long delay (hours? days? weeks?) before the free transactions will be included.

I suppose that it is possible that bitcoin could become so popular that the transaction volume is always high.  In that case there could be a bidding war, increasing the size of the fees until it becomes enough of a deterrent to reduce the number of transactions.  At that time the market will determine the appropriate fee size.

Lots of questions here:

The protocol itself doesn't require any transaction fees.  However, most of the client programs running out there, and most of the miners will not relay or add transactions to a block if they both look spammy and don't meet a minimum fee.

It depends.  On simple transactions where the coins used haven't been just recently received, and the transaction doesn't use a large number of tiny inputs, if you are willing to be patient for the transaction to eventually be included in a block, then there is no required transaction fee right now.  On transactions that use a large number of tiny inputs or transactions for very small amounts using coins that have just been received, it can be very difficult to get the transaction included in a block without a fee.

The sender pays the fee, although I suppose the sender and receiver could come to an agreement reducing the total amount that the receiver will receive to offset the cost of the fee.

I may be wrong here, and if I am I hope someone more knowledgeable than me will stop by and correct me, but I believe that if you are using a sufficiently aged coin, you should currently be able to send 0.00000001 BTC without any transaction fee.

If it arrives, then you can spend it.  Depending on the client you use, you may need to wait for some confirmations.  Depending on the size of the coin, you may also need to wait  for it to age before you can easily send it without a fee.

They go to the miner that includes the transaction in a block.  Right now if the transaction is included in a block created by a mining pool most of the mining pools keep these fees for themselves (not sharing them with the mining participants in the pool).  In the future as the block reward gets smaller, it is likely that the pools will have to begin sharing them with the participants.

Transaction fees go to miners. They are not presently mandatory, but if you want a small transaction to go through quickly, you have to pay a small fee.

After the bitchain is solved (130 years or so lol), miners will make 100% of profits from transaction fees. So the common idea/bitcoin sales pitch that bitcoin transfers are free and instant is not completely true. There is a cost to having a transaction processed, and those who do the processing (miners), rightfully expect to earn a profit.

Yes the profits are smaller than fiat financial institutions charge for (most) transactions, but BTC transactions do have to be paid for in the long run. so they are not totally free.

Someone more intelligent and with more information than me can speculate as to the potential specific situations that could arise in the future with transaction fees.

From the Bitcoin wiki:


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

Hi,

I've found contradictory information about BitCoin transaction fees. Sometimes
I can read that there are no fees at all. Others say that there are fees, and
there will be slightly higher fees later (mainly to compensate miners because
of the increasing difficulty).  What is the truth?  Is there transaction fee or
there isn't?  If there is, who pays, the sender or the receiver?  What is the
smallest amount of BTC that I can transfer?  If it arrives to a new (and empty)
wallet, can I send it, or I can't because of the transaction fees?  Where do
transaction fees go to?  I'm sure they cannot just disappear from the limited
(21 million BTC) system...