Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-14 📝 Original message: > > > So then because ...
📅 Original date posted:2019-11-14
📝 Original message:
>
> > So then because unilateral close is the only way to resolve atm, it is
> > correct also in theory that there will never be a commitment tx where the
> > non-initiator pays fees? But the point is clear, channels can get stuck.
>
> Yeah. Generally, it doesn't happen because we insist on a reasonable
> balance in the channel, but it's theoretically possible.
>
Ok, summarizing just for clarity:
- there will never be a commitment tx where the non-initiator pays fees
- generally a unilateral close doesn't happen because we insist on a
reasonable
balance in the channel
> >> > If we hard-code a constant, we won't be able to adapt to changes of
> >> > `dustRelayFee` in the bitcoin network. And we'd also need to deal
> with a
> >> > peer picking a value higher than that constant for its regular funding
> >> flow
> >> > dust limit parameter.
> >>
> >> Note that we can't adapt to dustRelayFee *today*, since we can't change
> >> it after funding (another thing we probably need to fix).
> >>
> >
> > You can't for an existing channel, but at least for a new channel you can
> > pick a different value. Which wouldn't be possible if we'd put a fixed
> > (anchor) amount in the spec.
>
> That's not really much consolation though for the existing network.
>
> Still Matt assures me that the relay dust limit is not going to change,
> so I think we're best off cutting down our test matrix by choosing a
> value and putting it directly into the spec.
>
> By my calculations, at minfee it will cost you ~94 satoshis to spend.
> Dust limit is 294 for Segwit outputs (basically assuming 3x minfee).
>
> So I'm actually happy to say "anchor outputs are 294 satoshi". These
> are simply spendable, and still only $3 each if BTC is $1M. Lower is
> better (as long as we stick with funder-pays), as long as they do
> eventually get spent.
>
Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is
`dustRelayFee` really never going to change? It even is a (hidden) cmd line
parameter that can be set easily.
If the fee market would rise and stay high for an extended period of time,
why wouldn't people use this flag to raise the dust relay fee? If we then
have our hard coded 294 sat anchors, no force close transactions can be
broadcast anymore. It would be risky to open new channels at that point,
because they can only be coop closed.
Maybe Lightning is relevant enough by that time to keep people from
touching `dustRelayFee`, but what if not? The fix at that point would be to
introduce a new commitment format, which given our process takes a long
time.
I'd think that having at least an option to adapt to `dustRelayFee` changes
for new channels makes Lightning more robust. The two options that I know
of are:
- Reuse `dust_limit_satoshis` on the `open_channel`/`accept_channel`
messages as the anchor size. This ignores that an anchor does not need to
be net positive after sweeping (because it's purpose is to get the commit
tx confirmed), while we generally do want htlcs to be net positive. It may
however be not such a big deal in practice. Suppose we'd just set this to
294 sat to get the desired anchor output value (and make it a soft
requirement for channel acceptance). The worst that can happen is that
there is a force close with one or more pending htlcs that aren't
economical to sweep. Which can happen anyway because this is a channel open
parameter and it is impossible to know what is economical for the lifetime
of the channel. Instead of burning to fees, the htlc output will sit there
waiting for fees to go down. It may have expired by then and either party
can claim it. Not perfect, but could it be good enough?
- Add a new `anchor_msat` field to the opening messages. We could add to
the spec "nodes MAY reject the channel if `anchor_sat` isn't 294". At least
then we are not hard-coding the value in the spec.
We *could* tweak both anchors by the same amount, but then you'd still
> need to see one of them to spend the other.
I don't think the tweak adds anything, because there is already enough
tweak on the other outputs? Only in the case of just a tweakless
(`option_static_remote_key`) `to_remote` output, there will also be a
tweakless anchor. But the same reasoning applies there as before: you won't
send this tx to a watchtower?
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191114/f50f4691/attachment.html>;
📝 Original message:
>
> > So then because unilateral close is the only way to resolve atm, it is
> > correct also in theory that there will never be a commitment tx where the
> > non-initiator pays fees? But the point is clear, channels can get stuck.
>
> Yeah. Generally, it doesn't happen because we insist on a reasonable
> balance in the channel, but it's theoretically possible.
>
Ok, summarizing just for clarity:
- there will never be a commitment tx where the non-initiator pays fees
- generally a unilateral close doesn't happen because we insist on a
reasonable
balance in the channel
> >> > If we hard-code a constant, we won't be able to adapt to changes of
> >> > `dustRelayFee` in the bitcoin network. And we'd also need to deal
> with a
> >> > peer picking a value higher than that constant for its regular funding
> >> flow
> >> > dust limit parameter.
> >>
> >> Note that we can't adapt to dustRelayFee *today*, since we can't change
> >> it after funding (another thing we probably need to fix).
> >>
> >
> > You can't for an existing channel, but at least for a new channel you can
> > pick a different value. Which wouldn't be possible if we'd put a fixed
> > (anchor) amount in the spec.
>
> That's not really much consolation though for the existing network.
>
> Still Matt assures me that the relay dust limit is not going to change,
> so I think we're best off cutting down our test matrix by choosing a
> value and putting it directly into the spec.
>
> By my calculations, at minfee it will cost you ~94 satoshis to spend.
> Dust limit is 294 for Segwit outputs (basically assuming 3x minfee).
>
> So I'm actually happy to say "anchor outputs are 294 satoshi". These
> are simply spendable, and still only $3 each if BTC is $1M. Lower is
> better (as long as we stick with funder-pays), as long as they do
> eventually get spent.
>
Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is
`dustRelayFee` really never going to change? It even is a (hidden) cmd line
parameter that can be set easily.
If the fee market would rise and stay high for an extended period of time,
why wouldn't people use this flag to raise the dust relay fee? If we then
have our hard coded 294 sat anchors, no force close transactions can be
broadcast anymore. It would be risky to open new channels at that point,
because they can only be coop closed.
Maybe Lightning is relevant enough by that time to keep people from
touching `dustRelayFee`, but what if not? The fix at that point would be to
introduce a new commitment format, which given our process takes a long
time.
I'd think that having at least an option to adapt to `dustRelayFee` changes
for new channels makes Lightning more robust. The two options that I know
of are:
- Reuse `dust_limit_satoshis` on the `open_channel`/`accept_channel`
messages as the anchor size. This ignores that an anchor does not need to
be net positive after sweeping (because it's purpose is to get the commit
tx confirmed), while we generally do want htlcs to be net positive. It may
however be not such a big deal in practice. Suppose we'd just set this to
294 sat to get the desired anchor output value (and make it a soft
requirement for channel acceptance). The worst that can happen is that
there is a force close with one or more pending htlcs that aren't
economical to sweep. Which can happen anyway because this is a channel open
parameter and it is impossible to know what is economical for the lifetime
of the channel. Instead of burning to fees, the htlc output will sit there
waiting for fees to go down. It may have expired by then and either party
can claim it. Not perfect, but could it be good enough?
- Add a new `anchor_msat` field to the opening messages. We could add to
the spec "nodes MAY reject the channel if `anchor_sat` isn't 294". At least
then we are not hard-coding the value in the spec.
We *could* tweak both anchors by the same amount, but then you'd still
> need to see one of them to spend the other.
I don't think the tweak adds anything, because there is already enough
tweak on the other outputs? Only in the case of just a tweakless
(`option_static_remote_key`) `to_remote` output, there will also be a
tweakless anchor. But the same reasoning applies there as before: you won't
send this tx to a watchtower?
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191114/f50f4691/attachment.html>;