<p>The maximum standard transaction size was introduced in <a href="https://github.com/bitcoin/bitcoin/pull/2273" rel="nofollow noreferrer">PR 2273</a>. In this PR, the rationale is given as</p>
<blockquote>
<p>Extremely large transactions with lots of inputs can cost the network
almost as much to process as they cost the sender in fees.</p>
</blockquote>
<p>A similarly worded comment lives in the codebase today above the code that performs the check.</p>
<p>This limit was introduced at 100 KB; when segwit was introduced, it was changed to be a weight limit changed to 400000 weight which results in an equivalent 100 KB non-witness size limit.</p>

CC BY-SA 4.0
2024-10-31T17:49:53.190Z
While this provides the stated reason why the limit was introduced, I was hoping to get a broader overview of the arguments why (and perhaps why not) transactions should be limited in weight.
Murch
CC BY-SA 4.0
2024-11-05T22:34:30.323Z
IT is a mystery why there is so little conversation on this subject, in the PR he mentioned.  To bad he didn't link from the PR to the broader discussion area.
djangofan
CC BY-SA 4.0
2024-10-30T21:23:15.820Z
2024-10-30T21:23:15.820Z
Ava Chow
<p>Larger transactions would permit slightly more efficient, bigger consolidation or batched payment transactions as well as non-payment application such as e.g. novel second layer protocols that make use of large proofs. If economic demand for such transactions were established, the current standardness weight limit could prove fragile and easily be circumvented via direct submission to miners or private mempools. This could quickly lead to the standardness limit being obsoleted and transactions of any consensus-valid weight being accepted to mempools.</p>
<p>Reasoning about transaction relay, incentive compatibility and validation are significantly easier with smaller transactions, e.g. pinning, the quadratic hashing problem, dependencies in the mempool, etc.</p>
<p>But the biggest issue with larger transaction sizes is how it affects block template creation. Building the block that collects the maximum sum of fees is a variant of the knapsack problem and therefore NP-hard. Good solutions can be approximated with greedy algorithms, even better solutions can be computed e.g. with linear programming approaches per significantly more computational effort.</p>
<p>A greedy approach can provide an optimal solution up to the point where the tail-end of the block is reached. Once some selection options no longer fit into the block, the available selection options begin to depend on prior choices and finding selections that significantly increase the block reward may require traversing an exponentially growing count of combinations.</p>
<p>As the block subsidy is exponentially shrinking, block rewards are expected to be increasingly dominated by fees as time passes. As long as most transactions are significantly smaller than the block space limit, greedy approaches will be able to produce sufficiently close to optimal solutions for miners to not gain a significant advantage by throwing more computing power at finding better block templates.
If investing more computing power results in drastically higher block rewards, mining operations will have yet another efficiency of scale that makes mining less fair for smaller miners.</p>
<p>Large transactions significantly increase the portion of the block that can no longer be populated close to optimally with a greedy approach and therefore represent mining centralization pressure. It would also incentivize the emergence of centralized block template creators, undermining censorship resistance.</p>

CC BY-SA 4.0
2024-11-05T22:24:16.730Z
2024-12-03T13:02:29.277Z
2024-12-03T13:02:29.277Z
Murch
<p>What are the reasons and arguments for and against limiting the weight of transactions per standardness rules or even consensus rules?</p>

<non-standard-transaction><transaction-weight>
Why do standardness rules limit transaction weight?
Murch
# Why do standardness rules limit transaction weight?

(Asked by: username_0 on 2024-10-30)

What are the reasons and arguments for and against limiting the weight of transactions per standardness rules or even consensus rules?

**Tags:** non-standard-transaction, transaction-weight


---

## 2 answers

### Answer by username_1 on 2024-10-30. Score: 2

The maximum standard transaction size was introduced in [PR 2273](https://github.com/bitcoin/bitcoin/pull/2273). In this PR, the rationale is given as

> Extremely large transactions with lots of inputs can cost the network
> almost as much to process as they cost the sender in fees.

A similarly worded comment lives in the codebase today above the code that performs the check.

This limit was introduced at 100 KB; when segwit was introduced, it was changed to be a weight limit changed to 400000 weight which results in an equivalent 100 KB non-witness size limit.

> **Comments:**
> **username_0**: While this provides the stated reason why the limit was introduced, I was hoping to get a broader overview of the arguments why (and perhaps why not) transactions should be limited in weight.  
> **username_2**: IT is a mystery why there is so little conversation on this subject, in the PR he mentioned.  To bad he didn't link from the PR to the broader discussion area.  

---

### Answer by username_0 on 2024-11-05. Score: 2

Larger transactions would permit slightly more efficient, bigger consolidation or batched payment transactions as well as non-payment application such as e.g. novel second layer protocols that make use of large proofs. If economic demand for such transactions were established, the current standardness weight limit could prove fragile and easily be circumvented via direct submission to miners or private mempools. This could quickly lead to the standardness limit being obsoleted and transactions of any consensus-valid weight being accepted to mempools.

Reasoning about transaction relay, incentive compatibility and validation are significantly easier with smaller transactions, e.g. pinning, the quadratic hashing problem, dependencies in the mempool, etc.

But the biggest issue with larger transaction sizes is how it affects block template creation. Building the block that collects the maximum sum of fees is a variant of the knapsack problem and therefore NP-hard. Good solutions can be approximated with greedy algorithms, even better solutions can be computed e.g. with linear programming approaches per significantly more computational effort.

A greedy approach can provide an optimal solution up to the point where the tail-end of the block is reached. Once some selection options no longer fit into the block, the available selection options begin to depend on prior choices and finding selections that significantly increase the block reward may require traversing an exponentially growing count of combinations.

As the block subsidy is exponentially shrinking, block rewards are expected to be increasingly dominated by fees as time passes. As long as most transactions are significantly smaller than the block space limit, greedy approaches will be able to produce sufficiently close to optimal solutions for miners to not gain a significant advantage by throwing more computing power at finding better block templates.
If investing more computing power results in drastically higher block rewards, mining operations will have yet another efficiency of scale that makes mining less fair for smaller miners.

Large transactions significantly increase the portion of the block that can no longer be populated close to optimally with a greedy approach and therefore represent mining centralization pressure. It would also incentivize the emergence of centralized block template creators, undermining censorship resistance.


---

