The paper suggests a soft-cap to combat "Forced Expiration Spam".
An attacker who causes many of the channels to be prematurely closed at once could overwhelm the network.
This means that some nodes might not be able to get their refund transactions accepted before the expiry of the locktime.
The soft cap rule means that blocks can be made larger in an "emergency" but would normally be smaller than the soft cap.
This could be accomplished by allowing transactions to reserve space for the closing transactions using a new opcode (OP_RESERVE).
<uint16 reserved_bytes> OP_RESERVE OP_DROP <normal scriptPubKey>
and the P2SH version
<uint16 reserved_bytes> OP_RESERVE OP_DROP OP_HASH160 [script hash] OP_EQUAL
OP_RESERVE in any other place would count as a failed script. Otherwise, it is just a NOP.
This transaction would count as that much extra space in the block. If a 250 byte transaction reserved another 300 bytes, then when computing the soft cap, that transaction would count as 550 bytes.
A transaction which spends that output would get credit for the reserved bytes. If it was 300 bytes, then it would count as zero bytes in size and not count towards the soft-cap. In effect, the bandwidth was already "paid" in the previous transaction.
The soft cap would be paired with a much higher hard cap. The average block size would be limited to the soft cap, but individual blocks could be much higher (say 10-20X).
Each tx would have an effective size of
(tx size) + sum(bytes reserved by outputs) - sum(bytes reserved by inputs)
