Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning t-bast,

> > An issue with the bidirectional upfront/hold fees is related to trustless 
> > offchain-to-onchain swaps, like Boltz and Lightning Loop.
> > As the claiming of the offchain side is dependent on claiming of the 
> > onchain side of the trustless swap mechanism, which is *definitely* slow, 
> > the swap service will in general be forced to pay up the hold fees.
>
> Yes, that is a good observation.
> But shouldn't the swap service take that into account in the fee it collects 
> to
> perform the swap? That way it is in fact the user who pays for that fee.

The user can wait for the swap service to put an onchain HTLC and then time it 
out.
Thus, the offchain/onchain swap service will pay for both the onchain HTLC and 
the hold fee.

This is fixed in e.g. Boltz by having a separate mining-fee invoice as well 
that must be paid before the offchain/onchain swap service will create the 
onchain HTLC.
This is why I thought it would be better to include the hold fee in the 
mining-fee invoice as well.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Bastien TEINTURIER via Lightning-dev]

Good morning Joost and Z,

So in your proposal, an htlc that is received by a routing node has the
> following properties:
> * htlc amount
> * forward up-front payment (anti-spam)
> * backward up-front payment (anti-hold)
> * grace period
> The routing node forwards this to the next hop with
> * lower htlc amount (to earn routing fees when the htlc settles)
> * lower forward up-front payment (to make sure that an attacker at the
> other end loses money when failing quickly)
> * higher backward up-front payment (to make sure that an attacker at the
> other end loses money when holding)
> * shorter grace period (so that there is time to fail back and not lose
> the backward up-front payment)


That's exactly it, this is a good summary.

An issue with the bidirectional upfront/hold fees is related to trustless
> offchain-to-onchain swaps, like Boltz and Lightning Loop.
> As the claiming of the offchain side is dependent on claiming of the
> onchain side of the trustless swap mechanism, which is *definitely* slow,
> the swap service will in general be forced to pay up the hold fees.


Yes, that is a good observation.
But shouldn't the swap service take that into account in the fee it
collects to
perform the swap? That way it is in fact the user who pays for that fee.

Cheers,
Bastien

Le mer. 28 oct. 2020 à 02:13, ZmnSCPxj  a écrit :

> Good morning Bastien, Joost, and all,
>
> An issue with the bidirectional upfront/hold fees is related to trustless
> offchain-to-onchain swaps, like Boltz and Lightning Loop.
>
> As the claiming of the offchain side is dependent on claiming of the
> onchain side of the trustless swap mechanism, which is *definitely* slow,
> the swap service will in general be forced to pay up the hold fees.
>
> It seems to me that the hold-fees mechanism cannot be ported over in the
> onchain side, so even if you set a "reasonable" grace period at the swap
> service of say 1 hour (and assuming forwarding nodes are OK with that
> humongous grace period!), the onchain side of the swap can delay the
> release of onchain.
>
> To mitigate against this, the swap service would need to issue a separate
> invoice to pay for the hold fee for the "real" swap payment.
> The Boltz protocol supports a separate mining-fee invoice (disabled on the
> Boltz production servers) that is issued after the invoice is "locked in"
> at the swap service, but I think that in view of the use of hold fee, a
> combined mining-fee+hold-fee invoice would have to be issued at the same
> time as the "real" swap invoice.
>
> Regards,
> ZmnSCPxj
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning Bastien, Joost, and all,

An issue with the bidirectional upfront/hold fees is related to trustless 
offchain-to-onchain swaps, like Boltz and Lightning Loop.

As the claiming of the offchain side is dependent on claiming of the onchain 
side of the trustless swap mechanism, which is *definitely* slow, the swap 
service will in general be forced to pay up the hold fees.

It seems to me that the hold-fees mechanism cannot be ported over in the 
onchain side, so even if you set a "reasonable" grace period at the swap 
service of say 1 hour (and assuming forwarding nodes are OK with that humongous 
grace period!), the onchain side of the swap can delay the release of onchain.

To mitigate against this, the swap service would need to issue a separate 
invoice to pay for the hold fee for the "real" swap payment.
The Boltz protocol supports a separate mining-fee invoice (disabled on the 
Boltz production servers) that is issued after the invoice is "locked in" at 
the swap service, but I think that in view of the use of hold fee, a combined 
mining-fee+hold-fee invoice would have to be issued at the same time as the 
"real" swap invoice.

Regards,
ZmnSCPxj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

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 that is that the backwards upfront payment can be made
> somewhat big without any
> negative impact on honest nodes.
>

Yes, that makes sense.


> But what happens if the attacker is also on the other end of the
>> uncontrolled spam payment? Not holding the payment, but still collecting
>> the forward payments?
>
>
> That's what I call short-lived `controlled spam`. In that case the
> attacker pays the forward fee at
> the beginning of the route but has it refunded at the end of the route. If
> the attacker doesn't
> want to lose any money, he has to release the HTLC before the grace period
> ends (which is going to
> be short-lived - at least compared to block times). This gives an
> opportunity for legitimate payments
> to use the HTLC slots (but it's a race between the attacker and the
> legitimate users).
>

I think indeed that this short-lived controlled spam also needs to be
brought under control. Otherwise it is still easy to jam a channel,
although it would need a continuous process to do it rather than sending a
bunch of 2000-block expiry htlcs. For the short-lived controlled spam there
is still a multiplier possible by making loops in the route. It is a race
with legitimate users, but if the spammer is efficient the probability of a
legitimate payment coming through is low. Similar to DDoS attacks where a
legitimate web request could make it to the server but probably doesn't.


> It's not ideal, because the attacker isn't penalized...the only way I
> think we can penalize this
> kind of attack is if the forward fee decrements at each hop, but in that
> case it needs to be in the
> onion (to avoid probing) and the delta needs to be high enough to actually
> penalize the attacker.
> Time to bikeshed some numbers!
>

So in your proposal, an htlc that is received by a routing node has the
following properties:
* htlc amount
* forward up-front payment (anti-spam)
* backward up-front payment (anti-hold)
* grace period

The routing node forwards this to the next hop with
* lower htlc amount (to earn routing fees when the htlc settles)
* lower forward up-front payment (to make sure that an attacker at the
other end loses money when failing quickly)
* higher backward up-front payment (to make sure that an attacker at the
other end loses money when holding)
* shorter grace period (so that there is time to fail back and not lose the
backward up-front payment)

On a high level, it seems to me that this can actually work.

- Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning Bastien,

> > C can trivially grief D here, making it look like D is delaying, by 
> > delaying its own `commitment_signed` containing the *removal* of the HTLC.
>
> You're right to dive into these, there may be something here.
> But I think your example doesn't work, let me know if I'm mistaken.
> D is the one who decides whether he'll be refunded or not, because D is the 
> first to send the
> `commit_sig` that removes the HTLC. I think we would extend `commit_sig` with 
> a tlv field that
> indicates "I refunded myself for HTLC N" to help C compute the same commit tx 
> and verify sigs.

D sending `commitment_signed` simply means C has the option to use either the 
previous commitment or the new one.
C can still drop the previous commitment, which has the hold fee still owned by 
C.

C only loses that option by sending `revoke_and_ack`, so C can still unfairly 
delay this, and at this point D is holding the previous commitment (which, as 
mentioned, has the hold fee still owned by C).
So C can still delay by not revoking its previous commitment (`revoke_and_ack`) 
and not signing the D-side next commitment (`commitment_signed`).

On the *other* hand if C can only *take* the hold fee at this point by dropping 
onchain, then the onchain fees and the loss of a viable channel (meaning the 
funds of C in that channel need to be put back into a new channel, again 
onchain fees) might very well dominate.
Is this enough of a deterrent?

On the other *other* hand, rules which involve "SHOULD/MUST fail the channel" 
have classically caused headaches in interop, xref. the mass channel closes 
between C-Lightning and lnd nodes some years ago due to sudden onchain fee 
movements.

-

On a mildly related note I have this old crap I wrote earlier this year, it 
might be possible to glean something from it:

* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002608.html


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Bastien TEINTURIER via Lightning-dev]

Hey Joost and Z,

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 that is that the backwards upfront payment can be made
somewhat big without any
negative impact on honest nodes. If you're an honest intermediate node,
only two cases are possible:

* your downstream peer settled the HTLC quickly (before the grace period
ends): in that case you
refund him his upfront fee, and you have time to settle the HTLC upstream
while still honoring
the grace period, so it will be refunded to you as well (unless you delay
the settlement upstream
for whatever reason, in which case you deserve to pay the hold_fee)
* your grace period has expired, so you can't get a refund upstream: if
that happens, the grace
period with your downstream node has also expired, so you're earning money
downstream and paying
money upstream, and you'll usually even take a small positive spread so
everything's good

