Re: Transaction Fees: How do I know the "transaction size" of a Bitcoin Payment?
The forced transaction fee rules are in the process of changing. What we are currently discussing is how it works for wallets or nodes that enforce the old rules. The most recent reference client has changed the rules a bit, and the next version is expected to change them even more.
Correct, as payments get smaller, the minimum recommended fee takes up a larger percentage of that payment. Whether or not it is "suitable" depends on how large of a fee you consider to be reasonable. A 0.0001 BTC fee on a 0.002 BTC transaction is only a fee of 5%.
Furthermore, a single transaction can pay multiple addresses. The recommended fee is per kilobyte, and each additional output adds less than 40 bytes to the transaction. Therefore you can send a single transaction that uses a single input and pays more than 20 addresses 0.0001 BTC each. The total being sent is 20 X 0.0001 = 0.002 BTC with a single fee of 0.0001 BTC resulting in a transaction fee of only 5% for each output.
Thanks for this valuable information
. So for transaction size, it's always better to receive bitcoin in a larger one-time transaction rather than many more transactions. Because if you want to send the bitcoin away again and the bitcoin, that you are trying to send, came from multiple transactions, the transaction size will get bigger...
As a generall rule yes, but in most cases it doesn't matter much. Each input ads less than 200 bytes to the transaction. So if you receive 4 transactions of 3 BTC each, or you receive 1 transaction of 12 BTC, you can still create a single transaction that pays up to 12 BTC without increasing the fee. It generally only becomes a problem when you are dealing with micro-transactions (which bitcoin is not suited well for).
No, the bitcoins aren't "lost" Either the transaction confirms and the bitcoins belong to the person that controls the receiving address, or it doesn't confirm and the bitcoins still belong to you.
Yes, it should. Although I'm not sure if the latest changes to the fee structure have been included in the latest version of MultiBit yet.
Yes, it should. Although I'm not sure if the latest changes to the fee structure have been included in the latest version of MultiBit yet.
Most automatic scripts make API calls to the reference client. The reference client then makes sure that the appropriate fee is added to the transaction when necessary. It is also possible for a script to build its own transactions using the createrawtransaction API call, but this is very dangerous if you aren't very careful and completely understand what you are doing. Using createrawtransaction, it is possible to create transactions that will never confirm, and it is possible to accidentally pay larger than intended transaction fees.
A better plan is to define that all payments are subject to a transaction fee of at least 0.0001 BTC.
The transaction defines inputs. These are previously received outputs that have not yet been spent. Each input is fully spent adding its entire value to the transaction to be reassigned in the outputs of the transaction.
The transaction defines outputs. Each newly created output assigns some of the total input value to an address.
If the sum of the value of the outputs is larger than the sum of the value of the inputs, then the transaction is invalid and will be rejected by the entire network. Properly working wallets will never create such a transaction.
If the sum of the value of the outputs is equal to the sum of the value of the inputs, then the transaction has no transaction fee.
If the sum of the value of the outputs is less than the sum of the value of the inputs, then the difference between the sum of the value of the inputs and the sum of the value of the outputs is the transaction fee.
I HIGHLY RECOMMEND that you read the Bitcoin Whitepaper written by Satoshi Nakamoto. It is silly to try to understand the details of the bitcoin protocol without having read the original paper that describes the entire design.
Quote
If 0.01 BTC is worth 4, and outputs that are lower than 0.01 BTC, might incur a transaction fee. then you cannot make micropayments of less than 4 with Bitcoin without having a transaction fee of at least 0.0001 BTC (worth about 0.04)
I just wanted to get confirmed, that this "lower than 0.01 BTC incurs a fee of at least 0.0001" is correct, cause that means Bitcoins is not very well suitable for payments up to 4.Correct, as payments get smaller, the minimum recommended fee takes up a larger percentage of that payment. Whether or not it is "suitable" depends on how large of a fee you consider to be reasonable. A 0.0001 BTC fee on a 0.002 BTC transaction is only a fee of 5%.
Furthermore, a single transaction can pay multiple addresses. The recommended fee is per kilobyte, and each additional output adds less than 40 bytes to the transaction. Therefore you can send a single transaction that uses a single input and pays more than 20 addresses 0.0001 BTC each. The total being sent is 20 X 0.0001 = 0.002 BTC with a single fee of 0.0001 BTC resulting in a transaction fee of only 5% for each output.
Quote
No. Transaction size is also increased by receiving multiple small values of bitcoins that must then be spent together as inputs to a transaction.
Thanks for this valuable information
. So for transaction size, it's always better to receive bitcoin in a larger one-time transaction rather than many more transactions. Because if you want to send the bitcoin away again and the bitcoin, that you are trying to send, came from multiple transactions, the transaction size will get bigger...As a generall rule yes, but in most cases it doesn't matter much. Each input ads less than 200 bytes to the transaction. So if you receive 4 transactions of 3 BTC each, or you receive 1 transaction of 12 BTC, you can still create a single transaction that pays up to 12 BTC without increasing the fee. It generally only becomes a problem when you are dealing with micro-transactions (which bitcoin is not suited well for).
Quote
The transaction is still immediate, but the confirmation may take a while (possibly several days). Under some circumstances where the transaction looks like spam or a DDOS attack on the network, many peers may refuse to relay the transaction. In this case your recipient will not see the transaction, and neither will the miners.
This means that it is possible to send Bitcoin to someone else, without him ever noticing that he has received Bitcoins. That means it is actually possible to lose Bitcoins in the sending process, even though the correct Bitcoin address has been named.. right?No, the bitcoins aren't "lost" Either the transaction confirms and the bitcoins belong to the person that controls the receiving address, or it doesn't confirm and the bitcoins still belong to you.
I find that very strange. If I'm using a program such as MultiBit, will it tell me when I should pay a transaction fee?
Yes, it should. Although I'm not sure if the latest changes to the fee structure have been included in the latest version of MultiBit yet.
Will it recommend me to pay a transaction fee for small amounts?
Yes, it should. Although I'm not sure if the latest changes to the fee structure have been included in the latest version of MultiBit yet.
Or how is this done. And how is this done in automatic scripts?
Most automatic scripts make API calls to the reference client. The reference client then makes sure that the appropriate fee is added to the transaction when necessary. It is also possible for a script to build its own transactions using the createrawtransaction API call, but this is very dangerous if you aren't very careful and completely understand what you are doing. Using createrawtransaction, it is possible to create transactions that will never confirm, and it is possible to accidentally pay larger than intended transaction fees.
Does one usually define that payments lower than 0.01 BTC are subject to transaction fee of 0.0001?
A better plan is to define that all payments are subject to a transaction fee of at least 0.0001 BTC.
And how do you define in a transaction what part of the transaction is designated as transaction fee and what part of the transaction is for the actual receiver?
The transaction defines inputs. These are previously received outputs that have not yet been spent. Each input is fully spent adding its entire value to the transaction to be reassigned in the outputs of the transaction.
The transaction defines outputs. Each newly created output assigns some of the total input value to an address.
If the sum of the value of the outputs is larger than the sum of the value of the inputs, then the transaction is invalid and will be rejected by the entire network. Properly working wallets will never create such a transaction.
If the sum of the value of the outputs is equal to the sum of the value of the inputs, then the transaction has no transaction fee.
If the sum of the value of the outputs is less than the sum of the value of the inputs, then the difference between the sum of the value of the inputs and the sum of the value of the outputs is the transaction fee.
I HIGHLY RECOMMEND that you read the Bitcoin Whitepaper written by Satoshi Nakamoto. It is silly to try to understand the details of the bitcoin protocol without having read the original paper that describes the entire design.