Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-13 📝 Original message: > > > If I were LOW-REP, ...
📅 Original date posted:2020-10-13
📝 Original message:
>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201013/5b59146c/attachment.html>;
📝 Original message:
>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201013/5b59146c/attachment.html>;