The only node that can end up loosing money on the backwards upfront
payment is the last node in
the route. But that node should always settle the HTLC quickly (or decide
to hodl it, but in that
case it's normal that it pays the hold_fee).

But what happens if the attacker is also on the other end of the
> uncontrolled spam payment? Not holding the payment, but still collecting
> the forward payments?


That's what I call short-lived `controlled spam`. In that case the attacker
pays the forward fee at
the beginning of the route but has it refunded at the end of the route. If
the attacker doesn't
want to lose any money, he has to release the HTLC before the grace period
ends (which is going to
be short-lived - at least compared to block times). This gives an
opportunity for legitimate payments
to use the HTLC slots (but it's a race between the attacker and the
legitimate users).

It's not ideal, because the attacker isn't penalized...the only way I think
we can penalize this
kind of attack is if the forward fee decrements at each hop, but in that
case it needs to be in the
onion (to avoid probing) and the delta needs to be high enough to actually
penalize the attacker.
Time to bikeshed some numbers!

C can trivially grief D here, making it look like D is delaying, by
> delaying its own `commitment_signed` containing the *removal* of the HTLC.


You're right to dive into these, there may be something here.
But I think your example doesn't work, let me know if I'm mistaken.
D is the one who decides whether he'll be refunded or not, because D is the
first to send the
`commit_sig` that removes the HTLC. I think we would extend `commit_sig`
with a tlv field that
indicates "I refunded myself for HTLC N" to help C compute the same commit
tx and verify sigs.

I agree with you that the details of how we'll implement the grace period
may have griefing attacks
depending on how we do it, it's worth exploring further.

Cheers,
Bastien

Le ven. 23 oct. 2020 à 12:50, ZmnSCPxj  a écrit :

> Good morning t-bast,
>
>
> > > And in this case C earns.
> >
> > > Can C delay the refund to D to after the grace period even if D
> settled the HTLC quickly?
> >
> > Yes C earns, but D has misbehaved. As a final recipient, D isn't
> dependent on anyone downstream.
> > An honest D should settle the HTLC before the `grace_period` ends. If D
> chooses to hold the HTLC
> > for a while, then it's fair that he pays C for this.
>
>
> Okay, now let us consider the case where the supposedly-delaying party is
> not the final destination.
>
> So, suppose D indicates to C that it should fail the HTLC.
> In this case, C cannot immediately propagate the `update_fail_htlc`
> upstream, since the latest commitment transaction for the C<->D channel
> still contains the HTLC.
>
> In addition, our state machine is hand-over-hand, i.e. there is a small
> window where there are two valid commitment transactions.
> What happens is we sign the next commitment transaction and *then* revoke
> the previous one.
>
> So I think C can only safely propagate its own upstream `update_fail_htlc`
> once it receives the `revoke_and_ack` from D.
>
> So the time measured for the grace period between C and D should be from C
> sending `update_add_htlc` to C receiving `revoke_and_ack` from D, in case
> the HTLC fails.
> This is the time period that D is allowed to consume, and if it exceeds
> the grace period, it is penalized.
>
> (In this situation, it is immaterial if D is the destination: C cannot
> know this fact.)
>
> So let us diagram this better:
>
>  C   D
>  |update_add_htlc--->| ---
>  |---commitment_signed-->|  ^
>  |  |<--commitment_signed---|  |
>  |-revoke_and_ack--->|  |
>  |   | grace period
>  |<--update_fail_htlc|  |
>  |<--commitment_signed---|  |

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning t-bast,


> > And in this case C earns.
>
> > Can C delay the refund to D to after the grace period even if D settled the 
> > HTLC quickly?
>
> Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent on 
> anyone downstream.
> An honest D should settle the HTLC before the `grace_period` ends. If D 
> chooses to hold the HTLC
> for a while, then it's fair that he pays C for this.


Okay, now let us consider the case where the supposedly-delaying party is not 
the final destination.

So, suppose D indicates to C that it should fail the HTLC.
In this case, C cannot immediately propagate the `update_fail_htlc` upstream, 
since the latest commitment transaction for the C<->D channel still contains 
the HTLC.

In addition, our state machine is hand-over-hand, i.e. there is a small window 
where there are two valid commitment transactions.
What happens is we sign the next commitment transaction and *then* revoke the 
previous one.

So I think C can only safely propagate its own upstream `update_fail_htlc` once 
it receives the `revoke_and_ack` from D.

So the time measured for the grace period between C and D should be from C 
sending `update_add_htlc` to C receiving `revoke_and_ack` from D, in case the 
HTLC fails.
This is the time period that D is allowed to consume, and if it exceeds the 
grace period, it is penalized.

(In this situation, it is immaterial if D is the destination: C cannot know 
this fact.)

So let us diagram this better:

 C   D
 |update_add_htlc--->| ---
 |---commitment_signed-->|  ^
 ||  |
 |   | grace period
 |<--update_fail_htlc|  |
 |<--commitment_signed---|  |
 |-revoke_and_ack--->|  |
 |---commitment_signed-->|  v  <--- grief point!
 |`update_fail_htlc`->C and the corresponding 
C->`commitment_signed`->D becomes too long:
  * D drops the channel onchain.
* The dropped commitment tx still contains the HTLC, since it is the 
"previous" commitment that D happens to hold that has not yet had the 
`update_fail_htlc` committed.

If D performs the above, then C is forced to wait *even longer* (it has to wait 
out the HTLC timelock) before it can safely propagate the `update_fail_htlc`: D 
could be fooling with it and actually knows the preimage and claim it onchain, 
so C for its own safety *must* wait out the onchain timelock.

Does that make sense?
Does it sensibly protect against this griefing?
Is it too much of a punishment and could potentially hurt D more than it hurts 
C if C is a heavily-connected node that will not miss the channel while D has 
fewer channels and opened the C<->D channel in the first place?

--

For success case `update_fulfill_htlc`, I believe C can immediately propagate 
this back to its upstream since it can now.
Thus, in that case, we can stop the timer at the `update_fulfill_htlc`.

So at least for the *end point* of the grace period, I think the end point 
should be:

* If the HTLC failed:
  * When both participants have sent `revoke_and_ack`.
* If the HTLC succeeded:
  * When the downstream participant has sent `update_fulfill_htlc`.

For the *start point*, it seems the C->`commitment_signed`->D containing the 
HTLC would work as the start point.
In particular, it seems to me that C can also deliberately defer its own 
C->`revoke_and_ack`->D:

 C   D
 |update_add_htlc--->|
 |---commitment_signed-->| ---
 ||  |  <--- grief point!
 |   | grace period
 |<--update_fail_htlc|  |
 |<--commitment_signed---|  |
 |-revoke_and_ack--->|  |
 |---commitment_signed-->|  v
 |

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

>
> 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 fee is meant to fight
> `controlled spam` (where the recipient also belongs to the attacker).
>

Yes, that was clear. I just meant to say that we could choose to first only
implement the easier uncontrolled spam protection via the forward payment.
Not that any type of protocol upgrade is easy...

What I'd really like to explore is whether there is a type of spam that I
> missed or griefing attacks
> that appear because of the mechanisms I introduce. TBH I think the
> implementation details (amounts,
> grace periods and their deltas, when to start counting, etc) are things
> we'll be able to figure out
> collectively later.
>

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. If that is the case, we don't need to look for other
potential weaknesses. It is just a different order to explore the
feasibility of the proposal.

The forward payment can indeed be small, because uncontrolled spam can only
be in-flight for a short time. To get to that annual return of 5% on a 1
BTC / 483 slot channel, it needs to be approx 1 sat/hour (if I calculated
that correctly). Let's say the spam payment is in-flight on average 30
seconds on a 20 route hop (60 sec at the start, 0 sec at the end). The
total "damage" would then be 600 hop-seconds, requiring a forward payment
of 150 msat to cover that. Still seems acceptable to me. If an honest
user makes a payment and needs 10 attempts, they will pay an additional 1.5
sats for that. Might be a ux-challenge to communicate that cost to a normal
user for a failed payment though.

But what happens if the attacker is also on the other end of the
uncontrolled spam payment? Not holding the payment, but still collecting
the forward payments?

For the backward payment the pricing is different. The max expiry of the
htlc is 2000 blocks, 1000 blocks on average along the route. 1000 blocks is
about 160 hours. So ideally the attacker at the far end of the route should
pay 20 * 160 * 1sat/hr = 3200 sat. This will also be the cost for a hold
invoice then, but not everybody liked them anyway. The net cost for a
regular (fast) payment will be nothing as you described.

- Joost

>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Bastien TEINTURIER via Lightning-dev]

