The most substantial design discussion after merge was about tx.gas, lanes, and whether a high-gas transaction can cheaply crowd out a low-throughput lane. dimdumon raised the concern that a non-system-lane attacker might only need to outbid honest users and set Tx.GAS = MAX, rather than fill ordinary block space with many transactions. (source) (source)
Sutton's first answer was that the current path is fee competition, with future mempool work aware of busy gas dimensions. IzioDev proposed keeping the per-block gas limit while adding a standard per-transaction gas limit to make lane clutter more expensive. (source) (source)
The discussion then sharpened around economics rather than L2 execution validity. hashdag said "gas payments are through L1" and go to L1 miners, while the miners remain the throttling entity regardless of transaction interpretation on other layers. (source)
FreshAir08 argued that if an attacker is willing to pay more than honest users for block space, that is not the same as an unpaid denial-of-service attack. hashdag summarized the model as a multi-dimensional gas-limit and knapsack system: below each lane constraint, the lane has no effect in that block; once the limit is reached, the lane participates in multi-dimensional pricing. (source) (source) (source)
someone235 added the implementation caveat: optimal revenue-maximizing transaction selection is NP-hard, so the node needs an approximation or assumptions about transaction distribution. Sutton agreed that a sufficiently good practical approximation can be designed, but keeping current performance is the harder part. (source) (source)
All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.