Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-13 📝 Original message: Joost Jager <joost.jager ...
📅 Original date posted:2020-10-13
📝 Original message:
Joost Jager <joost.jager at gmail.com> 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
📝 Original message:
Joost Jager <joost.jager at gmail.com> 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