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