As is, we're scheduled to tag the first release candidate of our latest major
release: 0.13, in a few weeks. One long running thread across our past few
release has been the prospect of the security enhancements brought about by
the "anchor" commitments protocol extension. Towards the end of the 0.12
release cycle, we made the decision to revert the previous move to make it
the "default" channel type due to the fear that an abrupt switch would end
up breaking end user wallets and services that weren't aware of the new
sanity checks added when opening a channel. At a high level, if one runs lnd
today with `--protocol.anchors` flag then a new restriction is added when
opening channel: there must be a "sufficient" amount of on-chain coins left
in the wallet, otherwise the funding request (or on-chain send request) will
In practice this means that previous "empty all my coins into a channel"
logic will no longer work when the flag is active. In addition to this,
attempts to empty out an on-chain wallet will *fail* if the lnd node has any
active anchor-enabled channels open. The rationale for this restrictions is
that although anchors enables an implementation to no longer "guess" what
the correct fee should be (as it can't be bumped after broadcast
pre-anchors), it shifts around the problem slightly to ensuring enough funds
are available *after commitment broadcast*. With fees steadily on the rise,
if routing nodes aren't able to increase the fee of their commitment
transaction in time with in-flight HTLCs, then loss of funds may occur due
to the time-lock race condition created when both the incoming and outgoing
One missing piece, namely automatically bumping up the fee of a commitment
transaction or HTLC resolution based on the current relative deadline to
timelock expiration is now under review . Ideally we're able to
sufficiently review+test the PR for inclusion in the next release before we
tag the upcoming rc.
With all that said, I'd like for the project to once again consider making
anchors the *default* for this new release, in-spite of the added
limitations to increase the safety of multi-hop HTLC resolution within the
core of the routing network. In the past we made the decision to flip things
back to opt-in as it wasn't clear that there was sufficient awareness of the
new funding related restrictions amongst the existing ecosystem of wallets
and services that were built upon lnd.
As we now have a bit of lead time before the next release, I'd like to hear
from those that maintain a wallet or service that depends on lnd to gauge if
these changes may not be all that destructive in practice. Some relevant
questions LN service/wallet developers include:
* Can your service/wallet presently handle not being able to fund a
channel w/ a low on-chain wallet in certain situations?
* Will removing the ability to "sweep all funds" from lnd's wallet while
it has active anchor channels present a significant burden (UX or
otherwise) to your wallet/service?
* Is the new requirement to maintain a certain amount of on-chain funds in
lnd's wallet *at all times* a significant barrier to adopting the
(safer) anchor commitments proposal?
Related to this change is my ongoing work on dynamic commitments . By
the end of the week I should have some working code that will allow an lnd
node to upgrade *on the fly*, without incurring any on-chain costs to switch
the new anchor commitment format, either upon start up or manually with user
intervention (to land sometime in the 0.14 era). This'll allow us to update
the entire network in a de-synchronized manner to the new safer format.
However if the current restrictions are deemed too severe, then we may have
to seek out some alternative guardrails in place. Without any guardrails
worst case is that a broadcaster commitment can't confirm due to
insufficient fees, and *manual* intervention is required to top off lnd's
on-chain wallet so it can use those new inputs to complete the CPPF and
"anchor" down the channel.
Looking forward to hearing from y'all!