From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11A90C0733; Wed, 15 Jul 2020 15:23:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 006D18B554; Wed, 15 Jul 2020 15:23:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXVQ12CtRADW; Wed, 15 Jul 2020 15:23:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by whitealder.osuosl.org (Postfix) with ESMTPS id CCAB28B54B; Wed, 15 Jul 2020 15:23:35 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id k5so2517476plk.13; Wed, 15 Jul 2020 08:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DfFuP8yRe/6olh6UzT4ENvjSKOcoPlqopfoHoBEUrjk=; b=twsXNyfPYMSRMK779k6S1FnsL6pE5iAG6mt3fOYq7f5GYSM1bKCIqnM62e90NMrBfW i2PAgdfnguUGikLH6iWuGjvcN5FB98Qm87SPBBTnXxpmgfI1/Qe7QWvFGAow7HcpWt/z Ppt5ugVqo1qo11HmWGK+0C6WDNA6SbOW7Jf7GoOeJ/yrditHmF8E3BI0roWD5Yzt3jzi 2QSAGIidH9h2xq06hKaokqQNDnnqjA5xSDe8uedLgFjzxoLp3/UDnHkfdZvRKyr8vuX3 wLbxYMvRC0IKzCh4ZWj8Q687ZNX7YeMK8wLUrG1npT74QHvB6vbXG5WG0OcKoja3P7fm eoZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DfFuP8yRe/6olh6UzT4ENvjSKOcoPlqopfoHoBEUrjk=; b=BAVmVGNDSnyXGqy0k4LnKtD5NRUfLbQ6difP65C0yl+v6Dhz5mJBv4ckzAAtvQDrOb Bl2q1kn+928NhuiV5x322445YU4TarloIwugxn/7CAaISyEC+1oL9MBAKGykjEvEH80u XdZVUaAByn2lt3QzuFIjezKwCARA8bQU++N2XwrzFWyD2PdC1OanZeYDQy0YubYFCuBa H70KYJllI6b+nh6S++2Hm4xycUD/hFEvRROLrFZ8sw46SJtnKi7UyLfw9IhiCMKfXVeP b8CVllpa1/FRGrryb+chMJ4R07KDfEApVPgCqHHSiXNsW0qk00TY0U/RXqeWEGHzOH7m SbyQ== X-Gm-Message-State: AOAM530DAWwKJFhAKlrAbY+auPxZZ86vMOVaeBXk7Aab1q1hCbg75wLr BgyZBaSemMdW316azt5KbAvHdse4zTleQWUN7+o= X-Google-Smtp-Source: ABdhPJxTu55oEJVAFmhVmXfnVoBarWHBCR54RIuSJrXY6VTsTVHL8EA77czP7gk7zmvTE1/fO+ZxuUVD0NFC+wo/2uk= X-Received: by 2002:a17:90a:2367:: with SMTP id f94mr191678pje.20.1594826615356; Wed, 15 Jul 2020 08:23:35 -0700 (PDT) MIME-Version: 1.0 References: <6443d6fb7ba06151b8a4ff4914761471.squirrel@giyzk7o6dcunb2ry.onion> In-Reply-To: From: Jochen Hoenicke Date: Wed, 15 Jul 2020 17:23:24 +0200 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e3006705aa7c8107" Cc: "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:23:37 -0000 --000000000000e3006705aa7c8107 Content-Type: text/plain; charset="UTF-8" On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Mr. Lee, > > > Sorry. Re-sending with correction to CC bitcoin-dev > > > > I am sorry if this was already brought up in previous threads. If I know > > lightning network correctly then HTLC is used to enforce settlements on > > blockchain if there is a dispute. Could a person lose money if their HTLC > > does not get confirmed in the timeframe or if an older HTLC gets > > confirmed first? I see different ways this could happen. > > > > One, if the blockchain is very saturated with other transactions. The > > reason we need lightning network is why it might have troubles with > > settlements? > > This could happen, but the entire exercise is to move transactions off the > blockchain, precisely to lower this risk. > > Otherwise, transfers onchain will take a long time. > In practice, a long time to settle a payment will invalidate many > real-world economic exchanges anyway (consider paying for food at a > restaurant --- if your payments take days to settle, the food has gotten > stale before the restaurant receives payment and releases your food). > Thus, if an onchain transfer takes a long time to settle, there is already > risk of economic loss present. > > By moving activity offchain, we reduce pressure onchain and improve > settlement speeds on both offchain and onchain, reducing risk of economic > loss due to delay. > > > > Two, competition from a different conflicting HTLC. A newer > > HTLC might not get confirmed before an older HTL. > > I cannot make sense of this. > > You cannot create conflicting HTLCs. > Correct. Removing or Creating an HTLC is something that both channel partners need to agree on. They may create multiple pending HTLCs as long as there are enough funds, but creating conflicting HTLCs is not possible. > > > > I found out about a recent attack technique that sounds like it might be > > similar called "flood and loot". > > Roughly, my understanding of Flood and Loot is to make a lot of > uneconomically tiny HTLCs going through a target victim forwarding node. > You make circular routes going from your own node back to yourself. > Then you refuse to actually claim the HTLCs sent back to yourself. > No, the way I understand it is that an attacker, say Malleroy, routes a lot of medium sized HTLC payments from his node to his node via a victim node, say Alice's, and possibly other nodes. Then Malleroy *accepts* the payments by publishing the hash on the receiving end, so he gets all the sent funds on his receiving channel. Malleroy's receiving node behaves completely honestly, and nobody can prove that it belongs to the attacker. Finally when Alice claims her HTLC by presenting the hash, Malleroy just ignores the claim. Now Alice, the victim, is forced to close the channel to prevent the HTLC to timeout. If Malleroy does it with multiple victims at exactly the same time, they will all compete with each other. The victims cannot increase the fee for the HTLC claiming transaction, because they are the ones who force-closed the channel. CPFP doesn't work, because their ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can claim the still pending HTLCs using an RBF transaction. So it is Alice who has to force close, which puts her at a big disadvantage. Malleroy will have to pay the lightning fees, but they are negligible. The fee for the on-chain force-close transaction (with the HTLC outputs) is paid by whoever opened the channel. AFAIK the fee for the HTLC resolving transactions is paid by whoever claims the HTLC. In this scenario it is paid from Alice's money. If Malleroy opened the channel, he risks losing some funds to on-chain fees. On the other hand the one who pays the fee controls the fee. He could negotiate a very low fee (say a cent per HTLC), when the network is idle and then wait for a natural congestion before starting the attack, giving him a low risk with high success probability. Every HTLC he can claim after timeout is profit. Regards, Jochen --000000000000e3006705aa7c8107 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 14 Jul 2020 at 16:42, ZmnSCPx= j via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good morning Mr. Lee,

