From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E5561C0733; Tue, 14 Jul 2020 14:42:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id C92CE20354; Tue, 14 Jul 2020 14:42:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkuSY34hUhTL; Tue, 14 Jul 2020 14:42:28 +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-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by silver.osuosl.org (Postfix) with ESMTPS id 687011FE0A; Tue, 14 Jul 2020 14:42:28 +0000 (UTC) Date: Tue, 14 Jul 2020 14:42:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1594737745; bh=HhL4wgnRbQCsjXH8ZvpBuibWyQLOiGGLbhChXBYERmc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=cULZ5QzYA2Oz5ZR6gmgCHFtM5jgOmiwmk3IgYvGGb1JbbQv45hxajCygwRgcbM2Eo YTZihGzYShl6M3xPQyUpA8Edhy89q/ED7Hjn43NPGifVXNlX830uwIGpDN54VqwhqL 6dihMxPrMuVZWzTSiU2Xm7IYKf+J2DrN0CKZbw3w= To: "Mr. Lee Chiffre" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <6443d6fb7ba06151b8a4ff4914761471.squirrel@giyzk7o6dcunb2ry.onion> References: <6443d6fb7ba06151b8a4ff4914761471.squirrel@giyzk7o6dcunb2ry.onion> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 14 Jul 2020 14:42:31 -0000 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-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. Either you have some free money to create an HTLC, in which case there is n= o possible conflict with an existing HTLC (the fund is reserved for HTLCs, = or it is yours without further encumbrance). Thus it is not possible to create a conflicting HTLC in any case: either yo= u have funds (that are not already in an HTLC) to fund an HTLC and that HTL= C cannot conflict with existing ones, or you have no funds and a new HTLC c= annot be created until one of the HTLCs is resolved one way or another. > Three, denial of service > the lightning router so they never have a chance to send a settlement > HTLC. This is possible, but only that node risks loss. The reason why unilateral close is always possible is to handle the case wh= ere a routing node comes offline. If you have offered an HTLC to a routing node, you retain a timelock branch= back to you (the "T" in HTLC). If the routing node goes offline past the timelock in the HTLC, then you un= ilaterally close the channel and drop the HTLC onchain. This is what lets you recover your funds. > > 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. Then you go offline. This means that the only way for the forwarding node to recover its funds i= s to drop the channel(s) involved onchain. But if the HTLCs are many and tiny, they are simply too uneconomic to claim= onchain, so they just lose the channel funds as fees. > > Is this a concern on lightning network? Yes. Work is being done (anchor commitments) to mitigate the effects of onchain = fees on Lightning. > I humbly say that I do not fully > understand all of lightning network yet. I am working to grasp the idea. > These are questions I look to find answer for. Another question I have. I > did read the paper Scalable Funding of Bitcoin Micropayment Channel > Networks. Would channel factories be better and eliminate my concern? They would not. Ultimately, your "final defense" is to drop the entire construction onchain= until you reach the HTLCs and you can have the blockchain enforce the HTLC= contract. It would *help* to reduce blockchain bloat by reducing the size of transact= ions to create multiple channels, and thus also secondarily helps reduce on= chain fee pressure and also reduce Flood-and-Loot (which is basically a lay= er-crossing attack, taking advantage of lower-layer fees to create attacks = on higher layers). But always the underlying problem remains: security costs something, and yo= u have to pay for protection on the Internet when transacting with potentia= lly untrusted (and untrustable) entities. It seems unlikely that "security costs something" can be eliminated. One can consider that modern-day state-imposed taxation is paying for secur= ity, for instance, of traditional face-to-face transactions. With Bitcoin, you can choose to either transact and pay for security, or no= t transact and forgo what you would have bought. With some tradeoffs, you can pay by other means that may be cheaper for you= . Regards, ZmnSCPxj