<p>The total size of the transaction must be less than 100,000 bytes or it will not be relayed across the network or included in blocks.</p>

<p>There COULD be a miner that is mining >100K transactions, but I don't think there is; if there is such a miner or you mine the transaction yourself then the limit would be the 1,000,000 byte blocksize limit.</p>

CC BY-SA 3.0
2018-02-08T13:04:17.637Z
This was true previously however, BIP141 has changed things when it was activated. See this question: [What is the current maximum Bitcoin block size in MB?](https://bitcoin.stackexchange.com/questions/69468/what-is-the-current-maximum-bitcoin-block-size-in-mb)
Willtech
CC BY-SA 3.0
2015-01-17T22:10:02.380Z
2015-01-17T22:10:02.380Z
gavinandresen
<p>These numbers are slightly different today after the segwit and taproot softforks got activated.</p>
<p>A standard transaction is limited to 400 000 weight units (WU). The smallest standard (single-sig payment¹) input is a P2TR keypath input with <a href="https://bitcoin.stackexchange.com/q/111395/5406">230 WU</a>. The <a href="https://bitcoin.stackexchange.com/q/111395/5406">smallest standard (payment²) output</a> is P2WPKH with 124 WU.</p>
<p>The header of a segwit transaction <a href="https://bitcoin.stackexchange.com/q/84004/5406">takes at least 42 WU</a>. For transactions with large input or output counts, the <a href="https://bitcoin.stackexchange.com/a/114585/5406">counter will increase</a> from 1 byte to 3 bytes when we have more than 252 inputs or outputs. This means that for the below transactions the header bytes will weigh 50 WU, leaving 399 950 WU for inputs and outputs.</p>
<p>Therefore, a standard transaction with one P2TR input (230 WU) could have <strong>3223 P2WPKH outputs</strong> (3223 × 124 WU = 399 652 WU) (and could optionally add one OP_RETURN output (40 WU+) for a total of 3224 outputs).</p>
<p>A standard transaction with one P2WPKH output (124 WU) can have <strong>1738 P2TR keypath inputs</strong> (1738 × 230 WU = 399 740 WU).</p>
<hr />
<p><sub>¹ A P2WSH input with an <code>OP_TRUE</code> witness script would be smaller and considered standard (H/T @instagibbs), but I’m sticking to commonly used script types based on a single signature for this answer.</sub><br />
<sub>² OP_RETURN outputs can be smaller (H/T Pieter Wuille), but you are only permitted a single OP_RETURN output in a standard transaction.</sub></p>

CC BY-SA 4.0
2023-05-25T02:45:14.537Z
2024-02-09T07:36:44.360Z
2024-02-09T07:36:44.360Z
Murch
<p>The economical way in your case would be to pay off (create as much outputs) as you can to decrease the fee cost. </p>

<p>Some standard transaction with one proven input and one output is about 161 - 250 bytes. <a href="https://en.bitcoin.it/wiki/Maximum_transaction_rate" rel="nofollow">see reference</a> some est. basic values:</p>

<ul>
<li>10 bytes for transaction header</li>
<li>50 bytes for previous transaction reference
<ul>
<li>9 bytes for header</li>
</ul></li>
<li>50 for output (depending on script size) </li>
</ul>

<p>The standard requirement (for miners to include your tx) is to pay 0.0001 BTC per 1000 bytes.</p>

<p>If your transaction is larger than 100 kB theoretical limit could be that your transaction is non-standard which means it fails the test IsStandard() for including the tx into the block because it is too large.</p>

<p>Nevertheless, it is possible to include even non-standard transaction into the block. This is being done by several mining pools but usually requires slightly higher fee.</p>

<p>So I estimate you can create transaction with up to 1900 outputs paying just 0.02 BTC fee and having transaction most probably verified in the upcoming block.</p>

<p>Please note that I have not tried this myself it is just my assumption. </p>

CC BY-SA 3.0
2015-01-18T19:25:39.360Z
I appreciate your input here. 0.02 is actually quite a high fee considering the small nature of the transactions I make. Furthermore I do not require that the transaction is processed promptly. Due it being a faucet I'm not bothered how long the transaction takes to confirm. In this instance what do you think would be a suitable number of addresses to include for a fee closer to 1 mBTC or similar?
cainy393
CC BY-SA 3.0
2015-01-19T22:58:07.960Z
@cainy393 Yes, you can have the fee as low as a 0.00001 BTC but it will take ages to get confirmed. I advice you to make some research on this - try to relay some low fee txs.
Marek
CC BY-SA 3.0
2015-02-16T17:54:38.513Z
Since I was using the blockchain.info API I just set the transaction fee to normal and let it select a reasonable one, which almost always seems to end up being 0.1 mBTC as per usual.

I found that much more than 100 transactions at a time became a problem due to the fact that I was making a GET request to the API and I think the url was too long.
cainy393
CC BY-SA 3.0
2015-01-17T22:20:30.833Z
2015-01-17T22:29:29.137Z
2015-01-17T22:29:29.137Z
Marek
<p><strong>The maximum theoretically possible number of outputs in a transaction is 111105</strong></p>
<p>To achieve the theoretical maximum, the transaction must be a coinbase transaction with non-output fields minimised (so that the ~whole block can be dedicated to outputs).</p>
<p>A formula for the possible number of outputs, <code>N</code>, in that case:</p>
<pre><code>Block_size_limit_bytes = Transaction_fields_bytes + N*output_size_bytes
N = ⌊ (Block_size_limit_bytes - Transaction_fields_bytes) / output_size_bytes ⌋
</code></pre>
<p>(<code>⌊x⌋</code> means round x down to nearest integer)</p>
<p><strong>For P2PKH:</strong></p>
<pre><code>Transaction_fields_bytes: 47 bytes (ignoring BIP34)
output_size_bytes:  25 + 9 = 34 bytes

N = ⌊ (1000000 - 47) / 34 ⌋
N = 29410
</code></pre>
<p>Maximum number of P2PKH outputs is 29410</p>
<p><strong>For P2WPKH:</strong></p>
<pre><code>Transaction_fields_bytes: 47 bytes (note no witness field required as no Segwit inputs)
output_size_bytes:  22 + 9 = 31 bytes

N = ⌊ (1000000 - 47) / 31 ⌋
N = 32256
</code></pre>
<p>Maximum number of P2WPKH outputs is 32256</p>
<p><strong>For AnyoneCanSpend:</strong></p>
<pre><code>Transaction_fields_bytes: 49 bytes (additional 2 bytes as no outputs&gt;2**16)
output_size_bytes:  0 + 9 = 9 bytes

N = ⌊ (1000000 - 49) / 9 ⌋
N = 111105
</code></pre>
<p>Maximum number of AnyoneCanSpend outputs is 111105</p>

CC BY-SA 4.0
2024-07-11T10:44:31.907Z
2024-07-11T10:44:31.907Z
Lee
<p>Is there a maximum recommended number of inputs/outputs for each transaction? I was scripting a faucet and wasn't sure whether to payout in one transaction to all addresses or split them into groups of say 100 or 1000.</p>

CC BY-SA 3.0
2015-01-17T17:01:28.460Z
I don't think there *is* a limit, except that every transaction must be capable of fitting into a block.
Nick ODell
<transactions><transaction-input><output><transaction-weight><payment-batching>
What is the maximum number of inputs/outputs a transaction can have?
cainy393
# What is the maximum number of inputs/outputs a transaction can have?

(Asked by: username_0 on 2015-01-17)

Is there a maximum recommended number of inputs/outputs for each transaction? I was scripting a faucet and wasn't sure whether to payout in one transaction to all addresses or split them into groups of say 100 or 1000.

**Tags:** transactions, transaction-input, output, transaction-weight, payment-batching

> **Comments:**
> **username_1**: I don't think there *is* a limit, except that every transaction must be capable of fitting into a block.  

---

## 4 answers

### Answer by username_2 on 2015-01-17. Score: 13

The total size of the transaction must be less than 100,000 bytes or it will not be relayed across the network or included in blocks.

There COULD be a miner that is mining >100K transactions, but I don't think there is; if there is such a miner or you mine the transaction yourself then the limit would be the 1,000,000 byte blocksize limit.

> **Comments:**
> **username_3**: This was true previously however, BIP141 has changed things when it was activated. See this question: [What is the current maximum Bitcoin block size in MB?](https://bitcoin.stackexchange.com/questions/69468/what-is-the-current-maximum-bitcoin-block-size-in-mb)  

---

### Answer by username_4 on 2023-05-25. Score: 7

These numbers are slightly different today after the segwit and taproot softforks got activated.

A standard transaction is limited to 400 000 weight units (WU). The smallest standard (single-sig payment¹) input is a P2TR keypath input with [230 WU](https://bitcoin.stackexchange.com/q/111395/5406). The [smallest standard (payment²) output](https://bitcoin.stackexchange.com/q/111395/5406) is P2WPKH with 124 WU.

The header of a segwit transaction [takes at least 42 WU](https://bitcoin.stackexchange.com/q/84004/5406). For transactions with large input or output counts, the [counter will increase](https://bitcoin.stackexchange.com/a/114585/5406) from 1 byte to 3 bytes when we have more than 252 inputs or outputs. This means that for the below transactions the header bytes will weigh 50 WU, leaving 399 950 WU for inputs and outputs.

Therefore, a standard transaction with one P2TR input (230 WU) could have **3223 P2WPKH outputs** (3223 × 124 WU = 399 652 WU) (and could optionally add one OP\_RETURN output (40 WU+) for a total of 3224 outputs).

A standard transaction with one P2WPKH output (124 WU) can have **1738 P2TR keypath inputs** (1738 × 230 WU = 399 740 WU).

---

¹ A P2WSH input with an `OP_TRUE` witness script would be smaller and considered standard (H/T @instagibbs), but I’m sticking to commonly used script types based on a single signature for this answer.  
² OP\_RETURN outputs can be smaller (H/T Pieter Wuille), but you are only permitted a single OP\_RETURN output in a standard transaction.


---

### Answer by username_5 on 2015-01-17. Score: 4

The economical way in your case would be to pay off (create as much outputs) as you can to decrease the fee cost.

Some standard transaction with one proven input and one output is about 161 - 250 bytes. [see reference](https://en.bitcoin.it/wiki/Maximum_transaction_rate) some est. basic values:

* 10 bytes for transaction header
* 50 bytes for previous transaction reference
  + 9 bytes for header
* 50 for output (depending on script size)

The standard requirement (for miners to include your tx) is to pay 0.0001 BTC per 1000 bytes.

If your transaction is larger than 100 kB theoretical limit could be that your transaction is non-standard which means it fails the test IsStandard() for including the tx into the block because it is too large.

Nevertheless, it is possible to include even non-standard transaction into the block. This is being done by several mining pools but usually requires slightly higher fee.

So I estimate you can create transaction with up to 1900 outputs paying just 0.02 BTC fee and having transaction most probably verified in the upcoming block.

Please note that I have not tried this myself it is just my assumption.

> **Comments:**
> **username_0**: I appreciate your input here. 0.02 is actually quite a high fee considering the small nature of the transactions I make. Furthermore I do not require that the transaction is processed promptly. Due it being a faucet I'm not bothered how long the transaction takes to confirm. In this instance what do you think would be a suitable number of addresses to include for a fee closer to 1 mBTC or similar?  
> **username_5**: @username_0 Yes, you can have the fee as low as a 0.00001 BTC but it will take ages to get confirmed. I advice you to make some research on this - try to relay some low fee txs.  
> **username_0**: Since I was using the blockchain.info API I just set the transaction fee to normal and let it select a reasonable one, which almost always seems to end up being 0.1 mBTC as per usual.  I found that much more than 100 transactions at a time became a problem due to the fact that I was making a GET request to the API and I think the url was too long.  

---

### Answer by username_6 on 2024-07-11. Score: 0

**The maximum theoretically possible number of outputs in a transaction is 111105**

To achieve the theoretical maximum, the transaction must be a coinbase transaction with non-output fields minimised (so that the ~whole block can be dedicated to outputs).

A formula for the possible number of outputs, `N`, in that case:

```
Block_size_limit_bytes = Transaction_fields_bytes + N*output_size_bytes
N = ⌊ (Block_size_limit_bytes - Transaction_fields_bytes) / output_size_bytes ⌋

```

(`⌊x⌋` means round x down to nearest integer)

**For P2PKH:**

```
Transaction_fields_bytes: 47 bytes (ignoring BIP34)
output_size_bytes:  25 + 9 = 34 bytes

N = ⌊ (1000000 - 47) / 34 ⌋
N = 29410

```

Maximum number of P2PKH outputs is 29410

**For P2WPKH:**

```
Transaction_fields_bytes: 47 bytes (note no witness field required as no Segwit inputs)
output_size_bytes:  22 + 9 = 31 bytes

N = ⌊ (1000000 - 47) / 31 ⌋
N = 32256

```

Maximum number of P2WPKH outputs is 32256

**For AnyoneCanSpend:**

```
Transaction_fields_bytes: 49 bytes (additional 2 bytes as no outputs>2**16)
output_size_bytes:  0 + 9 = 9 bytes

N = ⌊ (1000000 - 49) / 9 ⌋
N = 111105

```

Maximum number of AnyoneCanSpend outputs is 111105


---

