Should LDK be so opinionated about our_to_self_delay?

[luckysori]

We have a situation where our node is happy to take on the risk of letting their channel counterparty claim their force-close funds after 12 blocks, but we are hitting this error on channel setup:

rust-lightning/lightning/src/ln/channel.rs

Lines 1223 to 1225 in 56b0c96

	if config.channel_handshake_config.our_to_self_delay < BREAKDOWN_TIMEOUT {
	return Err(ChannelError::Close(format!("Configured with an unreasonable our_to_self_delay ({}) putting user funds at risks. It must be greater than {}", config.channel_handshake_config.our_to_self_delay, BREAKDOWN_TIMEOUT)));
	}

where BREAKDOWN_TIMEOUT is set to 144 blocks.

Whilst I understand that it's safe to enforce this at the library level, it's also limiting. Does it never make sense to go below 144 blocks? The number itself is arbitrary, which leads me to think that the library shouldn't have an opinion on this.

[TheBlueMatt]

I'm curious what your situation is - the 144 constant is designed to include the required time for a user to notice something is wrong, report an issue, and work with developers to resolve it before the timer runs out. For that a day is even relatively short.

[ariard]

@luckysori

Does it never make sense to go below 144 blocks?

There is clearly a case to go under 144 blocks to reduce the timevalue cost of the server liquidity in face of unreliable counterparty with a high-rate of non-cooperative force-close. The downside is in case of security issues, there is very low-odd we can release a security patch to fix the issues in let’s say 12 blocks. Where the we is defined at large with the Lightning folks/Bitcoin Core folks for channel compatibility and transaction-relay propagation compatibility issues. The hard things about hard things, I think the understanding of the whole matrix of liquidity/security risks is still in early days across the ecosystem, so for now I would rather recommend to modify BREAKDOWN_TIMEOUT for the channel acceptance check, especially if you’re already maintaining your own fork.