<p>No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size.</p>
<p>If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff. There's really no constraints on what a varint can represent. A transaction with such a number of inputs would not fit in a block, nor would it fit on any existing single storage medium as that transaction would be at least 664.1 Exabytes in size.</p>
<p>The maximum number of inputs that can fit in a valid transaction is 24386.</p>
<p>Such a transaction would not use segwit, so we use the maximum block size without segwit of 1000000 bytes. Subtract the 146 for the header and coinbase transaction to get 999854 bytes for the transaction. Subtract 4 bytes for the version, 4 bytes for the locktime, 1 byte for output count, 8 bytes for output value, 1 byte for output script, and 3 bytes for input count. This leaves us with 999833 bytes. With 41 bytes per input (32 previous txid, 4 output index, and 1 for script length, 4 for sequence number), there can be 24386 inputs.</p>

CC BY-SA 4.0
2019-04-02T06:11:56.287Z
To note, that includes zero security or signatures.
Claris
CC BY-SA 4.0
2019-05-21T08:18:36.380Z
`and 2 bytes for input count` correction: it is 3 bytes because 27022 inputs in `CompactInt` is equal to `fd8e69` (it needs an initial `0xfd` to indicate 2 bytes follow up)
Coding Enthusiast
CC BY-SA 4.0
2019-05-21T16:26:21.103Z
@Anonymous What do you mean by "includes zero security"?
Jonathan Cross
CC BY-SA 4.0
2019-05-21T17:09:48.470Z
Without signatures, all transaction in the block described here can be spent by anybody else. Including signatures reduces the number of inputs considerably.
Claris
CC BY-SA 4.0
2020-07-22T17:46:39.580Z
@Andrew: inputs also have `nSequence`, raising the minimum size of an input to 41.
Pieter Wuille
CC BY-SA 4.0
2020-07-22T18:46:23.520Z
Oops. I've updated the calculation.
Ava Chow
CC BY-SA 4.0
2019-04-02T05:19:25.223Z
2020-07-22T18:45:21.507Z
2020-07-22T18:45:21.507Z
Ava Chow
<p>In theory, what is the maximum number of inputs per transaction? Is it defined primarily by the maximum number we can store on the 9 byte varint? </p>

<p>How big of a number can be stored on 9 bytes?</p>

<p>Would such a transaction even fit in a block if it had just 1 output?</p>

<transactions><transaction-input><input>
Maximum number of inputs per transaction
Pedro
# Maximum number of inputs per transaction

(Asked by: username_0 on 2019-04-02)

In theory, what is the maximum number of inputs per transaction? Is it defined primarily by the maximum number we can store on the 9 byte varint?

How big of a number can be stored on 9 bytes?

Would such a transaction even fit in a block if it had just 1 output?

**Tags:** transactions, transaction-input, input


---

## 1 answers

### Answer by username_1 on 2019-04-02. Score: 8 | Accepted answer

No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size.

If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff. There's really no constraints on what a varint can represent. A transaction with such a number of inputs would not fit in a block, nor would it fit on any existing single storage medium as that transaction would be at least 664.1 Exabytes in size.

The maximum number of inputs that can fit in a valid transaction is 24386.

Such a transaction would not use segwit, so we use the maximum block size without segwit of 1000000 bytes. Subtract the 146 for the header and coinbase transaction to get 999854 bytes for the transaction. Subtract 4 bytes for the version, 4 bytes for the locktime, 1 byte for output count, 8 bytes for output value, 1 byte for output script, and 3 bytes for input count. This leaves us with 999833 bytes. With 41 bytes per input (32 previous txid, 4 output index, and 1 for script length, 4 for sequence number), there can be 24386 inputs.

> **Comments:**
> **username_2**: To note, that includes zero security or signatures.  
> **username_3**: `and 2 bytes for input count` correction: it is 3 bytes because 27022 inputs in `CompactInt` is equal to `fd8e69` (it needs an initial `0xfd` to indicate 2 bytes follow up)  
> **username_4**: @Anonymous What do you mean by "includes zero security"?  
> **username_2**: Without signatures, all transaction in the block described here can be spent by anybody else. Including signatures reduces the number of inputs considerably.  
> **username_5**: @Andrew: inputs also have `nSequence`, raising the minimum size of an input to 41.  
> **username_1**: Oops. I've updated the calculation.  

---

