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.
1I don't think there is a limit, except that every transaction must be capable of fitting into a block.– Nick ODellJan 17, 2015 at 17:01
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.
2This 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?– WilltechFeb 8, 2018 at 13:04
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. The smallest standard (payment²) output is P2WPKH with 124 WU.
The header of a segwit transaction takes at least 42 WU. For transactions with large input or output counts, the counter will increase 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.
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 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.
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?– cainy393Jan 18, 2015 at 19:25
@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.– MarekJan 19, 2015 at 22:58
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.– cainy393Feb 16, 2015 at 17:54