>
> Right, that was my above point about fetching scoring data - there's three
> relevant "buckets" of
> nodes, I think - (a) large nodes sending lots of payments, like the above,
> (b) "client nodes" that
> just connect to an LSP or two, (c) nodes that route some but don't send a
> lot of
>
> I think the performance question depends on the type of payment flows
> considered. If you're an
> end-user sending a payment to your local Starbucks for coffee, here fast
> payment sounds the end-goal.
> If you're doing remittance payment, cheap fees might be favored, and in
> function of
>
> But how do you decide to set it without a credit relationship? Do I
> measure my channel and set the
>
bit because the channel is "usually" (at what threshold?) saturating in the
> inbound direction? What
> happens if this changes for an hour and I get unlucky? Did I just screw
> myself?
>
As
Hi Christian,
> And after all this rambling, let's get back to the topic at hand: I
> don't think enshrining the differences of availability in the protocol,
> thus creating two classes of nodes, is a desirable
> feature.
Yes so to be clear, the HA signaling is not on the node level but on the
Hi Matt,
If nodes start aggressively preferring routes through nodes that reliably
> route payments (which I believe lnd already does, in effect, to some large
> extent), they should do so by measurement, not signaling.
>
The signaling is intended as a way to make measurement more efficient. If
Hi,
For a long time I've held the expectation that eventually payers on the
lightning network will become very strict about node performance. That they
will require a routing node to operate flawlessly or else apply a hefty
penalty such as completely avoiding the node for an extended period of
Hi Antoine,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
> limits, in opposition to the "static" ones declared to your counterparty
> during channel opening (within the protocol-limit of 483). On top, you can
> rate-limit the HTLCs forwards based on the incoming
A simple but imperfect way to deal with channel jamming and spamming is to
install a lightning firewall such as circuitbreaker [1]. It allows you to
set limits like a maximum number of pending htlcs (fight jamming) and/or a
rate limit (fight spamming). Incoming htlcs that exceed one of the limits
Pushed a golang implementation of the fat errors here:
https://github.com/lightningnetwork/lightning-onion/pull/60
Joost.
On Wed, Oct 19, 2022 at 1:12 PM Joost Jager wrote:
> Hi list,
>
> I wanted to get back to a long-standing issue in Lightning: gaps in error
> attribution. I've
Hi Thomas,
This is a very interesting proposal that elegantly solves the problem, with
> however a very significant size increase. I can see two ways to keep the
> size small:
> - Each node just adds its hmac in a naive way, without deleting any part
> of the message to relay. You seem to have
invasive than
just touching encode/relay/decode of the failure message. You also won't
have the timing information to identify slow nodes on the path.
Joost.
On Tue, Oct 25, 2022 at 9:58 PM Rusty Russell wrote:
> Joost Jager writes:
> > Hi list,
> >
> > I wanted to get back to
ctly reliable nodes
> > from being used for future payments.
>
> Eclair's code does not penalize nodes for future payment attempts in this
> case. It only ignores them for the retries of that particular payment.
>
> Cheers,
> Bastien
>
> Le mer. 19 oct. 2022 à 13:13, Joost
Hi list,
I wanted to get back to a long-standing issue in Lightning: gaps in error
attribution. I've posted about this before back in 2019 [1].
Error attribution is important to properly penalize nodes after a payment
failure occurs. The goal of the penalty is to give the next attempt a
better
On Sun, Jul 10, 2022 at 9:14 PM Matt Corallo
wrote:
> > It can also be considered a bad thing that DoS ability is not based on a
> number of messages. It
> > means that for the one time cost of channel open/close, the attacker can
> generate spam forever if
> > they stay right below the rate
On Thu, Jun 30, 2022 at 4:19 AM Matt Corallo
wrote:
> Better yet, as Val points out, requiring a channel to relay onion messages
> puts a very real,
> nontrivial (in a world of msats) cost to getting an onion messaging
> channel. Better yet, with
> backpressure ability to DoS onion message links
On Fri, Jul 1, 2022 at 2:17 PM Thomas HUET wrote:
> It was discussed in this issue:
> https://github.com/lightning/bolts/issues/835
>
Ah yes that was it. Thanks for the pointer!
> On the network, the traffic is not balanced. Some nodes tend to receive
> more than they send, merchants for
>
> > 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
could
> arbitrarily
> DoS Bob's payments by setting a high fee. This is just one example of the
> many
> ways this idea completely breaks the routing incentives.
>
> Cheers,
> Bastien
>
> Le ven. 1 juil. 2022 à 13:10, Joost Jager a
> écrit :
>
>> Path-finding alg
>
> 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
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
Hi Rusty,
Nice to see the proposal in more concrete terms. Few questions:
- The total proved utxo value (not counting any utxos which are spent)
> is multiplied by 10 to give the "announcable_channel_capacity" for that
> node.
>
Could this work as a dynamic value too, similar to the minimum
Hi fiatjaf and peter,
On Sat, Dec 18, 2021 at 2:08 PM fiatjaf wrote:
> As a temporary solution, I suggest taking a look at
> https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that
> you can either provide
> - a lone pubkey (to be used for manually identifying the payer later if
Hello list,
In Lightning we have a great scheme to protect the identity of the sender
of a payment. This is awesome, but there are also use cases where opt-in
sender authentication is desired.
An example of such a use case is chat over lightning. If you receive a text
message, you generally want
On Mon, Nov 22, 2021 at 5:11 PM Stefan Richter
wrote:
> I also don't believe putting a choice of more or less seconds expectation
> in the UI makes for a great user experience. IMHO the goal should just be:
> give the user an estimate of fees necessary to succeed within a reasonable
> time.
On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj wrote:
> Good morning Dave,
>
> > If LN software speculatively chooses a series of attempts with a similar
> > 95%, accounting for things like the probability of a stuck payment (made
> > worse by longer CLTV timeouts on some paths), it could present
. that can support this.
Joost.
On Mon, Nov 15, 2021 at 4:25 PM Joost Jager wrote:
> In Lightning pathfinding the two main variables to optimize for are
> routing fee and reliability. Routing fee is concrete. It is the sat amount
> that is paid when a payment succeeds. Reliability is a
Hi Rene,
> First I am happy that you also agree that reliability can and should be
> expressed as a probability as discussed in [0].
>
Probability based routing is not new to me. I've implemented a form of that
in lnd in march 2019: https://github.com/lightningnetwork/lnd/pull/2802,
followed by
In Lightning pathfinding the two main variables to optimize for are routing
fee and reliability. Routing fee is concrete. It is the sat amount that is
paid when a payment succeeds. Reliability is a property of a route that can
be expressed as a probability. The probability that a route will be
On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote:
> Good morning Joost,
>
> > A potential downside of a dedicated probe message is that it could be
> used for free messaging on lightning by including additional data in the
> payload for the recipient. Free messaging is already possible today via
of the route in it and nodes can't see whether there is
other meaningful data at the end.
On Thu, Oct 14, 2021 at 9:48 AM Joost Jager wrote:
> A practice that is widely applied by lightning wallets is to probe routes
> with an unknown payment hash before making the actual payment. Probing
&g
>If it is a multipart and we have the preimage, wait for all the parts to
arrive, then say yes to all of them.
Without actual reservations made in the channels, is this going to work?
For example: a 10M payment and a route that contains a channel with only 5M
balance. The sender's multi-path
There could be some corners where the incentives may not work out 100%, but
I doubt that any routing node would bother exploiting this. Especially
because there could always be that reputation scheme at the sender side
which may cost the routing node a lot more in lost routing fees than the
>
> > On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
> >
> > > So how would things work out with a combination of both of the
> > > proposals described in this mail? First we make probing free (free as
> > > in no liquidity locked
On Fri, Oct 15, 2021 at 4:21 PM Owen Gunden wrote:
> On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
> > So how would things work out with a combination of both of the
> > proposals described in this mail? First we make probing free (free as
> > in n
A practice that is widely applied by lightning wallets is to probe routes
with an unknown payment hash before making the actual payment. Probing
yields an accurate routing fee that can be shown to the user before
execution of the payment.
The downside of this style of probing is that for a short
>
> > The conventional approach is to create a lightning invoice on a node and
> > store the invoice together with order details in a database. If the order
> > then goes unfulfilled, cleaning processes remove the data from the node
> > and database again.
>
> > The problem with this setup is that
On Tue, Sep 21, 2021 at 5:47 PM Bastien TEINTURIER wrote:
> Hi Joost,
>
> Concept ACK, I had toyed with something similar a while ago, but I hadn't
> realized
> that invoice storage was such a DoS vector for merchants/hubs and wasn't
> sure it
> would be useful.
>
Yes, I definitely think it is.
On Tue, Sep 21, 2021 at 3:06 PM fiatjaf wrote:
> I would say, however, that these are two separate proposals:
>
> 1. implementations should expose a "stateless invoice" API for receiving
> using the payment_secret;
> 2. when sending, implementations should attach a TLV record with encoded
>
On Tue, Sep 21, 2021 at 2:05 PM fiatjaf wrote:
> What if instead of the payer generating the preimage the payee could
> generate stateless invoices? Basically just use some secret to compute the
> preimage upon receiving the HTLC, for example:
>
Maybe my explanation wasn't clear enough, but
Problem
One of the qualities of lightning is that it can provide light-weight,
no-login payments with minimal friction. Games, paywalls, podcasts, etc can
immediately present a QR code that is ready for scan and pay.
Optimistically presenting payment requests does lead to many of those
payment
>
> But Joost pointed out that you need to know the node_id of the next node
> though: this isn't quite true, since if the node_id is wrong the spec
> says you should send an `update_fail_malformed_htlc` with failure code
> invalid_onion_hmac, which node N turns into its own failure message.
>
>
> This struck me as an extremely salient point. One thing that has been
> noticeable missing from these discussions is any sort of threat model or
> attacker
> profile. Given this is primarily a griefing attack, and the attacker
> doesn't
> stand any direct gain, how high a fee is considered
.
Joost
On Thu, Feb 11, 2021 at 3:28 PM Joost Jager wrote:
> Hi all,
>
> Things have been quiet around channel jamming lately, but the
> vulnerability it still there as much as it was before. I've participated in
> an (isolated) mainnet channel jamming experiment (
> https://b
cally outlaw micropayments. If we think channel
> jamming is concerning enough in the short-term, we can deploy a
> bidirectional upfront payment-style of proposal now and consider a better
> solution when it's technically mature.
>
>
> Antoine
>
> Le jeu. 11 févr. 2021 à 10
Hi Antoine,
That said, routing nodes might still include the risk of hitting the chain
> in the computation of their `hodl_fee_rate` and the corresponding cost of
> having onchain timelocked funds.
>
Yes, that could be another reason to define `hodl_fee_rate` as a base fee
rate plus a component
Hi ZmnSCPxj,
Not quite up-to-speed back into this, but, I believe an issue with using
> feerates rather than fixed fees is "what happens if a channel is forced
> onchain"?
>
> Suppose after C offers the HTLC to D, the C-D channel, for any reason, is
> forced onchain, and the blockchain is bloated
Hi all,
Things have been quiet around channel jamming lately, but the vulnerability
it still there as much as it was before. I've participated in an (isolated)
mainnet channel jamming experiment (
Hi Bastien,
I brought up the question about the amounts because it could be that
>> amounts high enough to thwart attacks are too high for honest users or
>> certain uses.
>
>
> I don't think this is a concern for this proposal, unless there's an
> attack vector I missed.
> The reason I claim
>
> It is interesting that the forward and backward payments are relatively
>> independent of each other
>
>
> To explain this further, I think it's important to highlight that the
> forward fee is meant to fight
> `uncontrolled spam` (where the recipient is an honest node) while the
> backward
Hi Bastien,
We add a forward upfront payment of 1 msat (fixed) that is paid
> unconditionally when offering an HTLC.
> We add a backwards upfront payment of `hold_fees` that is paid when
> receiving an HTLC, but refunded
> if the HTLC is settled before the `hold_grace_period` ends (see footnotes
Hi Bastien,
Thanks for creating the summary!
While doing this exercise, I couldn't find a reason why the `reverse
> upfront payment` proposal
> would be broken (notice that I described it using a flat amount after a
> grace period, not an amount
> based on the time HTLCs are held). Can someone
>
> > We've looked at all kinds of trustless payment schemes to keep users
>
> > honest, but it appears that none of them is satisfactory. Maybe it is
> even
> > theoretically impossible to create a scheme that is trustless and has
> all
> > the properties that we're looking for. (A proof of that
>
> > If I were LOW-REP, I'd still charge an unknown node a hold fee. I
> > would only waive the hold fee for high-reputation nodes. In that case,
> > the attacker is still paying for the attack. I may be forced to take a
> > small loss on the difference, but at least the larger part of the pain
>
>
> > The idea is that the available prepaid hold fee balance is enough to
> cover the worst case hold fee. Otherwise the forward won't happen. The main
> difference with option B is that you pay a sum upfront which can be used to
> cover multiple forwards. And that this payment is a separate
>
> > A crucial thing is that these hold fees don't need to be symmetric. A new
> > node for example that opens a channel to a well-known, established
> routing
> > node will be forced to pay a hold fee, but won't see any traffic coming
> in
> > anymore if it announces a hold fee itself. Nodes
>
> > A. Prepayment: node pays an amount to its channel peer (for example via
> keysend) and the channel peer deducts the hold fees from that prepaid
> balance until it is at zero. At that point it somehow (in the htlc fail
> message?) communicates Lightning's version of http 402 to ask for more
>
Hello list,
Many discussions have taken place on this list on how to prevent undesired
use of the Lightning network. Spamming the network with HTLCs (for probing
purposes or otherwise) or holding HTLCs to incapacitate channels can be
done on today's network at very little cost to an attacker. So
Hi all,
Within our team, we've been discussing the subject of preventing
liquidity-consuming spam (aka channel jamming) further. One idea came up
that I think is worth sharing.
Previous prepay ideas were based on the sender paying something up-front in
case the htlc causes grief on the network.
>
> 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
>
>
> >> > Isn't spam something that can also be addressed by using rate limits
> for
> >> > failures? If all relevant nodes on the network employ rate limits,
> they
> >> can
> >> > isolate the spammer and diminish their disruptive abilities.
> >>
> >> Sure, once the spammer has jammed up the
>
> > The goal of this pre-payment proposal is to remove the need for
> > trusted parties
> >
> > Trust isn't the right word. It is a level of service that you provide
> > to your peers. If nodes are cognizant of the fact that the level of
> > service they receive goes down if they forward
On Thu, Nov 7, 2019 at 3:36 PM lisa neigut wrote:
> > Imagine the following setup: a network of nodes that trust each other
>
> The goal of this pre-payment proposal is to remove the need for trusted
> parties
>
Trust isn't the right word. It is a level of service that you provide to
your
>
> > 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
>
> > Isn't spam something that can also be addressed by using rate limits for
> > failures? If all relevant nodes on the network employ rate limits, they
> can
> > isolate the spammer and diminish their disruptive abilities.
>
> Sure, once the spammer has jammed up the network, he'll be stopped.
In my opinion, the prepayment should be a last resort. It does take away
some of the attractiveness of the Lightning Network. Especially if you need
to make many payment attempts over long routes, the tiny prepays do add up.
For a $10 payment, it's probably nothing to worry about. But for
>
> On Oct 30, 2019, at 06:04, Joost Jager wrote:
>
> > For the anchor outputs we consider:
>> >
>> > * Output type: normal P2WKH. At one point, an additional spending path
>> was
>> > proposed that was unconditional except for a 10 block csv lock
>
> * Output type: normal P2WKH. At one point, an additional spending path was
> proposed that was unconditional except for a 10 block csv lock. The
> intention of this was to prevent utxo set pollution by allowing anyone to
> clean up. This however also opens up the possibility for an attacker to
We started to look at the `push_me` outputs again. Will refer to them as
`anchor` outputs from now on, to prevent confusion with `push_msat` on the
`open_channel` message.
The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been
merged and for reasons described earlier in this
Hi ZmnSCPxj,
Since, B cannot report the `update_fail_htlc` immediately, its timer should
> still be running.
> Suppose we counted only up to `update_fail_htlc` and not on the
> `revoke_and_ack`.
> If C sends `update_fail_htlc` immediately, then the
> `update_add_htlc`->`update_fail_htlc` time
Hi Bastien,
> What about having each node add some padding along the way? The erring
> node's padding should be bigger than intermediate nodes' padding (ideally
> using a deterministic construction as you suggest) so details need to be
> fleshed out, but it could mitigate even more the
Hi ZmnSCPxj,
> > That is definitely a concern. It is up to senders how to interpret the
> received timestamps. They can decide to tolerate slight variations. Or they
> could just look at the difference between the in and out timestamp,
> abandoning the synchronization requirement altogether (a
Hi ZmnSCPxj,
Before proceeding with discussing HMACs and preventing nodes from putting
> words in the mouths of other nodes, perhaps we should consider, how we can
> ensure that nodes can be forced to be accurate about what happened.
>
> For instance, a proposal is for nodes to put timestamps for
Hello list,
In Lightning, the reliability of payments is dependent on the reliability
of the chosen route. Information about previous payment attempts helps to
select better routes and improve the payment experience. Therefore
implementations usually track the past performance of nodes and
Hi all,
In https://github.com/lightningnetwork/lightning-rfc/pull/516,
the incorrect_or_unknown_payment_details failure message is extended with
an htlc_msat field and thereby replaces the former incorrect_payment_amount
message. The objective of this change is to prevent a probing attack that
On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell wrote:
> The decision was made to allow additional channel_update in the error
> reply:
>
> DECISION: document that scid is not binding, allow extra
> channel_updates in errors for “upselling”.
>
Yes, I read this. What exactly is
Hello all,
I'd like to bring up an idea that builds on top of "non-strict" forwarding.
I commented about this on conner's non-strict forwarding lightning-rfc pr,
but it is probably better to discuss it on its own in this list.
A node that forwards non-strictly, is using any of its channels to
76 matches
Mail list logo