Thanks for your answers,

My first instinct is that additional complications are worse in general.
> However, it looks like simpler solutions are truly not enough, so adding
> the complication may very well be necessary.


I agree with both these statements ;). I'd love to find a simpler solution,
but this is the simplest
I've been able to come up with for now that seems to work without adding
griefing vectors...

The succeeding text refers to HTLCs "settling".


As you noted, settling means getting the HTLC removed from the commitment
transaction.
It includes both fulfills and fails, otherwise the proposal indeed doesn't
penalize spam.

If we also require that the hold fee be funded from the main output, then
> we cannot use single-funded channels, except perhaps with `push_msat`.


I see what you mean, the first payment cannot require a hold fee since the
fundee doesn't have a
main output. I think it's ok, it's the same thing as the reserve not being
met initially.

But you're right that there are potentially other mechanisms to enforce the
fee (like your suggestion
of subtracting from the HTLC output), I chose the simplest for now but we
can (and will) revisit
that choice if we think that the overall mechanisms work!

And in this case C earns.

Can C delay the refund to D to after the grace period even if D settled the
> HTLC quickly?


Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent
on anyone downstream.
An honest D should settle the HTLC before the `grace_period` ends. If D
chooses to hold the HTLC
for a while, then it's fair that he pays C for this.

it is the fault of the peer for getting disconnected and having a delay in
> reconnecting, possibly forfeiting the hold fee because of that.


I think I agree with that, but we'll need to think about the pros and cons
when we get to details.

Is 1msat going to even deter anyone?

I am wondering though what the values for the fwd and bwd fees should be. I
> agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be
> enough.


These values are only chosen for the simplicity of the example's sake. If
we agree the proposal works
to fight spam, we will do some calculations to figure a good value for
this. But I think finding the
right base values will not be the hard part, so we'll focus on this if
we're convinced the proposal
is worth exploring in full details.

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 fee is meant to fight
`controlled spam` (where the recipient also belongs to the attacker).

The reason it works is because the `uncontrolled spam` requires the
attacker to send a large volume
of HTLCs, so a very small forward fee gets magnified. The backward fee will
be much bigger because
in `controlled spam`, the attacker doesn't need a large volume of HTLCs but
holds them for a long
time. What I think is nice is that this proposal has only a tiny cost for
honest senders (the
forward fee).

What I'd really like to explore is whether there is a type of spam that I
missed or griefing attacks
that appear because of the mechanisms I introduce. TBH I think the
implementation details (amounts,
grace periods and their deltas, when to start counting, etc) are things
we'll be able to figure out
collectively later.

Thanks again for your time!
Bastien


Le ven. 23 oct. 2020 à 07:58, Joost Jager  a écrit :

> 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
>> about this).
>>
>
> It is interesting that the forward and backward payments are relatively
> independent of each other. In particular the forward anti-spam payment
> could quite easily be implemented to help protect the network. As you said,
> just transfer that fixed fee for every `update_add_htlc` message from the
> offerer to the receiver.
>
> I am wondering though what the values for the fwd and bwd fees should be.
> I agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be
> enough.
>
> Maybe a way to approach it is this: suppose routing nodes are able to make
> 5% per year on their committed capital. An aggressive routing node could be
> willing to spend up to that amount to take down a competitor.
>
> Suppose the network consists only of 1 BTC, 483 slot channels. What should
> the fwd and bwd fees be so that even an attacked routing node will still
> earn that 5% (not through forwarding fees, but through hold fees) in both
> the controlled and the uncontrolled spam scenario?
>
> - Joost
>
___
Lightning-dev mailing 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

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
> about this).
>

It is interesting that the forward and backward payments are relatively
independent of each other. In particular the forward anti-spam payment
could quite easily be implemented to help protect the network. As you said,
just transfer that fixed fee for every `update_add_htlc` message from the
offerer to the receiver.

I am wondering though what the values for the fwd and bwd fees should be. I
agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be
enough.

Maybe a way to approach it is this: suppose routing nodes are able to make
5% per year on their committed capital. An aggressive routing node could be
willing to spend up to that amount to take down a competitor.

Suppose the network consists only of 1 BTC, 483 slot channels. What should
the fwd and bwd fees be so that even an attacked routing node will still
earn that 5% (not through forwarding fees, but through hold fees) in both
the controlled and the uncontrolled spam scenario?

- Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning t-bast,

> Sorry in advance for the lengthy email,

Come on, ZmnSCPxj writes lengthier.

> but I think it's worth detailing my hybrid proposal
> (bidirectional upfront payments), it feels to me like a workable solution 
> that builds on
> previous proposals. You can safely ignore the details at the end of the email 
> and focus only on
> the high-level mechanism at first.
>
> Let's consider the following route: A -> B -> C -> D
>
> We add a `hold_grace_period_delta` field to `channel_update` (in seconds).
> We add two new fields in the tlv extension of `update_add_htlc`:
>
> * `hold_grace_period` (seconds)
> * `hold_fees` (msat)
>
> We add an `outgoing_hold_grace_period` field in the onion per-hop payload.
>
> When nodes receive an `update_add_htlc`, they verify that:
>
> * `hold_fees` is not unreasonable large
> * `hold_grace_period` is not unreasonably small or large
> * `hold_grace_period` - `outgoing_hold_grace_period` >= 
> `hold_grace_period_delta`
>
> Otherwise they immediately fail the HTLC instead of relaying it.
>
> For the example we assume all nodes use `hold_grace_period_delta = 10`.
>
> 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 
> about this).

My first instinct is that additional complications are worse in general.

However, it looks like simpler solutions are truly not enough, so adding the 
complication may very well be necessary.

Possibly one of the issues with previous proposals is that we considered the 
source as the payer of upfront fees always, without considering the possibility 
of the destination paying upfront fees.

We should consider *why* we did so.
Is it only because of lack of imagination?

The succeeding text refers to HTLCs "settling".
What does this mean exactly?
Does it refer to the preimage being revealed only?
Or does it refer to *either* `update_fulfill_htlc` **OR** `update_fail_htlc`?

If "settling" does not include failing the HTLC, I can extract hold fees from 
my peers by giving them HTLCs to random hashes that with very high probability 
has a preimage unknown to my peer.

Thus, "settling" here must also include failing the HTLC.


Can we arrange the HTLC as below?

* The HTLC is lower by the from-destination hold fee than what it "should" be.
  * So in your example, A would offer an HTLC that is 5 msat lower than what it 
"should" be, to represent the from-destination hold-fee.
* When the HTLC is fulfilled offchain, we move the hold fee amount from 
offerrer to acceptor, thus "refunding" the hold fee.
* If the HTLC is failed offchain, we just delete the HTLC.

The above would disincentivize dropping the channel onchain for whatever 
shenanigans might be possible there.

Note that if hold fees are always from the "main output" of the acceptor, then 
we cannot use single-funded channel opening.
Single-funded channel opening is significantly lower-risk as, if somebody opens 
a channel to you and then goes offline forever, you would not care, none of 
your funds are in the channel.
(Sure they could move funds out of the channel and *then* go offline forever, 
but you got paid for that by the forwarding fees in the first place.)
Dual-funding requires some amount of trust/reputation, where you would only be 
willing to put funds on the initiating peer if you are reasonably sure that 
they would remain online so that the funds you put in the channel are not 
uselessly locked.

If we also require that the hold fee be funded from the main output, then we 
cannot use single-funded channels, except perhaps with `push_msat`.

On the other hand, it might be useful to require that though, as a promise from 
the funder that yes, it *is* committed to making that channel work, and will 
thus `push_msat` at you so you can pay for hold fees.


>
> * A sends an HTLC to B:
> * `hold_grace_period = 100 sec`
> * `hold_fees = 5 msat`
> * `next_hold_grace_period = 90 sec`
> * forward upfront payment: 1 msat is deduced from A's main output and added 
> to B's main output
> * backwards upfront payment: 5 msat are deduced from B's main output and 
> added to A's main output
> * B forwards the HTLC to C:
> * `hold_grace_period = 90 sec`
> * `hold_fees = 6 msat`
> * `next_hold_grace_period = 80 sec`
> * forward upfront payment: 1 msat is deduced from B's main output and added 
> to C's main output
> * backwards upfront payment: 6 msat are deduced from C's main output and 
> added to B's main output
> * C forwards the HTLC to D:
> * `hold_grace_period = 80 sec`
> * `hold_fees = 7 msat`
> * `next_hold_grace_period = 70 sec`
> * forward upfront payment: 1 msat is deduced from C's main output and added 
> to D's main output
> * backwards upfront payment: 7 msat are deduced from D's main output and 
> added to C's main output

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Bastien TEINTURIER via Lightning-dev]

