Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-22 📝 Original message: Good morning list, Sorry ...
📅 Original date posted:2020-10-22
📝 Original message:
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 introduces less
potential griefing against honest nodes. With the scaling approach, an
honest node that has its
channel unilaterally closed is too heavily penalized IMHO (because it has
to pay for the maximum
hold duration).
I also chose to make the forward upfront payment constant (1 msat). Is it
going to be a pain to
bikeshed this constant? Do we need to add a mechanism to upgrade it? We
don't want to make this
more complex than it should.
Before we dive into the specifics (addressing the implementation concerns),
can you all please take
a bit of time to figure out whether the proposed mechanisms would mitigate
spam or not, and whether
it introduces griefing attacks against honest nodes. I think it would be a
waste of your time to
bikeshed the nuts and bolts details if the proposal is fundamentally
broken...
Answering to previous emails below.
Your proposal to add a small upfront payment, wouldn't that allow the
> (arbitrary) grace period to be removed?
I think we need a `grace_period` for the backwards upfront payment, to
encourage nodes to settle
quickly (otherwise I believe it's too easy to grief honest nodes because
the backwards upfront payment
will be bigger than the forward one - because `uncontrolled spam` is based
on volume so it doesn't
need a huge fee to mitigate).
Would my inane incremental routing idea also be in scope here?
It could potentially be easier to integrate spam mitigation inside
incremental routing, indeed.
But I think this proposal is unfortunately very costly in terms of
latency...
Thanks everyone,
Bastien
Le mer. 21 oct. 2020 à 05:21, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201022/4a7c0856/attachment.html>;
📝 Original message:
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 introduces less
potential griefing against honest nodes. With the scaling approach, an
honest node that has its
channel unilaterally closed is too heavily penalized IMHO (because it has
to pay for the maximum
hold duration).
I also chose to make the forward upfront payment constant (1 msat). Is it
going to be a pain to
bikeshed this constant? Do we need to add a mechanism to upgrade it? We
don't want to make this
more complex than it should.
Before we dive into the specifics (addressing the implementation concerns),
can you all please take
a bit of time to figure out whether the proposed mechanisms would mitigate
spam or not, and whether
it introduces griefing attacks against honest nodes. I think it would be a
waste of your time to
bikeshed the nuts and bolts details if the proposal is fundamentally
broken...
Answering to previous emails below.
Your proposal to add a small upfront payment, wouldn't that allow the
> (arbitrary) grace period to be removed?
I think we need a `grace_period` for the backwards upfront payment, to
encourage nodes to settle
quickly (otherwise I believe it's too easy to grief honest nodes because
the backwards upfront payment
will be bigger than the forward one - because `uncontrolled spam` is based
on volume so it doesn't
need a huge fee to mitigate).
Would my inane incremental routing idea also be in scope here?
It could potentially be easier to integrate spam mitigation inside
incremental routing, indeed.
But I think this proposal is unfortunately very costly in terms of
latency...
Thanks everyone,
Bastien
Le mer. 21 oct. 2020 à 05:21, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201022/4a7c0856/attachment.html>;