> Sorry. Re-sending with correction to CC bitcoin-dev
>
> I am sorry if this was already brought up in previous threads. If I kn= ow
> lightning network correctly then HTLC is used to enforce settlements o= n
> blockchain if there is a dispute. Could a person lose money if their H= TLC
> does not get confirmed in the timeframe or if an older HTLC gets
> confirmed first? I see different ways this could happen.
>
> One, if the blockchain is very saturated with other transactions. The<= br> > reason we need lightning network is why it might have troubles with > settlements?

This could happen, but the entire exercise is to move transactions off the = blockchain, precisely to lower this risk.

Otherwise, transfers onchain will take a long time.
In practice, a long time to settle a payment will invalidate many real-worl= d economic exchanges anyway (consider paying for food at a restaurant --- i= f your payments take days to settle, the food has gotten stale before the r= estaurant receives payment and releases your food).
Thus, if an onchain transfer takes a long time to settle, there is already = risk of economic loss present.

By moving activity offchain, we reduce pressure onchain and improve settlem= ent speeds on both offchain and onchain, reducing risk of economic loss due= to delay.


> Two, competition from a different conflicting HTLC. A newer
> HTLC might not get confirmed before an older HTL.

I cannot make sense of this.

You cannot create conflicting HTLCs.

Co= rrect.=C2=A0 Removing or Creating an HTLC is something that both channel pa= rtners need to agree on.=C2=A0 They may create multiple pending HTLCs as lo= ng as there are enough funds, but creating conflicting HTLCs is not possibl= e.
=C2=A0
= >
> I found out about a recent attack technique that sounds like it might = be
> similar called "flood and loot".

Roughly, my understanding of Flood and Loot is to make a lot of uneconomica= lly tiny HTLCs going through a target victim forwarding node.
You make circular routes going from your own node back to yourself.
Then you refuse to actually claim the HTLCs sent back to yourself.

No, the way I understand it is that an attacker= , say Malleroy, routes a lot of medium sized HTLC payments from his node to= his node via a victim node, say Alice's, and possibly other=C2=A0nodes= .=C2=A0
Then Malleroy *accepts* the payments by publishing the ha= sh on the receiving end, so he gets all the sent funds on his receiving cha= nnel.=C2=A0 Malleroy's receiving node behaves completely honestly, and = nobody can prove that it belongs to the attacker.
Finally when Al= ice claims her HTLC by presenting the hash, Malleroy just ignores the claim= .=C2=A0 Now Alice, the victim, is forced to close the channel to prevent th= e HTLC to timeout. If Malleroy does it with multiple victims at exactly the= same time, they will all compete with each other.=C2=A0 The victims cannot= increase the fee for the HTLC claiming transaction, because they are the o= nes who force-closed=C2=A0the channel.=C2=A0 CPFP doesn't work, because= their ultimate output is CLTV'd.=C2=A0 As soon as the HTLC timeouts Ma= lleroy can claim the still pending HTLCs using an RBF transaction.

So it is Alice who has to force close, which puts her at a= big disadvantage.

Malleroy will have to pay the l= ightning fees, but they are negligible.=C2=A0 The fee for the on-chain forc= e-close transaction (with the HTLC outputs) is paid by whoever opened the c= hannel. AFAIK the fee for the HTLC resolving transactions is paid by whoeve= r claims the HTLC.=C2=A0 In this=C2=A0scenario it is paid from Alice's = money.=C2=A0 If Malleroy opened the channel, he risks losing some funds to = on-chain fees.=C2=A0 On the other hand the one who pays the fee controls th= e fee.=C2=A0 He could negotiate a very low fee (say a cent per HTLC), when = the network is idle and then wait for a natural congestion before starting = the attack, giving him a low risk with high success probability.=C2=A0 Ever= y HTLC he can claim after timeout is profit.

Regar= ds,
=C2=A0 Jochen

--000000000000e3006705aa7c8107--