Good morning list,

Sorry in advance for the lengthy email, but I think it's worth detailing my
hybrid proposal
(bidirectional upfront payments), it feels to me like a workable solution
that builds on
previous proposals. You can safely ignore the details at the end of the
email and focus only on
the high-level mechanism at first.

Let's consider the following route: A -> B -> C -> D

We add a `hold_grace_period_delta` field to `channel_update` (in seconds).
We add two new fields in the tlv extension of `update_add_htlc`:

* `hold_grace_period` (seconds)
* `hold_fees` (msat)

We add an `outgoing_hold_grace_period` field in the onion per-hop payload.

When nodes receive an `update_add_htlc`, they verify that:

* `hold_fees` is not unreasonable large
* `hold_grace_period` is not unreasonably small or large
* `hold_grace_period` - `outgoing_hold_grace_period` >=
`hold_grace_period_delta`

Otherwise they immediately fail the HTLC instead of relaying it.

For the example we assume all nodes use `hold_grace_period_delta = 10`.

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
about this).

* A sends an HTLC to B:
* `hold_grace_period = 100 sec`
* `hold_fees = 5 msat`
* `next_hold_grace_period = 90 sec`
* forward upfront payment: 1 msat is deduced from A's main output and added
to B's main output
* backwards upfront payment: 5 msat are deduced from B's main output and
added to A's main output
* B forwards the HTLC to C:
* `hold_grace_period = 90 sec`
* `hold_fees = 6 msat`
* `next_hold_grace_period = 80 sec`
* forward upfront payment: 1 msat is deduced from B's main output and added
to C's main output
* backwards upfront payment: 6 msat are deduced from C's main output and
added to B's main output
* C forwards the HTLC to D:
* `hold_grace_period = 80 sec`
* `hold_fees = 7 msat`
* `next_hold_grace_period = 70 sec`
* forward upfront payment: 1 msat is deduced from C's main output and added
to D's main output
* backwards upfront payment: 7 msat are deduced from D's main output and
added to C's main output

* Scenario 1: D settles the HTLC quickly:
* all backwards upfront payments are refunded (returned to the respective
main outputs)
* only the forward upfront payments have been paid (to protect against
`uncontrolled spam`)

* Scenario 2: D settles the HTLC after the grace period:
* D's backwards upfront payment is not refunded
* If C and B relay the settlement upstream quickly (before
`hold_grace_period_delta`) their backwards
upfront payments are refunded
* all the forward upfront payments have been paid (to protect against
`uncontrolled spam`)

* Scenario 3: C delays the HTLC:
* D settles before its `grace_period`, so its backwards upfront payment is
refunded by C
* C delays before settling upstream: it can ensure B will not get refunded,
but C will not get
refunded either so B gains the difference in backwards upfront payments
(which protects against
`controlled spam`)
* all the forward upfront payments have been paid (to protect against
`uncontrolled spam`)

* Scenario 4: the channel B <-> C closes:
* D settles before its `grace_period`, so its backwards upfront payment is
refunded by C
* for whatever reason (malicious or not) the B <-> C channel closes
* this ensures that C's backwards upfront payment is paid to B
* if C publishes an HTLC-fulfill quickly, B may have his backwards upfront
payment refunded by A
* if B is forced to wait for his HTLC-timeout, his backwards upfront
payment will not be refunded
but it's ok because B got C's backwards upfront payment
* all the forward upfront payments have been paid (to protect against
`uncontrolled spam`)

If done naively, this mechanism may allow intermediate nodes to deanonymize
sender/recipient.
If the base `grace_period` and `hold_fees` are randomized, I believe this
attack vector disappears,
but it's worth exploring in more details.

The most painful part of this proposal will be handling the `grace_period`:

* when do you start counting: when you send/receive `update_add_htlc`,
`commit_sig` or
`revoke_and_ack`?
* what happens if there is a disconnection (how do you account for the
delay of reconnecting)?
* what happens if the remote settles after the `grace_period`, but refunds
himself when sending his
`commit_sig` (making it look like from his point of view he settled before
the `grace_period`)?
I think in that case the behavior should be to give your peers some leeway
and let them get away
with it, but record it. If they're doing it too often, close channels and
ban them; stealing
upfront fees should never be worth losing channels.

I chose to make the backwards upfront payment fixed instead of scaling it
based on the time an HTLC
is left pending; it's slightly less penalizing for spammers, but is less
complex and 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning t-bast,

>
> I've started summarizing proposals, attacks and threat models on github [1].
> I'm hoping it will help readers get up-to-speed and avoid falling in the same 
> pitfalls we already
> fell into with previous proposals.

Would my inane incremental routing idea also be in scope here? 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002811.html


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

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 point me to the most
> obvious attacks on it?
>
> It feels to me that its only issue is that it still allows spamming for
> durations smaller than the
> grace period; my gut feeling is that if we add a smaller forward direction
> upfront payment to
> complement it it could be a working solution.
>

The 'uncontrolled spamming' as you called it in your doc is pretty serious.
If you want to have fun, you should really try to spin up a bunch of
threads and keep your outgoing channels fully saturated with max length
routes going nowhere. I tried it on testnet and it was quite bad. All that
traffic is fighting for resources which makes it take even longer to unlock
the htlcs again.

I think that any solution should definitely address this case too.

Your proposal to add a small upfront payment, wouldn't that allow the
(arbitrary) grace period to be removed? It would mean that routing nodes
always need to pay something for forwarding spam, but if they do it quick
enough (honest nodes) that expense is covered by the upfront payment.

- Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Bastien TEINTURIER via Lightning-dev]

Good morning list,

I've started summarizing proposals, attacks and threat models on github [1].
I'm hoping it will help readers get up-to-speed and avoid falling in the
same pitfalls we already
fell into with previous proposals.

I've kept it very high-level for now; we can add nitty-gritty technical
details as we slowly
converge towards acceptable solutions. I have probably missed subtleties
from previous proposals;
feel free to contribute to correct my mistakes. I have omitted for examples
the details of Rusty's
previous proposal since he mentioned a new, better one that will be
described soon.

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 point me to the most obvious
attacks on it?

It feels to me that its only issue is that it still allows spamming for
durations smaller than the
grace period; my gut feeling is that if we add a smaller forward direction
upfront payment to
complement it it could be a working solution.

Pasting it here for completeness:

### Reverse upfront payment

This proposal builds on the previous one, but reverses the flow. Nodes pay
a fee for *receiving*
HTLCs instead of *sending* them.

```text
A -> B -> C -> D

B pays A to receive the HTLC.
Then C pays B to receive the forwarded HTLC.
Then D pays C to receive the forwarded HTLC.
```

There must be a grace period during which no fees are paid; otherwise the
`uncontrolled spam` attack
allows the attacker to force all nodes in the route to pay fees while he's
not paying anything.

The fee cannot be the same at each hop, otherwise it's free for the
attacker when he is at both
ends of the payment route.

This fee must increase as the HTLC travels downstream: this ensures that
nodes that hold HTLCs
longer are penalized more than nodes that fail them fast, and if a node has
to hold an HTLC for a
long time because it's stuck downstream, they will receive more fees than
what they have to pay.

The grace period cannot be the same at each hop either, otherwise the
attacker can force Bob to be
the only one to pay fees. Similarly to how we have `cltv_expiry_delta`,
nodes must have a
`grace_period_delta` and the `grace_period` must be bigger upstream than
downstream.

Drawbacks:

* The attacker can still lock HTLCs for the duration of the `grace_period`
and repeat the attack
continuously

Open questions:

* Does the fee need to be based on the time the HTLC is held?
* What happens when a channel closes and HTLC-timeout has to be redeemed
on-chain?
* Can we implement this without exposing the route length to intermediate
nodes?

Cheers,
Bastien

[1] https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md

Le dim. 18 oct. 2020 à 09:25, Joost Jager  a écrit :

