Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Feedback Requested: Default Anchor Channels in lnd
179 views
Skip to first unread message
Olaoluwa Osuntokun
Apr 6, 2021, 8:31:01 PM4/6/21
to lnd
Hi y'all,
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
be *rejected*.
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
HTLC expire.
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 [1]. 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 [2][3]. 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!
-- Laolu
[1]: https://github.com/lightningnetwork/lnd/pull/5148
[2]: https://twitter.com/roasbeef/status/1285384312724979712
[3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
-- Laolu
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
be *rejected*.
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
HTLC expire.
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 [1]. 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 [2][3]. 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!
-- Laolu
[1]: https://github.com/lightningnetwork/lnd/pull/5148
[2]: https://twitter.com/roasbeef/status/1285384312724979712
[3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
-- Laolu
Olaoluwa Osuntokun
Apr 27, 2021, 8:25:22 PM4/27/21
to Daniel Alexiuc, lnd
So "sweepall" will still work, but it may send funds back to the lnd
wallet if the action would've otherwise reduced lnd's balance
below the required threshold.
On Tue, Apr 6, 2021 at 6:02 PM Daniel Alexiuc <dan...@alexiuc.com> wrote:
* Can your service/wallet presently handle not being able to fund a
channel w/ a low on-chain wallet in certain situations?
Yes, I don't see any problems with that.
* 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?
We do use a sweep all once a week or so to consolidate transactions when fees are low. However I don't think this is a significant problem, we can probably just do a 'sweep most' instead.
* 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?
No problem, we always have on-chain funds present.Daniel
--
To unsubscribe from this group and stop receiving emails from it, send an email to lnd+uns...@lightning.engineering.
Olaoluwa Osuntokun
May 5, 2021, 3:27:29 PM5/5/21
to lnd
---------- Forwarded message ---------
From: Olaoluwa Osuntokun <la...@lightning.engineering>
Date: Tue, Apr 27, 2021 at 5:23 PM
Subject: Re: [lnd]: Feedback Requested: Default Anchor Channels in lnd
To: Roy Sheinfeld <ro...@breez.technology>
Cc: roeierez <roei...@gmail.com>, Yaacov Akiba Slama <yas...@breez.technology>
From: Olaoluwa Osuntokun <la...@lightning.engineering>
Date: Tue, Apr 27, 2021 at 5:23 PM
Subject: Re: [lnd]: Feedback Requested: Default Anchor Channels in lnd
To: Roy Sheinfeld <ro...@breez.technology>
Cc: roeierez <roei...@gmail.com>, Yaacov Akiba Slama <yas...@breez.technology>
Hi Roy,
Thanks for responding!
Answers to your questions:
1. Right now we require that at least 10k satoshis be allocated (can be in a
single UTXO) per anchor channel. We do this to ensure that if a user force
closes then we can attach additional fees to ensure their transaction
confirms. This value isn't set in stone, and instead was selected as an
initial "good enough" value to move forward with.
2. Yes the amount is per channel, but we're looking into possibly tweaking it
such that it doesn't directly apply to _private_ channels, since they aren't
used for routing in the network today.
3. Yes, each node personally makes sure it has enough funds allocated to get
a force close transaction confirmed if it needs to. We could possibly make
the check slightly looser by only enforcing the new reserved balance if you
have funds on the channel. However, that would mean that if a user received a
new incoming HTLC, they may not be able to get their force close transaction
confirmed in time to redeem the HTLC on chain.
4. Yes, old channels can still be used. The default comes into play when you
connect to another peer that signals the new feature bit, in this case then a
new anchor channel will be opened. In the future, we plan to use dynamic
commitment to upgrade all nodes on the fly (either opt-in or automatically).
I realized I worded one of the prior questions incorrectly: the "sweepall"
functionality will still work (not return an error in this case new case), but
will instead create an _additional_ change output to send the required funds
back into lnd's wallet.
This topic (making anchors the default) is now IMO, increasingly more relevant
given the now subsiding blockchain congestion due to a hash rate drop (and
possibly other factors). We've had some users contact us that their channels
can't close, as they forced closed a non-anchors channel with a very low fee
rate (like 1 sat/byte), so they can't bump it without cooperation from the
other party.
We're a week or so away from tagging 0.13rc1, so we'd like to be able to commit
to a direction w.r.t (finally) making this the default within the next week or
so.
-- Laolu
Thanks for responding!
Answers to your questions:
1. Right now we require that at least 10k satoshis be allocated (can be in a
single UTXO) per anchor channel. We do this to ensure that if a user force
closes then we can attach additional fees to ensure their transaction
confirms. This value isn't set in stone, and instead was selected as an
initial "good enough" value to move forward with.
2. Yes the amount is per channel, but we're looking into possibly tweaking it
such that it doesn't directly apply to _private_ channels, since they aren't
used for routing in the network today.
3. Yes, each node personally makes sure it has enough funds allocated to get
a force close transaction confirmed if it needs to. We could possibly make
the check slightly looser by only enforcing the new reserved balance if you
have funds on the channel. However, that would mean that if a user received a
new incoming HTLC, they may not be able to get their force close transaction
confirmed in time to redeem the HTLC on chain.
4. Yes, old channels can still be used. The default comes into play when you
connect to another peer that signals the new feature bit, in this case then a
new anchor channel will be opened. In the future, we plan to use dynamic
commitment to upgrade all nodes on the fly (either opt-in or automatically).
I realized I worded one of the prior questions incorrectly: the "sweepall"
functionality will still work (not return an error in this case new case), but
will instead create an _additional_ change output to send the required funds
back into lnd's wallet.
This topic (making anchors the default) is now IMO, increasingly more relevant
given the now subsiding blockchain congestion due to a hash rate drop (and
possibly other factors). We've had some users contact us that their channels
can't close, as they forced closed a non-anchors channel with a very low fee
rate (like 1 sat/byte), so they can't bump it without cooperation from the
other party.
We're a week or so away from tagging 0.13rc1, so we'd like to be able to commit
to a direction w.r.t (finally) making this the default within the next week or
so.
-- Laolu
On Wed, Apr 7, 2021 at 1:18 AM Roy Sheinfeld <ro...@breez.technology> wrote:
Hi Laolu,
Thanks for reaching out!
We haven't had the time to look into anchor yet.
Couple of questions:
1. What's a "sufficient" amount?
2. Is the amount per channel (we have thousands of channels and expect tens of thousands and want to put most of our liquidity in channels)?
3. Does this requirement apply on the other end of the channel (our users don't have on-chain balance)?
4. If and when you upgrade, could we still use the "old" channels?
To answer your questions:
* Can your service/wallet presently handle not being able to fund a channel w/ a low on-chain wallet in certain situations? No.
* 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? No.
* 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? Yes, it seems it would be, but we need some clarity here.
Best,
Roy
-------- Original Message --------
--
Reply all
Reply to author
Forward
0 new messages