Hi list
With the current hullabaloo on default policy, custom policy rules on the base
layer I started thinking about the process for negotiating configuration
options for a channel open with a potential channel counterparty, what it
currently is and what should optimally be part of the Lightning P2P protocol
and what should be communicated out of band.
I'm not familiar with the codebases of all the Lightning implementations so
although I can scratch around and find out some of the answers myself I'm sure
there are people on this list who are much better informed than I am.
One particular area I'm interested in is the setting of timelocks [0]
(to_self_delay, cltv_expiry) as defaults in Lightning implementations, the
ability of Lightning node operators to change from those defaults and to what
extent they can/should be able to negotiate on what these are prior to agreeing
to open a channel together.
My understanding with the setting of both of these timelocks is that it is a
direct trade-off between giving you as a Lightning node operator as much time
to respond to cheat attempts / untimely revealing of the HTLC prehash and
risking your capital being locked up for longer when a channel counterparty or
a participant in a route misbehaves. The higher the timelocks are the more
"secure" it is but also the longer your capital will be locked up for in
"unhappy" cases.
When onchain fees are low no one really cares what these timelocks are and as
long as the Lightning implementations set reasonable defaults Lightning node
operators are happy to run them. But when onchain fees are higher and the
ability to get a transaction confirmed onchain becomes more
challenging/expensive these timelocks will be a lot more relevant. As a result
this trade-off and the individual Lightning node operators' preferences will
also be in greater focus.
So a few questions (which are also covered in the linked StackExchange post
[0]). What are the defaults for these timelocks today in all the Lightning
implementations? How easy it is for Lightning node operators to change them? Is
it possible (should it be possible?) for Lightning node operators to negotiate
the setting of these timelocks prior to opening a channel? Or should this be
done in out of band communication prior to agreeing to use the Lightning
protocol to open a channel? If both potential channel counterparties have
different preferences on setting these timelocks is it (should it?) be clear
that the reason the potential channel counterparty rejected the channel open
was because the preferred timelocks were slightly different?
Thanks
Michael
[0]:
https://bitcoin.stackexchange.com/questions/121673/what-are-the-default-timelocks-in-lightning-implementations-today-how-are-they
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
