Currently routing nodes on the lightning network charge fees based on a
policy that pertains to the outgoing channel only.
Several mentions have been made by routing node operators that this limits
the control that they can exert over the flow of traffic. The movement of
funds on all of the
>
> Path-finding algorithms that are currently in use generally don’t support
> negative fees. But in this case, the sum of inbound and outbound fees is
> still positive and therefore not a problem. If routing nodes set their
> policies accidentally or intentionally so that the sum of fees turns
Hi Joost,
As I've already stated every time this has been previously discussed, I
believe
this doesn't make any sense. The funds that are on the other side of the
channel belong to your peer, not you, so they're free to use it however they
want. If you're not happy with the way your peer is
Hi Bastien,
I vaguely remembered that the idea of inbound fees had been discussed
before. Before writing my post, I scanned through old ML posts and bolts
issues but couldn't find the discussion. Maybe it was part of a different
but related email or a bolts pr?
With regards to your objections,
Hi Joost,
It was discussed in this issue:
https://github.com/lightning/bolts/issues/835
On the network, the traffic is not balanced. Some nodes tend to receive
more than they send, merchants for instance. For the lightning network to
be reliable, we need to incentivise people to open channels to
Hi Joost,
> isn't it the case that it is always possible to DoS your peer by just
rejecting any forward that comes in from them?
Yes, this is a good point. But there is a difference though. If you do that
with inbound fees, the "malicious" peer is able to prevent _everyone_ from
even trying to
> That's not 100% reliable at all. How long to you want for the new
gossip?
So you know it's a new channel, with a new capacity (look at the on-chain
output), between the same parties (assuming ppl use that multi-sig signal).
If
you attempt to route over it and have a stale policy, you'll get
Hi Val,
> Another huge win of backpressure is that it only needs to happen in DoS
> situations, meaning it doesn’t have to impact users in the normal case.
I agree, I think the same would apply to prepayments as well (0 or 1 msat in
calm times). My main concern with relying _only_ on
Good morning Michael,
> Hey ZmnSCPxj
>
> It is an interesting topic. Alex Bosworth did a presentation at the Lightning
> Hack Day last year with a similar attempt at categorizing the different
> strategies for a routing/forwarding node (Ping Pong, Liquidity Battery,
> Inbound Sourcing,
Hi Matt,
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable cost that an attacker cares about without
> impacting the system's usability due to said cost.
Applying this statement to related a area, would you also agree that
proposals
to introduce
Hi y'all,
Quick post...
A few weeks ago, some of the dlcspecs developers reached out to ask for
feedback on this PR [1] that attempts to specify a way to send messages
larger
than 65 KB using BOLT 8 (Noise based encrypted transport). After taking a
glance at the PR, I realized that it isn't
Hi Lisa,
> Adding a noticeable on-chain signal runs counter to the goal of the move
> to taproot / gossip v2, which is to make lightning's onchain footprint
> indistinguishable from any other onchain usage
My model of gossip v2 is something like:
* there's no longer a 1:1 mapping of channels
12 matches
Mail list logo