> > 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 would also be
>>
>> > useful information to have.)
>>
>> I don't think anyone has drawn yet a formal proof of this, but roughly a
>> routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
>> to answer the following question "Is this payment coming from Alice and
>> going to Caroll will compensate for my resources consumption ?". With the
>> current LN system, the compensation is conditional on payment settlement
>> success and both Alice and Caroll are distrusted yet discretionary on
>> failure/success. Thus the underscored question is undecidable for a routing
>> peer making relay decisions only on packet observation.
>>
>> One way to mitigate this, is to introduce statistical observation of
>> sender/receiver, namely a reputation system. It can be achieved through a
>> scoring system, web-of-trust, or whatever other solution with the same
>> properties.
>> But still it must be underscored that statistical observations are only
>> probabilistic and don't provide resource consumption security to Bob, the
>> routing peer, in a deterministic way. A well-scored peer may start to
>> suddenly misbehave.
>>
>> In that sense, the efficiency evaluation of a reputation-based solution
>> to deter DoS must be evaluated based based on the loss of the reputation
>> bearer related to the potential damage which can be inflicted. It's just
>> reputation sounds harder to compute accurately than a pure payment-based
>> DoS protection system.
>>
>
> I can totally see the issues and complexity of a reputation-based system.
> With 'trustless payment scheme' I meant indeed a trustless pure
> payment-based DoS protection system and the question whether such a system
> can be proven to not exist. A sender would pay an up-front amount to cover
> the maximum cost, but with the 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

>
> > 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 would also be
>
> > useful information to have.)
>
> I don't think anyone has drawn yet a formal proof of this, but roughly a
> routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
> to answer the following question "Is this payment coming from Alice and
> going to Caroll will compensate for my resources consumption ?". With the
> current LN system, the compensation is conditional on payment settlement
> success and both Alice and Caroll are distrusted yet discretionary on
> failure/success. Thus the underscored question is undecidable for a routing
> peer making relay decisions only on packet observation.
>
> One way to mitigate this, is to introduce statistical observation of
> sender/receiver, namely a reputation system. It can be achieved through a
> scoring system, web-of-trust, or whatever other solution with the same
> properties.
> But still it must be underscored that statistical observations are only
> probabilistic and don't provide resource consumption security to Bob, the
> routing peer, in a deterministic way. A well-scored peer may start to
> suddenly misbehave.
>
> In that sense, the efficiency evaluation of a reputation-based solution to
> deter DoS must be evaluated based based on the loss of the reputation
> bearer related to the potential damage which can be inflicted. It's just
> reputation sounds harder to compute accurately than a pure payment-based
> DoS protection system.
>

I can totally see the issues and complexity of a reputation-based system.
With 'trustless payment scheme' I meant indeed a trustless pure
payment-based DoS protection system and the question whether such a system
can be proven to not exist. A sender would pay an up-front amount to cover
the maximum cost, but with the guarantee that nodes can only take a fair
part of the deposit (based on actual lock time). Perhaps the taproot
upgrade offers new possibilities with adaptor signatures to atomically swap
part of the up-front payment with htlc-received-in-time-signatures from
nodes downstream (random wild idea).


> > What I can see working is a system where peers charge each other a hold
> fee
> > for forwarded HTLCs based on the actual lock time (not the maximum lock
>
> > time) and the htlc value. This is just for the cost of holding and
> separate
> > from the routing fee that is earned when the payment settles
>
> Yes I guess any solution will work as long as it enforces an asymmetry
> between the liquidity requester and a honest routing peer. This asymmetry
> can be defined as guaranteeing that the routing peer's incoming/outgoing
> balance is always increasing, independently of payment success. Obviously
> this increase should be materialized by a payment, while minding it might
> be discounted based on requester reputation ("pay-with-your-reputation").
> This reputation evaluation can be fully delegated to the routing node
> policy, without network-wise guidance.
>
> That said, where I'm skeptical on any reputation-heavy system is on the
> long-term implications.
>
> Either, due to the wants of a subset of actors deliberately willingly to
> trade satoshis against discounted payment flow by buying well-scored
> pubkeys, we see the emergence of a reputation market. Thus enabling
> reputation to be fungible to satoshis, but with now a weird "reputation"
> token to care about.
>
> Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys
> from channel ownership or export your score across routing peers) and thus
> you now have reputation scarcity which is introducing a bias from a "purer"
> market, where agents are only routing based on advertised fees. IMO, we
> should strive for the more liquid Lightning market we can, as it avoids
> bias towards past actors and thus may contain centralization inertia. I'm
> curious about your opinion on this last point.
>

I am in favor of more liquidity and less centralization, but as far as I
know the reality is that we don't have a good solution yet to achieve this
without being vulnerable to DoS attacks. If those attacks would happen on a
large scale today, what would we do?

Also peers can implement these trusted upfront payments without protocol
changes. Just stop forwarding when the prepaid forwarding budget is used up
and require a top-up. It may have been implemented already in parts of the
network, I don't think there is a way to know. I've experimented a bit with
the fee model myself (
https://twitter.com/joostjgr/status/1317546071984427009). Node operators
don't need to wait for permission.

To me it seems that the longer it takes to come up with a good anti-DoS
system for Lightning, the further the outside world will have 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Antoine Riard]

Hi Joost,

Thanks for your proposal, please find my following opinion which is
deliberately on a high-level as IMO defining better threats model and
agreeing on expected network dynamics resulting from any solution
trade-offs sounds required before to work on any solution.

> 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 would also be

> useful information to have.)

I don't think anyone has drawn yet a formal proof of this, but roughly a
routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking
to answer the following question "Is this payment coming from Alice and
going to Caroll will compensate for my resources consumption ?". With the
current LN system, the compensation is conditional on payment settlement
success and both Alice and Caroll are distrusted yet discretionary on
failure/success. Thus the underscored question is undecidable for a routing
peer making relay decisions only on packet observation.

One way to mitigate this, is to introduce statistical observation of
sender/receiver, namely a reputation system. It can be achieved through a
scoring system, web-of-trust, or whatever other solution with the same
properties.
But still it must be underscored that statistical observations are only
probabilistic and don't provide resource consumption security to Bob, the
routing peer, in a deterministic way. A well-scored peer may start to
suddenly misbehave.

In that sense, the efficiency evaluation of a reputation-based solution to
deter DoS must be evaluated based based on the loss of the reputation
bearer related to the potential damage which can be inflicted. It's just
reputation sounds harder to compute accurately than a pure payment-based
DoS protection system.

> Perhaps a small bit of trust isn't so bad. There is trust in Lightning

> already. For example when you open a channel, you trust (or hope) that
your
> peer remains well connected, keeps charging reasonable fees, doesn't

> force-close in a bad way, etc.

That's a good recall, obviously we should avoid getting stuck in a false
trust-vs-trustlessness dichotomy but always bound the discussion to a
specific situation. Even the base layer involved some trust assumptions,
like fetching your initial p2p peers from DNS seeds, all the matter is how
do you minimize this assumption. You might not have the same expectation
when it's miners which might completely screw up the safety of your coin
stack than routing nodes which might only make your loss a tiny routing
fee, a minor nuisance.

> What I can see working is a system where peers charge each other a hold
fee
> for forwarded HTLCs based on the actual lock time (not the maximum lock

> time) and the htlc value. This is just for the cost of holding and
separate
> from the routing fee that is earned when the payment settles

Yes I guess any solution will work as long as it enforces an asymmetry
between the liquidity requester and a honest routing peer. This asymmetry
can be defined as guaranteeing that the routing peer's incoming/outgoing
balance is always increasing, independently of payment success. Obviously
this increase should be materialized by a payment, while minding it might
be discounted based on requester reputation ("pay-with-your-reputation").
This reputation evaluation can be fully delegated to the routing node
policy, without network-wise guidance.

That said, where I'm skeptical on any reputation-heavy system is on the
long-term implications.

Either, due to the wants of a subset of actors deliberately willingly to
trade satoshis against discounted payment flow by buying well-scored
pubkeys, we see the emergence of a reputation market. Thus enabling
reputation to be fungible to satoshis, but with now a weird "reputation"
token to care about.

Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys
from channel ownership or export your score across routing peers) and thus
you now have reputation scarcity which is introducing a bias from a "purer"
market, where agents are only routing based on advertised fees. IMO, we
should strive for the more liquid Lightning market we can, as it avoids
bias towards past actors and thus may contain centralization inertia. I'm
curious about your opinion on this last point.

Moving forward, I think t-bast is working on gathering materials to
checkbox the first step, establishing a fully-fledged threat model.

Cheers,

Antoine

Le lun. 12 oct. 2020 à 07:04, Joost Jager  a écrit :

> 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 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Rusty Russell]

Joost Jager  writes:
>>
>> > 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 will need to build a
>> > reputation before they're able to command hold fees. Similarly, routing
>> > nodes that have a strong relation may decide to not charge hold fees to
>> > each other at all.
>>
>> I can still establish channels to various low-reputation nodes, and then
>> use them to grief a high-reputation node.  Not only do I get to jam up
>> the high-reputation channels, as a bonus I get the low-reputation nodes
>> to pay for it!
>
> So you're saying:
>
> ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP
>
> 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 is felt by
> the attacker. The assumption is that this is sufficient enough to deter the
> attacker from even trying.

