Bitcoin Forum
November 06, 2024, 08:16:29 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Transaction Fees: How do I know the "transaction size" of a Bitcoin Payment?  (Read 5065 times)
nearmint (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile
February 25, 2014, 12:47:45 AM
 #1

According to my source quoted below, Bitcoin Payments may be subject to transaction fees.

Here are my questions:
1. How can I know the size of a transaction in bytes? How is the transaction size calculated? Is the only way to increase the transaction size by adding more recipients of coin? I.e. sending coins to multiple wallets in a single transaction?

2. According to the article, outputs that are lower than 0.01 BTC, might incur a transaction fee. -> let's assume 0.01 BTC is worth 4€; then I cannot make Micropayments of less than 1€ with Bitcoin without having a payment fee??? Is this correct?

3. According to the article, a payment fee would simply be a motivation for bitcoin miners to include my transaction in the next generated block. Does this mean I can "choose to pay the fee"? And if I don't the transaction might not be "immediate", because of lack of motivation for the bitcoin miner?



Please help me to grasp this more clearly Smiley Thanks!



Quote
A transaction may be safely sent without fees if these conditions are met:

    It is smaller than 1,000 bytes.
    All outputs are 0.01 BTC or larger.
    Its priority is large enough (see the Technical Info section below)

Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).

Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.

Source: https://en.bitcoin.it/wiki/Transaction_fees
DannyHamilton
Legendary
*
Offline Offline

Activity: 3472
Merit: 4801



View Profile
February 25, 2014, 02:13:04 AM
 #2

According to my source quoted below, Bitcoin Payments may be subject to transaction fees.

Here are my questions:
1. How can I know the size of a transaction in bytes?

It is typically calculated for you by your bitcoin wallet.

How is the transaction size calculated?

By adding up all the bytes necessary to create the transaction.

Is the only way to increase the transaction size by adding more recipients of coin? I.e. sending coins to multiple wallets in a single transaction?

No.  Transaction size is also increased by receiving multiple small values of bitcoins that must then be spent together as inputs to a transaction.

2. According to the article, outputs that are lower than 0.01 BTC, might incur a transaction fee. -> let's assume 0.01 BTC is worth 4€; then I cannot make Micropayments of less than 1€ with Bitcoin without having a payment fee??? Is this correct?

I don't understand your logic.

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

If you want your transaction to be confirmed quickly you should consider including a fee of at least 0.0001 BTC with every transaction, even if the outputs are larger than 0.01 BTC.  Otherwise there is potential for it to take a few days for the transaction to confirm.


3. According to the article, a payment fee would simply be a motivation for bitcoin miners to include my transaction in the next generated block. Does this mean I can "choose to pay the fee"? And if I don't the transaction might not be "immediate", because of lack of motivation for the bitcoin miner?

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.


The information below is outdated.  There are new rules for transaction fees in the more recent versions of the reference client.

Quote
A transaction may be safely sent without fees if these conditions are met:

    It is smaller than 1,000 bytes.
    All outputs are 0.01 BTC or larger.
    Its priority is large enough (see the Technical Info section below)

Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).

Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.

Source: https://en.bitcoin.it/wiki/Transaction_fees
bitGun
Newbie
*
Offline Offline

Activity: 38
Merit: 0


View Profile
February 25, 2014, 03:06:28 AM
 #3

it‘s strange that for the same amount of transactions, sometimes it ask me to pay a fee, but sometimes it can be sent for zero fees, who can explain that?
Mein Coin LLC
Newbie
*
Offline Offline

Activity: 24
Merit: 0


View Profile
February 25, 2014, 06:45:17 AM
 #4

