I'm not up on modern Bitcoin opcodes, so I hope this makes sense:

A hard-fork proposal to make closing Lightning Network channels more predictable:

Problem: At the time a Lightning Network channel is opened, it is unknown what fees will be required to close it.

Insight: Most agree that the size of the blockchain should not grow faster than it currently is growing: 1 MB per block. But what if a block was published that was X bytes shorter than this limit, with the understanding that some future block be allowed to exceed the 1 MB limit by X bytes?

Proposal: Two new opcodes would be introduced:

"Reserve X bytes" would include a signed nonce. If a miner chose to include a transaction with such an opcode, then the block they publish must be at least X bytes smaller than the 1 MB limit. Miners would tend to price such a transaction based on the actual size of the transaction plus X.

"Redeem Nonce" would simply allow the mined block to exceed 1 MB by up to X bytes. Miners would tend to include all such transactions in the mempool where X is no more than the actual size of the transaction, because it would be free money: they would get all of the associated transaction fees while not using up any of the 1 MB space allowed.