No, because HIGH-REP == ATTACKER and LOW-REP pays.

> I guess your concern is with trying to become a routing node? If nobody
> knows you, you'll be forced to pay hold fees but can't attract traffic if
> you charge hold fees yourself. That indeed means that you'll need to be
> selective with whom you accept htlcs from. Put limits in place to control
> the expenditure. Successful forwards will earn a routing fee which could
> compensate for the loss in hold fees too.

"Be selectinve with whom you accept HTLCs from"... it always comes back
to incentives to de-anonymize the network :(

> I think this mechanism can create interesting dynamics on the network and
> eventually reach an equilibrium that is still healthy in terms of
> decentralization and privacy.

I suspect that if you try to create a set of actual rules for nodes
using actual numbers, I think you'll find you enter a complexity spiral
as you try to play whack-a-mole on all the different ways you can
exploit it.

(This is what happened every time I tried to design a peer-penalty
system).

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning Joost,


> > * I convince Rene to make a channel to me.
>
> You may succeed, but Rene is probably not going to pay you a hold fee because 
> you're untrusted.

Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene 
relationships, not necessarily recouping these funds.

>  
>
> > * I connect to Joost.
> > * I prepay to Joost.
> > * I forward Me->Joost->Rusty->Rene->me.
> >   * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and 
> > the tr\*st that Rene has to Rusty.
> > * When the HTLC reaches me, I dicker around and wait until it is about to 
> > time out before ultimately failing.
> > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. 
>
> But most importantly: you will have paid hold fees to Joost for the long lock 
> time of the htlc. This should keep you from even trying this attack.

But I might be interested in paying money in order to damage your reputation 
with Rusty, and damaging the reputation of Rusty with Rene.
Thus my capacity to disrupt the network is increased linearly by the number of 
hops involved, thus my point: I think what should be paid should be for the 
entire route, not the first hop.

For that matter, how certain are you that Rene and Zeeman are not secretly the 
same person, have you seen them in the same room together?


As I pointed out before, the main reason to engage in these attacks is to lock 
up the capacity of less-capitalized competitors in the payment forwarding 
business.
Cases of slow payment resolution caused by intermediate nodes are more likely 
to be because of incompetence (crashing nodes, ISP disconnections, clumsy 
humans tripping on power supplies) than active malice.
Thus, the primary motivated attackers are the ends of the payment: the payer 
and payee, who, in this attack, are coordinating with each other to lock up the 
funds of multiple other lesser-capacity nodes (and which might be a single 
node).

To an extent, to protect against such attacks, we need to know the payer and 
payee and somehow judge their tr\*stworthiness --- but we want to not have to 
reveal their identities, since that works against our privacy.

Hmmm.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Christian Decker]

Joost Jager  writes:
>> The LOW-REP node being out of pocket is the clue here: if one party
>> loses funds, even a tiny bit, another party gains some funds. In this
>> case the HIGH-REP node collaborating with the ATTACKER can extract some
>> funds from the intermediate node, allowing them to dime their way to all
>> of LOW-REP's funds. If an attack results in even a tiny loss for an
>> intermediary and can be repeated, the intermediary's funds can be
>> syphoned by an attacker.
>>
>
> The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all
> those failed payments and small losses and start to realize that something
> strange is happening. I know the proposal isn't fully trustless, but I
> think it can work in practice.
>
>
>> Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the
>> preimage is even worse:
>>
>>  - Attacker node `A` charging hold fees receives HTLC from victim `V`
>>  - `A` does not forward the HTLC, but starts charging hold fees
>>  - Just before the timeout for the HTLC would force us to settle onchain
>>`A` just removes the HTLC without forwarding it or he can try to
>>forward at the last moment, potentially blaming someone else for its
>>failure to complete
>>
>> This results in `A` extracting the maximum hold fee from `V`, without
>> the downstream hold fees cutting into their profits. By forwarding as
>> late as possible `A` can cause a downstream failure and look innocent,
>> and the overall payment has the worst possible outcome: we waited an
>> eternity for what turns out to be a failed attempt.
>>
>
> The idea is that an attacker node is untrusted and won't be able to charge
> hold fees.

The attacker controls both the sender and the HIGH-REP node. The sender
doesn't need to be trusted, it just initiates a payment that is used to
extract hold fees from a forwarding node. The HIGH-REP node doesn't
lose reputation because from what we can witness externally the payment
failed somewhere downstream. It does require an attacker to have a hold
fee charging HIGH-REP node, yes, but he is not jeopardizing its
reputation by having it fail downstream.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

>
> > 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
> > is felt by the attacker. The assumption is that this is sufficient
> > enough to deter the attacker from even trying.
>
> The LOW-REP node being out of pocket is the clue here: if one party
> loses funds, even a tiny bit, another party gains some funds. In this
> case the HIGH-REP node collaborating with the ATTACKER can extract some
> funds from the intermediate node, allowing them to dime their way to all
> of LOW-REP's funds. If an attack results in even a tiny loss for an
> intermediary and can be repeated, the intermediary's funds can be
> syphoned by an attacker.
>

The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all
those failed payments and small losses and start to realize that something
strange is happening. I know the proposal isn't fully trustless, but I
think it can work in practice.


> Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the
> preimage is even worse:
>
>  - Attacker node `A` charging hold fees receives HTLC from victim `V`
>  - `A` does not forward the HTLC, but starts charging hold fees
>  - Just before the timeout for the HTLC would force us to settle onchain
>`A` just removes the HTLC without forwarding it or he can try to
>forward at the last moment, potentially blaming someone else for its
>failure to complete
>
> This results in `A` extracting the maximum hold fee from `V`, without
> the downstream hold fees cutting into their profits. By forwarding as
> late as possible `A` can cause a downstream failure and look innocent,
> and the overall payment has the worst possible outcome: we waited an
> eternity for what turns out to be a failed attempt.
>

The idea is that an attacker node is untrusted and won't be able to charge
hold fees.

- Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

>
> > 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 Lightning
> payment, not integrated with the add/fail/settle flow. I prefer option B,
> but implementation effort is also a consideration.
>
> If the above is not done (i.e. if I only prepay Joost but not Rusty) then
> it seems to me that the below remote attack is possible:
>

Indeed, the above isn't done. Z only prepays Joost, not rusty.


> * I convince Rene to make a channel to me.
>

You may succeed, but Rene is probably not going to pay you a hold fee
because you're untrusted.


> * I connect to Joost.
> * I prepay to Joost.
> * I forward Me->Joost->Rusty->Rene->me.
>   * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and
> the tr\*st that Rene has to Rusty.
> * When the HTLC reaches me, I dicker around and wait until it is about to
> time out before ultimately failing.
> * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty.


But most importantly: you will have paid hold fees to Joost for the long
lock time of the htlc. This should keep you from even trying this attack.

Thinking a little more deeply: it is in principle possible to give a
> financial value to an amount of msat being locked for an amount of time.
> For instance the C-Lightning `getroute` has a `riskfactor` argument which
> is used in this conversion.
> Basically, by being locked in an HTLC and later failing, then the
> forwarding node loses the expected return on investment if instead the
> amount were locked in an HTLC that later succeeds.
>
> Now, the cost on a forwarding node is based on the actual amount of time
> that its outgoing HTLC is locked.
>

That is indeed the proposal, to give financial value to the sats and the
htlc slot being locked for an amount of time.


> When we consider multi-hop payments, then we should consider that the
> initiator of the multi-hop payment is asking multiple nodes to put their
> funds at risk.
>
> Thus, the initiator of a multi-hop payment should, in principle, prepay
> for *all* the risk of *all* the hops.
>
>
> If we do not enforce this, then an initiator of a multi-hop payment can
> pay a small amount relative to the risk that *all* the hops are taking.
>

I understand that, but I think it might be a large enough shift in the
incentives of the attacker.


> Secondarily, we currently assume that forwarding nodes will, upon having
> their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as
> possible.
> This is because the incoming HTLC would be locked and unuseable until they
> claim their incoming HTLC, and the liquidity would not be usable for
> earning more fees until the incoming HTLC is claimed and put into its pool
> of liquidity.
>
However, if we make anything that is based on the time that a forwarding
> node claims its incoming HTLC, then this may incentivize the forwarding
> node to delay claiming the incoming HTLC.
>

Yes, that is the trust part again.


