Non-confiscatory Transaction Weight Limit

The challenge of constructing block templates becomes notably complicated as transaction sizes approach the limit of a block, raising concerns beyond mere technical capabilities. Software solutions capable of optimally building block templates from a selection of candidate transactions could mitigate some of these complexities. However, this introduces a secondary issue more critical than the construction of blocks itself: the difficulty for relay nodes, which may not be involved in mining, to make profitable decisions in advance of block formation. This complexity arises from the need to decide on the viability of transactions long before their potential inclusion in a block, a decision made even more uncertain by the possible arrival of additional transactions in the interim.

A key concern is the reliance of users intending to execute large transactions on the public peer-to-peer network and anonymous miners for confirmation of their transactions. In the absence of reliable information on miner-incentive compatibility at relay time, users are compelled to secure private agreements with miners to ensure their large transactions are confirmed without excessive cost. The overarching goal should be to enable the confirmation of large transactions without necessitating such private agreements or incurring significant additional expenses. Failure to achieve this renders any improvements in block building for miners moot, as users and miners would simply bypass these processes for direct agreements.

Delving into the specifics of handling giant transactions, one proposed limit suggests a hypothetical consensus cap of 990000 virtual bytes (vB) for transactions, assuming headers and coinbase transactions do not exceed 10000 vB. A scenario is posited where a large transaction, despite offering a competitive fee rate, might not be included in the optimal block template due to bin-packing dilemmas and the steepness of the fee-size curve. This discrepancy can lead to erroneous relay and replacement decisions, expose the network to potential free relay attacks, and cause congestion in the mempool with transactions unlikely to be mined.

For smaller transactions, the decision to mine can be static, determined at the point of relay. Conversely, the larger a transaction, the more its potential for being mined depends on the context of other transactions at the time a block is found. This uncertainty complicates defenses against denial-of-service attacks. A tentative solution considers simplifying block construction by treating every transaction as if it were approximately 1 MvB in size, which effectively reduces the block to containing only one large transaction plus the coinbase. This approach, while potentially reducing issues related to child-pays-for-parent (CPFP) scenarios and dependency problems, might not fully address the underlying challenges but offers a starting point for further discussion and development.