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

[Joost Jager]

Thanks for this explanation (and Matt's) of the dust limit. For me it
definitely adds to a better understanding of the matter.

In short, I don't expect dust limits to rise unless the BTC/fiat price
> drops so far that UTXO-filling attacks become much more affordable than
> they are with today's limits.  Dust limits may instead decrease (or be
> removed), but I don't think that's a problem for anchor outputs.
>

If the BTC/fiat price rises and this leads to lowering the dust limit, it
could be beneficial to lower the anchor size too. In the current proposal,
the channel initiator pays for both anchors. They basically give away a
little bit of money to the non-initiator via the non-initiator anchor
output. If those anchors have become expensive because btc is expensive, it
would be nice to choose a lower value (as far as permitted by the dust
limit).


> That said, I think it'd be a nice thing for LN implementations to strive
> to create anchor outputs that are economical to spend and that may
> require using a negotiable output amount to compensate for rises in
> feerates making small-value outputs less economical, especially if
> you're using different anchor outputs for each channel party.
>

On the one hand, we'd want them to be economical to not create dust. But on
the other hand because it is free money too, we also want them to be as
small as possible (as mentioned above). I would think that an individual
running a node is more concerned with their balance than the quality of the
utxo set.

So far, the following factors/events were mentioned that could lead to
unhappiness about a hard-coded anchor value (hopefully this is complete and
correct now):

A. Dust limit rises: need bigger anchors to get commitment transactions
accepted (arguably unlikely to happen).
B. Btc price goes up, dust limit goes down: may want smaller anchors to
reduce amount (in fiat terms) of free money given to the non-initiator
C. Fee rates go up: need bigger anchors to make them economical to spend
and prevent them from filling up the utxo set.

Introducing a new parameter in the channel opening sequence that sets the
anchor size would keep all options open. I would be comfortable with doing
that and knowing we won't need changes if any of the three scenarios above
play out.

Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191119/8419eb62/attachment.html>