Proposal for Simplified Lightning Channel Closures

I'm not super familiar with the latest Bitcoin opcodes, so I hope I'm clear here: I’ve got a hard-fork idea aimed at making the closure of Lightning Network channels more straightforward: So here’s the issue: when you open a Lightning Network channel, you have no clue what fees you’ll need to close it. Here’s a thought: people mostly agree that we should keep the blockchain from expanding too quickly, like the current limit of 1 MB per block. But what if a block was published that was a bit smaller than that limit, knowing that a future block could go over the 1 MB limit by that same amount? Here’s the proposal: we’d add two new opcodes: "Reserve X bytes" would involve a signed nonce. If a miner decides to add a transaction with this opcode, the block they create must be X bytes less than the 1 MB cap. Miners would likely set fees for such transactions based on the real size plus that X. "Redeem Nonce" would let the mined block exceed the 1 MB limit by up to X bytes. Miners would probably want to include all these transactions in the mempool as long as X doesn’t go over the actual transaction size, since it’s basically free cash for them: they’d rake in all the fees associated without taking up any of the 1 MB space.

Blocks have been larger than 1 MB for several years now. There is nothing currently preventing miners from publishing smaller blocks if they want to. I suspect there are several issues with this, but the first that comes to mind is: This seems like it would open an avenue for a significant attack.  Couldn't a malicious party "Reserve" space as much as possible every time fees are low, and then after a few years "Redeem" all the reserved space all at once in a HUGE block?

I like this idea. It's basically a "prepaid future block space". This could even be generalized, i.e. not only usable for Lightning channels, but also for all kinds of transactions - you anyway couldn't avoid it to be used for other purposes. I have not heard about such a proposal at this moment, although it's still possible somebody has proposed it in the past. There's only one problem I see: When transactions are cheap, it is likely that some entities could reserve lots of space and then make block space unnecessarily scarce, for example exchanges who want space for future consolidation transactions. This would however also drive up the fee, like if normal transactions were stored instead, and thus it could not be abused infinitely. In general it would lead probably to a more balanced fee market, with less low-fee and less high-fee periods. Some time ago I had a somewhat related idea: change the "weight formula" of some transaction types, to make simple payments and Lightning closure transactions occupying less weight than normal transactions. This would make channel closures in congested times easier. The problem is however a bit similar to the one of your idea: if you lower the weight too much, then people will find ways to use it for other purposes, maybe even for storing data in some way (see Stampchain's or Doginals' approach) and then you have effectively a block size increase. Your proposal is better than this one, because there would be no (average) block size increase even if the mechanism was gamed somewhat, but there could be still the problem of excessive "space reservations". I don't think that a hard fork would be achievable for this on Bitcoin, at least outside of an emergency situation. You could try however to find an altcoin project which is more accustomed to hardforking, and in the case of the mechanism working well it could maybe taken under consideration. (PS: This for sure would get normally more merits from me, but I'm a bit cautious as it's your first post since 2016 and the password was changed. Perhaps you can clarify.) Edited the post a bit as I also want to answer @DannyHamilton who posted almost at the same time than me: Using this to attack Bitcoin would be equally expensive than a normal spam attack, so I think the reservation of space itself is not a vector here (i.e. you couldn't make Bitcoin unusable). I'm unsure if the huge block in the future could be a problem though. Perhaps this could be solved with a hard block size cap of e.g. 2x the current max vByte size. This means there would be additional space for "redeem nonce" transactions per block, but a limited amount.

It's interesting idea and easy to understand, but i don't like it due to these reasons. 1. It's a hard-fork, which unlikely to be accepted by Bitcoin community and developers. 2. Additional technical complexity on protocol level. I prefer either block size increase or LN software improve how they handle inconsistent TX fee rate. But that would kill the point of OP's idea, since people/group who have "reserve" still compete in terms of TX fee rate.

That's a valid point. In theory there could be ways to deal with the "huge block" problem in another ways, but the solutions occurring to me (preserving the original concept of no fee-competition in the future block) would make the protocol much more complex and also less useful. For example, one could think about limiting the reservation to a timeframe (between blockheight X and Y), limit the amount of "reserve transactions" per block, etc.. But a relatively simple solution could be to change the concept a bit: Instead that the "reservation" means that you will be able to get a space in any future block without fee competition, it means that you are enabled to compete in an additional space of the block (e.g. 4 MB vBytes more). In this space there will be less fee competition so a fast confirmation is extremely likely, but not guaranteed. This would solve the "huge block" problem and also gives the miners even more incentives to include the second transactions, as there will be to some extent a fee market in this additional block space because it's not unlimited.

It's somewhat better. But if without fee competition means no fee, there's no reason for miner/pool to add such transaction.

I think here you misunderstood. My "variation" of the proposal means that there should be fee competition. If the space where such redeem transactions can be included is limited, then transactions will compete for this space. Even if the block space was unlimited then the users would include a fee because otherwise no miners would include their transactions. But with a limited space there can be situations where the competition leads to a significant income for miners. As the OP wrote, these transactions are "free money" for the miners, so they will include them even if the fee is very low. On most altcoins where the fee competition is low (e.g. LTC) it works in the same way.