Bitcoin: Transaction with Multiple Inputs – Example

  • There exists a fact about Bitcoin, which states that each received output can only be claimed by one input.
  • Some people might infer from that – that each transaction could only have one input.

But in reality, the second assumption does not follow from the first. If it did, then the inputs and outputs would perpetually have to become smaller, and in addition, it would be possible to prove that any Bitcoin-amount originated, literally, from one Bitcoin.

In reality, a transaction is possible which has multiple inputs, and two outputs. Each of its inputs has uniquely claimed a received output – without contradicting the first premise above.

(Edit 07/13/2017 : Therefore, none of those outputs can be used again. )

Now, one way I could try to prove this, would be to put together a transaction in my own wallet-program, which clearly displays the inputs-list, as well as the outputs-list, and then to take a screen-shot. But there would be two problems with that sort of ~proof~ :

  1. Somebody could think, that this is just a high-level, GUI operation, which my wallet-software is breaking down into smaller raw-data-operations.
  2. Showing such a screen-shot would also reveal (x+2) of my public keys, where (x) would be the number of inputs I have dialed up, just to take my screen-shot.

But, there is no real need for me to use my own transactions. I can just link to a transaction on ‘’, which belonged to ‘some other person’, who received 31 inputs in one transaction, yielded one main output, and yielded one change-address-output (for them). This transaction has one ‘Tx ID':

Therefore, this is one transaction, at the raw, data-level. It just happens to be atypical.



Print Friendly, PDF & Email

5 thoughts on “Bitcoin: Transaction with Multiple Inputs – Example”

    1. First of all, nobody on my blog ever said you were dumb.

      Secondly, in order to do something like that, one needs to have a Bitcoin wallet. The following example would work:

      As would this one:

      But those are not the only examples of a working Bitcoin wallet.

      Additionally, the user needs to have received multiple payments – i.e., inputs – to his or her wallet. Then, that user just needs to make a single large payment, the total amount of which does not exceed the balance of the wallet. The wallet program takes care of the rest.

      As I wrote, a single transaction may have more than one output. Two is typical because one output will state how much the actual amount is, while the second output would be change.

      Now, the question has been asked, how the user can reduce the amount of transaction fees, when ‘dusting’ his wallet for many small inputs. But the available answers to that question have become less numerous over the years. It was once true that a user could just copy and paste a non-committed Bitcoin transaction (from the PC’s wallet app) to a mining pool’s Web-site. And a mining pool which once allowed that was called ‘Eligius’. But this opportunity may have become much rarer in recent years. Eligius has become inactive over the years. The user would need to wait next, until that mining pool has mined the transaction. Another possibility would be, just to state one of your own Receiving Addresses, and to make a single large payment to it, and state that one wants to pay a smaller fee.

      This last option might be a bit precarious because the wallet program will wait, with the inputs tied up, until the transaction completes. Therefore, if consolidating many transactions like that, it’s best if the wallet program has a “Coin Control” feature, which allows the user to specify which inputs to use, to make the transaction. That way, only the inputs specified will be tied up until the transaction completes.

      Alternatively, the user can “Freeze” all the inputs which have larger amounts on them, so that such a consolidation will only tie up the (unfrozen) receiving inputs, which that user wanted to consolidate from.

      And then the idea is to wait, until the transaction is mined, despite having specified a low fee. This could take a while. There is no guarantee how long this will take.

      To start with, the user would need to have received actual Bitcoin amounts to his wallet, to dust in that way. Because Bitcoins are actually money, that part may not be easy. This could happen if the small amounts were received from many buyers, or, for example, if the user had posted a Bitcoin address on the Web, which any visitor could have donated amounts to. But this latter practice could have legal / tax implications in some countries…

      The fee in the cited example was “0.003 BTC”.


    2. There’s an alternative way, that doesn’t involve Freezing specific Receiving Addresses, and that may apply the best if there are many Inputs to a single Receiving Address. Technically, one Input is defined by a combination of Transaction ID, and Receiving Address. Well in my “Electrum Wallet”, if I right-click on a Receiving Address that has a remaining, non-zero balance, I can next Left-Click on “Spend From”… In the Window which opens, I’m allowed to spend an amount smaller than what was present as my balance. Presumably, this just sweeps the one address and causes a Change Address to receive payment, in addition to my designated address…

      If it was not possible to have a non-zero balance on the same Receiving Address again afterwards, then the practice of making a Bitcoin Address publicly visible, let’s say in order to receive small donations, would stop working, as soon as the recipient has consolidated the existing Inputs to that address.

      But, reusing the same Receiving Address numerous times in this way, is considered to be bad practice. At the very least, after (or just before) the Inputs to an existing address have been consolidated, what its owner should do is remove it from view, so that future donations will be made to a new Receiving Address.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>