Basically, one or a few number of inputs should make no real difference. But at some point the size of the transaction may grow so big that it will start to get less priority over other ones, because miners may prefer lower-sized transaction to get more transactions fees (assuming they would hit regularly the block size limit).

Anyway the workaround you propose is pointless, moving bitcoins separately from several addresses to one unique address prior of the real transaction would cost you even more. The total size of all the transactions you need for that would exceed the size of a unique direct transaction with several inputs.

BTW, notice that the virtual balance your client shows for each of your “accounts” may not reflect the real repartition as seen by the network for each associated address. (It costs nothing to move virtual amount from one account from the other, but it will also not change the way transactions will be build later by the client).

Basically, one or a few number of inputs should make no real difference. But at some point the size of the transaction may grow so big that it will start to get less priority over other ones, because miners may prefer lower-sized transactions to get more transactions fees (assuming they would hit regularly the block size limit).

Anyway the workaround you propose is pointless, moving bitcoins separately from several addresses to one unique address prior of the real transaction would cost you even more. The total size of all the transactions you need for that would exceed the size of a unique direct transaction with several inputs.

BTW, notice that the virtual balance your client shows for each of your “accounts” may not reflect the real repartition as seen by the network for each associated address. (It costs nothing to move virtual amount from one account to the other, but it will also not change the way transactions will be build later by the client).

Basically, one or a few number of inputs should make no real difference. But at some point the size of the transaction may grow so big that it will start to get less priority over other ones, because miners may prefer lower-sized transaction to get more transactions fees (assuming they would hit regularly the block size limit).

Anyway the workaround you propose is pointless, moving bitcoins separately from several addresses to one unique address prior of the real transaction would cost you even more. The total size of all the transactions you need for that would exceed the size of a unique direct transaction with several inputs.

Basically, one or a few number of inputs should make no real difference. But at some point the size of the transaction may grow so big that it will start to get less priority over other ones, because miners may prefer lower-sized transaction to get more transactions fees (assuming they would hit regularly the block size limit).

Anyway the workaround you propose is pointless, moving bitcoins separately from several addresses to one unique address prior of the real transaction would cost you even more. The total size of all the transactions you need for that would exceed the size of a unique direct transaction with several inputs.

BTW, notice that the virtual balance your client shows for each of your “accounts” may not reflect the real repartition as seen by the network for each associated address. (It costs nothing to move virtual amount from one account from the other, but it will also not change the way transactions will be build later by the client).