> > > > B. Tightly integrated with the htlc add/fail/settle messages. When
> an htlc is added, the maximum cost (based on maximum lock time) for holding
> is deducted from the sender's channel balance. When the htlc settles, a
> refund is given based on the actual lock time. An additional
> `update_fee`-like message is added for peers to update their hold fee
> parameters (fee_base and fee_rate).
> > >
> > > If I am a forwarding node, and I receive the preimage from the
> outgoing HTLC, can I deliberately defer claiming the incoming HTLC
> (pretending that the outgoing HTLC was taking longer than it actually took)
> in order to reduce the amount I have to refund?
> >
> > Yes you can. That is the trust part, your peer trusts you not to do
> this. If they don't trust you, they won't forward to you if you charge a
> (high) hold fee.
>
> What happens if I charge a tiny hold feerate in msats/second, but end up
> locking the funds for a week?
> How does my peer know that even though I charge a tiny hold fee, I will
> hold their funds hostage for a week?
>

That is the trust part also.


> > > > In both cases the sender needs to trust its peer to not steal the
> payment and/or artificially delay the forwarding to inflate the hold fee. I
> think that is acceptable given that there is a trust relation between peers
> already anyway.
> > >
> > > I am wary of *adding* trust.
> > > You might trust someone to keep an eye on your snacks while you go
> refill your drink, but not to keep an eye on your hardware wallet when you
> do the same.
> > > (Since consuming snacks and drinks and hardware wallets are human
> activities, this should show that I am in fact a human.)
> >
> > So I am arguing that there is trust already between peers. Quite
> considerable trust even in case of high on-chain fee conditions. The 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Christian Decker]

I think the mechanism can indeed create interesting dynamics, but not in
a good sense :-)

>> I can still establish channels to various low-reputation nodes, and
>> then use them to grief a high-reputation node.  Not only do I get to
>> jam up the high-reputation channels, as a bonus I get the
>> low-reputation nodes to pay for it!
>
> So you're saying:
>
> ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP
>
> 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
> is felt by the attacker. The assumption is that this is sufficient
> enough to deter the attacker from even trying.

The LOW-REP node being out of pocket is the clue here: if one party
loses funds, even a tiny bit, another party gains some funds. In this
case the HIGH-REP node collaborating with the ATTACKER can extract some
funds from the intermediate node, allowing them to dime their way to all
of LOW-REP's funds. If an attack results in even a tiny loss for an
intermediary and can be repeated, the intermediary's funds can be
syphoned by an attacker.

Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the
preimage is even worse:

 - Attacker node `A` charging hold fees receives HTLC from victim `V`
 - `A` does not forward the HTLC, but starts charging hold fees
 - Just before the timeout for the HTLC would force us to settle onchain
   `A` just removes the HTLC without forwarding it or he can try to
   forward at the last moment, potentially blaming someone else for its
   failure to complete

This results in `A` extracting the maximum hold fee from `V`, without
the downstream hold fees cutting into their profits. By forwarding as
late as possible `A` can cause a downstream failure and look innocent,
and the overall payment has the worst possible outcome: we waited an
eternity for what turns out to be a failed attempt.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning Joost,

> > > 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 
> > > money.
> >
> > If the node has already forwarded the HTLC onward, what enforcement hold 
> > does the node have on the sender of the incoming HTLC?
> > Presumably the sender of the HTLC has already gotten what it wanted --- an 
> > outgoing HTLC --- so how can the forwarding node enforce this request to 
> > get more money.
>
> 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 Lightning 
> payment, not integrated with the add/fail/settle flow. I prefer option B, but 
> implementation effort is also a consideration.

Okay, so basically, it becomes something like this.

* There exists a network Joost <-> Rusty <-> Rene
* I connect to Joost.
* I owe Rene some sats.
* First, I prepay Joost directly a bunch of sats.
  * Joost is now willing to forward to Rusty, but Rusty is not yet willing to 
forward further.
* I prepay Rusty a bunch of sats.
  * I effectively "spend" some of the prepaid service that I already paid to 
Joost in order to pay to Rusty.
* Finally, using the prepay to Joost and Rusty, I now can route a payment to 
Rene.

Is that approximately how it works out?

Does it mean that Joost and Rusty have to know the source of the payment route?
Worse, they have to keep track of prepaid fees from all nodes, not just their 
direct peers?

If the above is not done (i.e. if I only prepay Joost but not Rusty) then it 
seems to me that the below remote attack is possible:

* I convince Rene to make a channel to me.
* I connect to Joost.
* I prepay to Joost.
* I forward Me->Joost->Rusty->Rene->me.
  * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and the 
tr\*st that Rene has to Rusty.
* When the HTLC reaches me, I dicker around and wait until it is about to time 
out before ultimately failing.
* Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty.

---

Thinking a little more deeply: it is in principle possible to give a financial 
value to an amount of msat being locked for an amount of time.
For instance the C-Lightning `getroute` has a `riskfactor` argument which is 
used in this conversion.
Basically, by being locked in an HTLC and later failing, then the forwarding 
node loses the expected return on investment if instead the amount were locked 
in an HTLC that later succeeds.

Now, the cost on a forwarding node is based on the actual amount of time that 
its outgoing HTLC is locked.

When we consider multi-hop payments, then we should consider that the initiator 
of the multi-hop payment is asking multiple nodes to put their funds at risk.

Thus, the initiator of a multi-hop payment should, in principle, prepay for 
*all* the risk of *all* the hops.


If we do not enforce this, then an initiator of a multi-hop payment can pay a 
small amount relative to the risk that *all* the hops are taking.




Secondarily, we currently assume that forwarding nodes will, upon having their 
outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as possible.
This is because the incoming HTLC would be locked and unuseable until they 
claim their incoming HTLC, and the liquidity would not be usable for earning 
more fees until the incoming HTLC is claimed and put into its pool of liquidity.

However, if we make anything that is based on the time that a forwarding node 
claims its incoming HTLC, then this may incentivize the forwarding node to 
delay claiming the incoming HTLC.




>
> > > B. Tightly integrated with the htlc add/fail/settle messages. When an 
> > > htlc is added, the maximum cost (based on maximum lock time) for holding 
> > > is deducted from the sender's channel balance. When the htlc settles, a 
> > > refund is given based on the actual lock time. An additional 
> > > `update_fee`-like message is added for peers to update their hold fee 
> > > parameters (fee_base and fee_rate).
> >
> > If I am a forwarding node, and I receive the preimage from the outgoing 
> > HTLC, can I deliberately defer claiming the incoming HTLC (pretending that 
> > the outgoing HTLC was taking longer than it actually took) in order to 
> > reduce the amount I have to refund?
>
> Yes you can. That is the trust part, your peer trusts you not to do this. If 
> they don't trust you, they won't forward to you if you charge a (high) hold 
> fee.

What happens if I charge a tiny hold feerate in msats/second, but end up 
locking the funds for a week?
How does my peer know that even though I charge a tiny hold fee, I will hold 

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

>
> > 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 will need to build a
> > reputation before they're able to command hold fees. Similarly, routing
> > nodes that have a strong relation may decide to not charge hold fees to
> > each other at all.
>
> I can still establish channels to various low-reputation nodes, and then
> use them to grief a high-reputation node.  Not only do I get to jam up
> the high-reputation channels, as a bonus I get the low-reputation nodes
> to pay for it!
>

So you're saying:

ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP

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 is felt by
the attacker. The assumption is that this is sufficient enough to deter the
attacker from even trying.


> Operators of high reputation nodes can even make this profitable; doubly
> so, since they eliminate the chance of any of those low-reputation nodes
> every getting to be high reputation (and thus competing).
>

> AFAICT any scheme which penalizes the direct peer creates a bias against
> forwarding unknown payments, thus is deanonymizing.
>

If you're an honest but unknown sender (initiating the payment) and you
just pay the hold fee, I don't think there is a problem? The unknown
forward will still be carried out by a high-rep node. Also need to keep in
mind that the hold fee for quick happy flow payments is going to be tiny
(for example when calculating back from a desired annual return on the
staked channel capacity). And we can finally make these parasitic hodl
invoice users pay for it!

I guess your concern is with trying to become a routing node? If nobody
knows you, you'll be forced to pay hold fees but can't attract traffic if
you charge hold fees yourself. That indeed means that you'll need to be
selective with whom you accept htlcs from. Put limits in place to control
the expenditure. Successful forwards will earn a routing fee which could
compensate for the loss in hold fees too.

I think this mechanism can create interesting dynamics on the network and
eventually reach an equilibrium that is still healthy in terms of
decentralization and privacy.

Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Rusty Russell]

Joost Jager  writes:
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.

