Topic: A Proposal for easy-to-close Lightning Channels (and other uses) (Read 131 times)

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.

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

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 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.

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.

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'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.