[Lightning-dev] [PATCH] First draft of option_simplfied_commitment

Matt Corallo lf-lists at mattcorallo.com
Sat Nov 16 05:46:26 UTC 2019


Regarding the dust relay limit, there may be a little bit of a
misunderstanding as to a few important details. The purpose of it (much
like the dust output values in the anchor outputs) is to discourage
outputs which are not ever economically spendable, not short-term
uneconomically spendable.

This value is, thus, *not* connected to the mempool's min relay fee
(except for the purposes of calculating the constant, which may be part
of the disconnect here). The min relay fee represents a short-term DoS
limit, and, thus, can float wildly (though, since 2017, and even in
general, we largely have not seen it go up much in absolute value at all).

Further, and, critically, there are a number of issues with *any* policy
change that makes several bits of the P2P network less efficient, and,
thus, they are generally avoided where possible. These include, compact
block relay, feerate estimation, relay-DoS-resistance, etc.

While none of this is to say that the dust limit will *never* change, I
really don't think its unreasonable to hard code it - there's no
pressure *to* change it, and if there's an additional reason not to (ie
that deployed software relies on that value, which other software, more
than lightning already does), then it almost certainly wont be.

Matt

On 11/14/19 9:56 AM, Joost Jager wrote:
>> 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
> 
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev



More information about the Lightning-dev mailing list