[Lightning-dev] Making (some) channel limits dynamic

[Antoine Riard]

> There is no need to stop the channel's operations while you're updating
these parameters, since
they can be updated unilaterally anyway

I think it's just how you defne channel's operations, either emptying out
all pending HTLCs or more a `update_fee` alike semantic. You're right that
the latter should be good enough for the set of parameters you're proposing.
A lightweight `update_policy` doesn't sound to bear difficulty at first
sight.

Le jeu. 8 oct. 2020 à 08:23, Bastien TEINTURIER <bastien at acinq.fr> a écrit :

> Good morning Antoine and Zman,
>
> Thanks for your answers!
>
> I was thinking dynamic policy adjustment would be covered by the dynamic
>> commitment mechanism proposed by Laolu
>
>
> I didn't mention this as I think we still have a long-ish way to go before
> dynamic commitments
> are spec-ed, implemented and deployed, and I think the parameters I'm
> interested in don't require
> that complexity to be updated.
>
> Please forget about channel jamming, upfront fees et al and simply
> consider the parameters I'm
> mentioning. It feels to me that these are by nature dynamic channel
> parameters (some of them are
> even present in `channel_update`, but no-one updates them yet because
> direct peers don't take the
> update into account anyway). I'd like to raise `htlc_minimum_msat` on some
> big channels because
> I'd like these channels to be used only for big-ish payments. Today I
> can't, I have to close that
> channel and open a new one for such a trivial configuration update, which
> is sad.
>
> There is no need to stop the channel's operations while you're updating
> these parameters, since
> they can be updated unilaterally anyway. The only downside is that if you
> make your policy stricter,
> your peer may send you some HTLCs that you will immediately fail
> afterwards; it's only a minor
> inconvenience that won't trigger a channel closure.
>
> I'd like to know if other implementations than eclair have specificities
> that would make this
> feature particularly hard to implement or undesirable.
>
> Thanks,
> Bastien
>
> Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
>
>> Good morning Antoine, and Bastien,
>>
>>
>> > Instead of relying on reputation, the other alternative is just to have
>> an upfront payment system, where a relay node doesn't have to account for a
>> HTLC issuer reputation to decide acceptance and can just forward a HTLC as
>> long it paid enough. More, I think it's better to mitigate jamming with a
>> fees-based system than a web-of-trust one, less burden on network newcomers.
>>
>> Let us consider some of the complications here.
>>
>> A newcomer wants to make an outgoing payment.
>> Speculatively, it connects to some existing nodes based on some policy.
>>
>> Now, since forwarding is upfront, the newcomer fears that the node it
>> connected to might not even bother forwarding the payment, and instead just
>> fail it and claim the upfront fees.
>>
>> In particular: how would the newcomer offer upfront fees to a node it is
>> not directly channeled with?
>> In order to do that, we would have to offer the upfront fees for that
>> node, to the node we *are* channeled with, so it can forward this as well.
>>
>> * We can give the upfront fee outright to the first hop, and trust that
>> if it forwards, it will also forward the upfront fee for the next hop.
>>   * The first hop would then prefer to just fail the HTLC then and there
>> and steal all the upfront fees.
>>     * After all, the offerrer is a newcomer, and might be the sybil of a
>> hacker that is trying to tie up its liquidity.
>>       The first hop would (1) avoid this risk and (2) earn more upfront
>> fees because it does not forward those fees to later hops.
>>   * This is arguably custodial and not your keys not your coins applies.
>>     Thus, it returns us back to tr\*st anyway.
>> * We can require that the first hop prove *where* along the route errored.
>>  If it provably failed at a later hop, then the first hop can claim more
>> as upfront fees, since it will forward the upfront fees to the later hop as
>> well.
>>   * This has to be enforcable onchain in case the channel gets dropped
>> onchain.
>>     Is there a proposal SCRIPT which can enforce this?
>>   * If not enforcable onchain, then there may be onchain shenanigans
>> possible and thus this solution might introduce an attack vector even as it
>> fixes another.
>>     * On the other hand, sub-satoshi amounts are not enforcable onchain
>> too, and nobody cares, so...
>>
>> On the other hand, a web-of-tr\*st might not be *that* bad.
>>
>> One can say that "tr\*st is risk", and consider that the size and age of
>> a channel to a peer represents your tr\*st that that peer will behave
>> correctly for fast and timely resolution of payments.
>> And anyone can look at the blockchain and the network gossip to get an
>> idea of who is generally considered tr\*stworthy, and since that
>> information is backed by Bitcoins locked in channels, this is reasonably
>> hard to fake.
>>
>> On the other hand, this risks centralization around existing, long-lived
>> nodes.
>> *Sigh*.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201008/4fe5af26/attachment-0001.html>