If you want to "push" your transaction through.  It makes the transaction happen faster.
nearmint (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile
February 25, 2014, 09:25:43 AM
 #5

Hello DanielHamilton,
thanks for your answer!

Quote

I don't understand your logic.

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

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

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? 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? Will it recommend me to pay a transaction fee for small amounts? Or how is this done. And how is this done in automatic scripts? Does one usually define that payments lower than 0.01 BTC are subject to transaction fee of 0.0001? 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?
DannyHamilton
Legendary
*
Offline Offline

Activity: 3472
Merit: 4801



View Profile
February 25, 2014, 03:18:47 PM
 #6

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.


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 Smiley. 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.
nearmint (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile
February 25, 2014, 09:37:13 PM
Last edit: February 25, 2014, 09:53:48 PM by nearmint
 #7

Thanks again for the time you took to answer my questions!!

Unfortunately, I don't quite understand this last part of your reply yet. Is defining inputs = ALL previously received outputs to a certain wallet?) From what I understand, if we have to calculate the sum of all inputs (=all btc ownership values that were transferred to the wallet?) minus the sum of all outputs (=all btc ownership values that were transferred away from the wallet), then the transaction fee can only be calculated after the transaction has taken place. But that can't be right :-), so I guess it will get more clear to me, once I've finished the whitepaper.

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


By the way,.. starting to read Satoshi's whitepaper..the first question that pops to my mind is in regards to the Timestamp Server.
Won't the transaction size increase, depending on how many Timestamps have been added to the chain? Wouldn't this mean at one point, every transaction will be subject to higher and higher transaction fees, simply because the timestamp chain is getting larger and larger?
Quote
Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing the ones before it

Is the following true?
1. Miners' nodes are needed to confirm transactions
2. At one point, all Bitcoins are mined
3. So at some point, miners need to make money just by confirming transactions, because they can't mine Bitcoins anymore.
4. The process of confirming transactions increases in difficulty depending on amount of transfers of the bitcoin-ownership (therefore the difficulty just increases, it's not self-regulated), as opposed to the difficulty to mine Bitcoin, which increases in difficulty depending on how much total CPU power is trying to mine the Coins at a given point (self-regulated: less cpu power mining >easier mining for the remaining clients)


DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 25, 2014, 09:45:00 PM
Last edit: February 25, 2014, 10:09:09 PM by DeathAndTaxes
 #8

In a transaction each input is the unspent output of a prior transaction.  Only the outputs being spent are defined in the transaction.  The number of outputs in the wallet doesn't matter.  If you received the following outputs 1 BTC, 0.1 BTC, 0.2 BTC, 0.05 BTC, 0.01 BTC and you were creating a tx which spends 0.25 BTC the wallet/client might pick the 0.2 BTC and 0.05 BTC.  Those would be the only inputs in the transaction.  The others would remain unspent to be used in future transactions.

The timestamps that Satoshi refers to on a meta level are the blocks in the network.  Transactions are placed in blocks, blocks reference other blocks to form a chain.  This doesn't increase the size of a transaction.
DannyHamilton
Legendary
*
Offline Offline

Activity: 3472
Merit: 4801



View Profile
February 25, 2014, 10:17:42 PM
 #9

Unfortunately, I don't quite understand this last part of your reply yet. Is defining inputs = ALL previously received outputs to a certain wallet?) From what I understand, if we have to calculate the sum of all inputs (=all btc ownership values that were transferred to the wallet?) minus the sum of all outputs (=all btc ownership values that were transferred away from the wallet), then the transaction fee can only be calculated after the transaction has taken place.

A wallet contains only the private keys that are necessary to sign transactions.  There are no "Bitcoins" in a wallet.  The wallet uses the private keys to calculate the associated bitcoin addresses (each private key has one and only one bitcoin address that it is mathematically linked to).  The wallet then uses the addresses to search through the entire blockchain for every transaction that pays an output to that address.  Some of those outputs will already have been spent in other transactions.  The wallet sums up all the unspent outputs and displays this as a total for you.  The outputs remain in the blockchain, still unspent until you actually spend them.

When you create a transaction, your wallet chooses one or more of the unspent outputs in the blockchain that are associated with an address that the wallet has the private key for.  The wallet chooses enough inputs to make sure that the total value being provided to the transaction is at least as much as the total value of the outputs that you told the wallet you wanted to create.

Listing an input in a transaction involves providing reference information about where in the blockchain to find that unspent output as well as an ECDSA digital signature using the private key proving that the spender is authorized to spend that output.  There is some additional overhead for each input as well. All together this requires approximately 180 bytes.

Listing an output in a transaction involves providing the RIPEMD-160 hash that is associated with the bitcoin address, and a total value being sent to that address. There is some additional overhead for each output as well. All together this requires approximately 40 bytes.

There transaction itself has some overhead indicating the quantity of inputs, quantity of outputs, and a few other useful pieces of information.

So, the wallet first determines how much value the sum of the outputs is.  Then it finds enough unspent inputs to gather together to provide the necessary value to the transaction.  It is rare for the exact amount needed to be available from a combination of inputs, so this will generally result in providing too much value to the transaction.  The wallet then creates one additional output to send the "change" back to an address in the wallet.  At this point the wallet knows exactly how big the inputs and outputs are.  It can calculate the appropriate fee, and adjust the value of the "change" to make sure there is enough value left over unaccounted for to provide an appropriate fee.  Then the transaction inputs are all signed and the transaction is broadcast.

By the way,.. starting to read Satoshi's whitepaper..the first question that pops to my mind is in regards to the Timestamp Server.

As has been pointed out, since Bitcoin is decentralized, there is no single "timestamp server" instead Bitcoin needs a decentralized way to indicate the order that transactions occur.  The blockchain provides this functionality.  By packaging transactions into blocks and making it possible to discern the order of those blocks, it is now possible to state that a particular transaction "occurs" either before or after another transaction.

Won't the transaction size increase, depending on how many Timestamps have been added to the chain?

Not transaction size.  Each transaction provides a reference into the blockchain to indicate which previous unspent transaction output is being spent.  This reference is the same size regardless of the size of the blockchain.  The size of the blockchain on the other hand does increase forever.  It grows in size by one block approximately every 10 minutes.

Wouldn't this mean at one point, every transaction will be subject to higher and higher transaction fees, simply because the timestamp chain is getting larger and larger?

See above.  Transaction doesn't get bigger.  The reference used doesn't change in size as the blockchain gets bigger.

Is the following true?
1. Miners' nodes are needed to confirm transactions

Yes this is the purpose of mining.  In exchange the miner that solves the block is rewarded with the sum of all the transaction fees of all the transactions they include in the block (giving them an incentive to actually include the transactions) as well as the current block subsidy (newly created bitcoins).  The current subsidy is 25 BTC.  The subsidy is cut in half every 210,000 blocks (approximately every 4 years).

2. At one point, all Bitcoins are mined

Yes.  Since the subsidy is an integer, and is cut in half every 210,000 blocks, eventually the subsidy will be 0 BTC.

3. So at some point, miners need to make money just by confirming transactions, because they can't mine Bitcoins anymore.

Correct.  As the subsidy shrinks and bitcoin gains popularity, eventually the total transaction fees in a block will exceed the block subsidy.  The subsidy will continue to shrink and eventually the entire mining revenue will be from transaction fees.

4. The process of confirming transactions increases in difficulty depending on amount of transaction (not self-regulated!) // The difficulty to mine Bitcoin increases in difficulty depending on how many nodes are trying to mine the Coins (self-regulated! less miners>easier mining)

The target hash that a miner must find to satisfy the proof-of-work is self-regulated by the protocol.  It is adjusted to attempt to keep the rate of solved blocks as close to 2016 blocks every 705,600 seconds.  The adjustment occurs every 2016 blocks.

If the 2,016 blocks were solved faster than 705,600 seconds, then the protocol requires a new difficulty target that is proportionally more difficult to achieve.  This results in the average time between blocks increasing.

If the 2,016 blocks were solved slower than 705,600 seconds, then the protocol requires a new difficulty target that is proportionally less difficult to achieve.  This results in the average time between blocks decreasing.

The difficulty is not related to the amount of transctions at all.  It is entirely based on the speed at which blocks are being solved.

Additional hashing power from miners decreases the amount of time that it takes to find a low enough hash to satisfy the difficulty (it is faster/easier to roll a 1 if you roll 15 dice all at once than it is if you are only rolling 2 dice at a time).  This speeds up block solving and triggers a difficulty adjustment when the next 2,016 block trigger is encountered.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!