Hey laolu,
I think this fits in nicely with the "parameter re-negotiation" portion of
> my
> loose Dynamic commitments proposal.
Yes, maybe it's better to not offer two mechanisms and wait for dynamic
commitments to offer that
flexibility.
Instead, you may
> want to only allow them to utilize s
> I suggest adding tlv records in `commitment_signed` to tell our channel >
> peer that we're changing the values of these fields.
I think this fits in nicely with the "parameter re-negotiation" portion of
my
loose Dynamic commitments proposal. Note that in that paradigm, something
like this would
Good morning,
For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
>
Good morning t-bast,
> Hey Zman,
>
> > raising the minimum payment size is another headache
>
> It's true that it may (depending on the algorithm) lower the success rate of
> MPP-split.
> But it's already a parameter that node operators can configure at will (at
> channel creation time),
> so IM
Hey Zman,
raising the minimum payment size is another headache
>
It's true that it may (depending on the algorithm) lower the success rate
of MPP-split.
But it's already a parameter that node operators can configure at will (at
channel creation time),
so IMO it's a complexity we have to deal with
Good morning t-bast,
> 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 dir
> 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
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 d
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
Hello Bastien,
As a first note , I was thinking dynamic policy adjustment would be covered
by the dynamic commitment mechanism proposed by Laolu as it presents the
same trade-offs, you need to stop channel HTLC processing before upgrading,
otherwise it might falsify your whole in-flight HTLC accou
Good evening list,
Recent discussions around channel jamming [1] have highlighted again the
need to think twice when
configuring your channels parameters. There are currently parameters that
are set once at channel
creation that would benefit a lot from being configurable throughout the
lifetime o
11 matches
Mail list logo