...
> 
> In both cases the sender needs to trust its peer to not steal the payment
> and/or artificially delay the forwarding to inflate the hold fee. I think
> that is acceptable given that there is a trust relation between peers
> already anyway.
>
> 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 will need to build a
> reputation before they're able to command hold fees. Similarly, routing
> nodes that have a strong relation may decide to not charge hold fees to
> each other at all.

I can still establish channels to various low-reputation nodes, and then
use them to grief a high-reputation node.  Not only do I get to jam up
the high-reputation channels, as a bonus I get the low-reputation nodes
to pay for it!

Operators of high reputation nodes can even make this profitable; doubly
so, since they eliminate the chance of any of those low-reputation nodes
every getting to be high reputation (and thus competing).

AFAICT any scheme which penalizes the direct peer creates a bias against
forwarding unknown payments, thus is deanonymizing.

> I'd also like to encourage everyone to prioritize this spam/jam issue and
> dedicate more time to solving it. Obviously there is a lot more to do in
> Lightning, but I am not sure if we can afford to wait for the real
> adversaries to show up on this one.

Agreed.  It's a classic "it's not actually on fire *right now*" problem,
so it does keep getting pushed back.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

>
> > 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
> money.
>
> If the node has already forwarded the HTLC onward, what enforcement hold
> does the node have on the sender of the incoming HTLC?
> Presumably the sender of the HTLC has already gotten what it wanted --- an
> outgoing HTLC --- so how can the forwarding node enforce this request to
> get more money.
>

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 Lightning
payment, not integrated with the add/fail/settle flow. I prefer option B,
but implementation effort is also a consideration.

> B. Tightly integrated with the htlc add/fail/settle messages. When an
> htlc is added, the maximum cost (based on maximum lock time) for holding is
> deducted from the sender's channel balance. When the htlc settles, a refund
> is given based on the actual lock time. An additional `update_fee`-like
> message is added for peers to update their hold fee parameters (fee_base
> and fee_rate).
>
> If I am a forwarding node, and I receive the preimage from the outgoing
> HTLC, can I deliberately defer claiming the incoming HTLC (pretending that
> the outgoing HTLC was taking longer than it actually took) in order to
> reduce the amount I have to refund?
>

Yes you can. That is the trust part, your peer trusts you not to do this.
If they don't trust you, they won't forward to you if you charge a (high)
hold fee.

> In both cases the sender needs to trust its peer to not steal the payment
> and/or artificially delay the forwarding to inflate the hold fee. I think
> that is acceptable given that there is a trust relation between peers
> already anyway.
>
> I am wary of *adding* trust.
> You might trust someone to keep an eye on your snacks while you go refill
> your drink, but not to keep an eye on your hardware wallet when you do the
> same.
> (Since consuming snacks and drinks and hardware wallets are human
> activities, this should show that I am in fact a human.)
>

So I am arguing that there is trust already between peers. Quite
considerable trust even in case of high on-chain fee conditions. The added
risk of being scammed out of these prepay sats may not be significant.

Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[ZmnSCPxj via Lightning-dev]

Good morning Joost,

I would like some clarifications on this mechanism.


> 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 money.

If the node has already forwarded the HTLC onward, what enforcement hold does 
the node have on the sender of the incoming HTLC?
Presumably the sender of the HTLC has already gotten what it wanted --- an 
outgoing HTLC --- so how can the forwarding node enforce this request to get 
more money.

> B. Tightly integrated with the htlc add/fail/settle messages. When an htlc is 
> added, the maximum cost (based on maximum lock time) for holding is deducted 
> from the sender's channel balance. When the htlc settles, a refund is given 
> based on the actual lock time. An additional `update_fee`-like message is 
> added for peers to update their hold fee parameters (fee_base and fee_rate).

If I am a forwarding node, and I receive the preimage from the outgoing HTLC, 
can I deliberately defer claiming the incoming HTLC (pretending that the 
outgoing HTLC was taking longer than it actually took) in order to reduce the 
amount I have to refund?

> In both cases the sender needs to trust its peer to not steal the payment 
> and/or artificially delay the forwarding to inflate the hold fee. I think 
> that is acceptable given that there is a trust relation between peers already 
> anyway.

I am wary of *adding* trust.
You might trust someone to keep an eye on your snacks while you go refill your 
drink, but not to keep an eye on your hardware wallet when you do the same.
(Since consuming snacks and drinks and hardware wallets are human activities, 
this should show that I am in fact a human.)


How about this?

Before, when thinking about JIT routing, I suggested that a JIT-routing enabled 
forwarding node should only be willing to pay for the JIT rebalancing up to 
some fraction (less than 1.0) of the amount already earned from the outgoing 
channel, in order to protect against some attacks.
And when the JIT-routing node does a rebalance in order to serve the 
forwarding, it should deduct the cost of the rebalance from its cumulative sum 
of earnings from that outgoing channel.

The effect of the above is that the already-earned forwarding fees serves as a 
"level of trust" that the rebalancing in order to serve the outgoing forward 
will not be wasted.

Perhaps intermediate nodes should limit incoming HTLCs from peers that have not 
given them a lot of successful forwards and earned forwarding fees from those 
forwards.
i.e. if it is a new peer, you allow HTLCs up to a certain size, then if the 
outgoing HTLC is claimed quickly rather than slowly and you earn a good amount 
of fee, you might be willing to increase the limits of incoming HTLCs.

This is effectively "growing trust".


Of course, now we have to wonder about exit scams where a node manipulates you 
into increasing this "trust score" and later screwing you over when you are 
willing to accept larger total HTLCs  Sigh.
On the other hand, if you base this on the amount of fees you earn per unit 
time and deducting the converted risk of having your fees locked in outgoing 
HTLCs, then attackers have to effectively pay you forwarding fees first before 
they can attack you, and once they attack, they lose the accumulated score.

So in some way, this system functions a little like pre-paid fees, except the 
pre-payment is in the actual pay-on-successful-forwarding of previous HTLCs you 
have forwarded.
Maybe.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

[Joost Jager]

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 far this
doesn't seem to be happening in practice, but I believe that it is only a
matter of time before it will become a real issue.

Rate limits and other limits such as the maximum number of in-flight HTLCs
increase the cost of an attack, but may also limit the capabilities of
honest users. It works as a mitigation, but it doesn't seem to be the ideal
solution.

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 would also be
useful information to have.)

Perhaps a small bit of trust isn't so bad. There is trust in Lightning
already. For example when you open a channel, you trust (or hope) that your
peer remains well connected, keeps charging reasonable fees, doesn't
force-close in a bad way, etc.

What I can see working is a system where peers charge each other a hold fee
for forwarded HTLCs based on the actual lock time (not the maximum lock
time) and the htlc value. This is just for the cost of holding and separate
from the routing fee that is earned when the payment settles.

This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
fee_base is in there to compensate for the usage of an htlc slot, which is
a scarce resource too.

I think the implementation of this is less interesting at this stage, but
some ideas are:

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
money.

B. Tightly integrated with the htlc add/fail/settle messages. When an htlc
is added, the maximum cost (based on maximum lock time) for holding is
deducted from the sender's channel balance. When the htlc settles, a refund
is given based on the actual lock time. An additional `update_fee`-like
message is added for peers to update their hold fee parameters (fee_base
and fee_rate).

In both cases the sender needs to trust its peer to not steal the payment
and/or artificially delay the forwarding to inflate the hold fee. I think
that is acceptable given that there is a trust relation between peers
already anyway.

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 will need to build a
reputation before they're able to command hold fees. Similarly, routing
nodes that have a strong relation may decide to not charge hold fees to
each other at all.

This asymmetry is what is supposed to prevent channel jamming attacks. The
attacker needs to pay hold fees to send out the payment, but when it comes
back to the attacker after traversing a circular route, they won't be able
to charge a hold fee to cancel out the hold fee paid at the start of the
route. (Assuming the attacker node is not trusted.)

A consequence for honest users is that payment attempts are no longer free.
The cost should however be negligible for fast-failing attempts. Also
senders will have to be a lot more selective when building a route.
Selecting a 'black hole' hop (hop that doesn't forward nor fail) can be
costly.

The hold fee scheme is a bit looser compared to previously proposed schemes
(as far as I know...). It is purely an arrangement between channel peers
and doesn't try to exactly compensate every hop for its costs. Instead
trust relations that arguably exist already are leveraged to present a bill
to the actor who deserves it.

Interested to hear opinions about this proposal.

I'd also like to encourage everyone to prioritize this spam/jam issue and
dedicate more time to solving it. Obviously there is a lot more to do in
Lightning, but I am not sure if we can afford to wait for the real
adversaries to show up on this one.

Cheers,
Joost
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev