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

[Bastien TEINTURIER]

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/22e78ab2/attachment-0001.html>