Say I want to get lots of small bitcoin deposits and sell them off soon thereafter. Say I get bitcoin in $5 chunks. If I take the standard advice and never reuse an address, I have to pay a transaction fee every time I sell one of those chunks. As of this writing, the average fee is over $2. This puts the overall fee for this endeavor at 40%. On the other hand, it seems like I could collect all of the deposits in one address and sell when I've reached some acceptable threshold, say $100. It seems like this would cost me a mere 2%.

On the other hand, I have read the following at https://en.bitcoin.it/wiki/Address_reuse#High_Fees

A single invoice payment using P2PKH can be redeemed and spent with a predictable fee because the transaction should have a predictable size. Software that determines payment and available funds based on "address balance" can cause loss through high fees. If you are paid to an address in many small increments, you will pay a much higher transaction fee when redeeming those payments. It is much more useful for a client to display transaction outputs spendable than address balances for this reason.

My understanding was that transaction fees are per byte, and that my transaction would be a standard sized one of the form "MyAddress is sending x many Satoshi to YourAddress". Why would I have to pay more?

  • en.bitcoin.it/wiki/Transaction#Input says "An input is a reference to an output from a previous transaction", as opposed to an address. To quote Al Gore "while I strongly disagree with the court's decision, I accept it". It feels like if bitcoin paid from addresses rather than outputs, you could significantly reduce the size of blocks in the way I described. It would be interesting to understand that design decision. Aug 16, 2017 at 19:24

1 Answer 1


When you have an address with multiple inputs (you have sent bitcoin to the same address multiple times) and you want to send all of those bitcoins to another address, all of those inputs must be included in the transaction, and recording each input takes up space. If you have only sent bitcoin to an address once, it only has one input, therefore the transaction only needs to contain one input, which takes up less space.

  • I think my original description wasn't clear. Say 11 different people send me bitcoin and eventually I sell it all. In scenario A, where I use a different receiving address for each of the 11 incoming transactions, the people giving me the money each pay something like a $2 transaction fee, and I have to pay something like $22 to sell the bitcoin, since it will take 11 transaction to do it. Scenario B : I give everyone the same public address and when I sell, I generate a normal sized transaction (if not, why not?) and only pay $2. Aug 16, 2017 at 14:24
  • What matters is that you're sending coins received through multiple independent payments. Whether those payments are all to the same address or not is irrelevant. Aug 16, 2017 at 17:34
  • @PieterWuille Why? Presumably that is because I have to list the inputs to the address when I make the payment. But isn't that information already encoded in the blockchain? Is there a reference that I could look at? Aug 16, 2017 at 18:15
  • Yes, Bitcoin transactions spends have to refer to the transaction output that created them. More outputs to refer to = more bytes = more fee. Aug 16, 2017 at 18:20
  • I believe you. Can you help me understand WHY the transaction has to refer to the previous transactions that created it? There is probably some fundamental misunderstanding in the following sentence, what is it : "at a given point in time, a Bitcoin address holds a certain amount of value, and that value can be calculated using the blockchain by adding the total value of transactions into the address and subtracting the total value of transactions out of the address". If that's right, why list all the inputs to an address when you are paying from it, given that they are on the block chain? Aug 16, 2017 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.