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

[Matt Corallo]

Regarding your list,
A. Indeed, unlikely to happen.
B. Maybe, but we’re talking a 10x increase so that suddenly you’re paying some extra pennies. In the scale of likelihood, and in the scale of what fees will be anyway, this doesn’t matter.
C. You still seem to have missed the point that they need to be economical *eventually *, at the mempool’s lowest. That is hugely different from “fees increasing”. I really don’t think the history here supports your position.

At a high level, you seem to be completely discounting the cost of complexity in the protocol. Lightning already has way too many values you have to negotiate with your counterparty, and the state machine is already complicated enough that three groups of talented developers failed to check key parameters during state transitions!

If at all possible, the answer should be “remove more crap from the state machine”, not “well, we’re like 95% sure this is fine, let’s just heap on the complexity”. Not only does this fly in the face of any reasonable definition of “good engineering practice”, but the cost to change it later is relatively low!

We’re rewriting the state machine and transaction format now, let’s learn from the past few years, not pretend everything is perfect.

Matt

> On Nov 19, 2019, at 08:47, Joost Jager <joost.jager at gmail.com> wrote:
> 
> 
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191119/3483a0e2/attachment.html>