Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-07 📝 Original message: > > > We could > > ...
📅 Original date posted:2019-11-07
📝 Original message:
>
> > We could
> > simplify this to a single to_self_delay that is proposed by the
> initiator,
> > but what was the original reason to allow distinct values?
>
> Because I didn't fight hard enough for simplicity :(
>
But the people you were fighting with, what reason did they have? Just
flexibility in general, or was there an actual use case? Maybe these people
are reading this email and can comment?
There is no "negotiation" on opening; it's accept or error. That leads
> to a situation where every implementation MUST accept what every
> implementation offers.
>
Agreed that the verb negotiate is a bit misleading. Although the
open/accept sequence could be repeated several times to make it more of a
negotiation.
> The unification proposal was to use the max of the two settings. That's
> fair; if you want me to suffer a 2 week delay, you should too.
>
Yes, we could do that as part of this new commitment format. Make that an
implicit consequence of `option_anchor_outputs` (or whatever its name will
be). The semantics need to change anyway, because we want that CSV lock on
every output.
> >> * Within each version of the commitment transaction, both anchors always
> >> > have equal values and are paid for by the initiator.
> >>
> >> Who pays if they can't afford it? What if they push_msat everything to
> >> the other side?
> >
> > Similar to how it currently works. There should never be a commitment
> > transaction in which the initiator cannot pay the fee.
>
> Unfortunately, this is not correct (in theory).
>
> We can always get into a case where fees are insufficient (simultanous
> HTLC adds), but it's unusual. We used to specify that the non-funder
> would pay the remaining fee, but we dropped this in favor of allow
> unilateral close if this ever happened.
>
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.
> > With anchor outputs
> > there should never be a commitment tx in which the initiator cannot pay
> the
> > fee and the anchors.
>
> There can be, but I think we can simply modify this so you have to pay
> the anchors *first* before fees.
>
That way it seems that adding the anchors doesn't make the stuck channel
problem that you described above worse?
> > 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.
> If we really want to make it adjustable, could we make each side pay for
> its own; if you can't afford it, you don't get one? There's no point
> the funder paying for a fundee-anchor if the fundee has no skin in the
> game.
>
> That reduces the pressure somewhat, I think?
>
If you can't afford you don't get one, not sure about that. I could open a
channel, send out the total capacity an in htlc to myself via some other
hops, force close with a very low commit fee, then pull in the htlc (one
time the money). The victim then needs to get the commit confirmed to claim
the money, but there is no anchor unfortunately. I wait for the htlc to
expire, then anchor down the commit tx and time out the htlc (twice the
money).
> > In the light of this forgotten insight, is there a reason why the anchor
> > output would need key rotation? Having no rotation makes it easier to let
> > those anchors go straight into the wallet, which may mitigate the dust
> utxo
> > problem a bit. At least then they can be easily coin-selected for any
> > on-chain spent, if the market fees are low enough.
>
> Or what about we rotate the anchors and nothing else, which (assuming we
> make it anyone-can-spend-after-N-blocks) reduces the amount of onchain
> spam if someone completely loses their keys?
>
> That's a bigger change, but maybe it's worth it?
>
We now have David's great proposal to reuse the funding keys for the anchor
output. That allows us to always let anyone spend after confirmation,
because they can reconstruct the spend script. But I think this also means
that we cannot do rotation on the anchor keys. We need to use the funding
pubkey as is.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191107/5f5f2d36/attachment.html>;
📝 Original message:
>
> > We could
> > simplify this to a single to_self_delay that is proposed by the
> initiator,
> > but what was the original reason to allow distinct values?
>
> Because I didn't fight hard enough for simplicity :(
>
But the people you were fighting with, what reason did they have? Just
flexibility in general, or was there an actual use case? Maybe these people
are reading this email and can comment?
There is no "negotiation" on opening; it's accept or error. That leads
> to a situation where every implementation MUST accept what every
> implementation offers.
>
Agreed that the verb negotiate is a bit misleading. Although the
open/accept sequence could be repeated several times to make it more of a
negotiation.
> The unification proposal was to use the max of the two settings. That's
> fair; if you want me to suffer a 2 week delay, you should too.
>
Yes, we could do that as part of this new commitment format. Make that an
implicit consequence of `option_anchor_outputs` (or whatever its name will
be). The semantics need to change anyway, because we want that CSV lock on
every output.
> >> * Within each version of the commitment transaction, both anchors always
> >> > have equal values and are paid for by the initiator.
> >>
> >> Who pays if they can't afford it? What if they push_msat everything to
> >> the other side?
> >
> > Similar to how it currently works. There should never be a commitment
> > transaction in which the initiator cannot pay the fee.
>
> Unfortunately, this is not correct (in theory).
>
> We can always get into a case where fees are insufficient (simultanous
> HTLC adds), but it's unusual. We used to specify that the non-funder
> would pay the remaining fee, but we dropped this in favor of allow
> unilateral close if this ever happened.
>
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.
> > With anchor outputs
> > there should never be a commitment tx in which the initiator cannot pay
> the
> > fee and the anchors.
>
> There can be, but I think we can simply modify this so you have to pay
> the anchors *first* before fees.
>
That way it seems that adding the anchors doesn't make the stuck channel
problem that you described above worse?
> > 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.
> If we really want to make it adjustable, could we make each side pay for
> its own; if you can't afford it, you don't get one? There's no point
> the funder paying for a fundee-anchor if the fundee has no skin in the
> game.
>
> That reduces the pressure somewhat, I think?
>
If you can't afford you don't get one, not sure about that. I could open a
channel, send out the total capacity an in htlc to myself via some other
hops, force close with a very low commit fee, then pull in the htlc (one
time the money). The victim then needs to get the commit confirmed to claim
the money, but there is no anchor unfortunately. I wait for the htlc to
expire, then anchor down the commit tx and time out the htlc (twice the
money).
> > In the light of this forgotten insight, is there a reason why the anchor
> > output would need key rotation? Having no rotation makes it easier to let
> > those anchors go straight into the wallet, which may mitigate the dust
> utxo
> > problem a bit. At least then they can be easily coin-selected for any
> > on-chain spent, if the market fees are low enough.
>
> Or what about we rotate the anchors and nothing else, which (assuming we
> make it anyone-can-spend-after-N-blocks) reduces the amount of onchain
> spam if someone completely loses their keys?
>
> That's a bigger change, but maybe it's worth it?
>
We now have David's great proposal to reuse the funding keys for the anchor
output. That allows us to always let anyone spend after confirmation,
because they can reconstruct the spend script. But I think this also means
that we cannot do rotation on the anchor keys. We need to use the funding
pubkey as is.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191107/5f5f2d36/attachment.html>;