Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-11 📝 Original message: Joost Jager <joost.jager ...
📅 Original date posted:2019-11-11
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> > 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?
Compromise among the committee meant adding everything to the spec if
there was a conceivable reason for it; the simplicity argument was less
strong then (maybe because we hadn't implemented it all yet!).
> 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.
>> > 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.
>> 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).
Excellent point. And the complexity of some "you can only use a little
bit of capacity until I have an anchor too" is worse, so let's stick
with your proposal as the simplest: funder pays for two, always.
>> 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.
I missed that proposal, thanks!
It's stronger than my scheme, in that it works even if neither anchor is
spent; which, if we keep update_fee, is a distinct possibility. And
makes the script shorter (my fee calc above assume this).
We *could* tweak both anchors by the same amount, but then you'd still
need to see one of them to spend the other.
Cheers,
Rusty.
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>>
>> > 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?
Compromise among the committee meant adding everything to the spec if
there was a conceivable reason for it; the simplicity argument was less
strong then (maybe because we hadn't implemented it all yet!).
> 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.
>> > 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.
>> 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).
Excellent point. And the complexity of some "you can only use a little
bit of capacity until I have an anchor too" is worse, so let's stick
with your proposal as the simplest: funder pays for two, always.
>> 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.
I missed that proposal, thanks!
It's stronger than my scheme, in that it works even if neither anchor is
spent; which, if we keep update_fee, is a distinct possibility. And
makes the script shorter (my fee calc above assume this).
We *could* tweak both anchors by the same amount, but then you'd still
need to see one of them to spend the other.
Cheers,
Rusty.