From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3779FC004C for ; Tue, 4 Aug 2020 15:00:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 25C2B86356 for ; Tue, 4 Aug 2020 15:00:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLUkZ3QIl71W for ; Tue, 4 Aug 2020 15:00:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by fraxinus.osuosl.org (Postfix) with ESMTPS id D493084F24 for ; Tue, 4 Aug 2020 15:00:01 +0000 (UTC) Date: Tue, 04 Aug 2020 14:59:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1596553199; bh=onJpplAw7odxI8LAvRzfXAapQ/sDnv6MytHCyezgAeo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=udeAEP09gPVE7ppCyVIFmS1jX1vIeL2ssHU5/2u1TtGHB5x//hK/GVOBJyEgckGcq WZ4jzFxSzRK1dZuOVo05MSfuPFj3gUKZduyj7TYaKlRDH8qgCwa4ThRYBjtFDRscsD 39pF+8vQBmHbVL883RMRWjodTGHjpg4Yntdp7x3Y= To: Matt Corallo From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com> References: <735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT 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, 04 Aug 2020 15:00:04 -0000 Good morning Matt, > Hmm, apologies that little context was provided - this was meant in the c= ontext of the current crop of relay-based attacks that have been discovered= . As we learned in those contexts, =E2=80=9Cjust handle it when it confirms= =E2=80=9D doesn=E2=80=99t provide the types of guarantees we were hoping fo= r as placing commitment transactions in mempools can be used to prevent hon= est nodes from broadcasting the latest state. This implies that HTLC securi= ty may be at risk. > Ah, okay. So the attack is this: * Attacker connects twice to the LN: one to any node near the victim, one t= o the victim. * Attacker arranges for the attacker-victim channel to have most funds in t= he side of the victim. * The attacker routes a circular payment terminating in the victim-attacker= channel. * The victim accepts some incoming HTLC, and provides an outgoing HTLC to= the attacker via the victim-attacker channel. * The attacker broadcasts a very low-fee old-state transaction of the victi= m-attacker channel, one that is too low-fee to practically get confirmed, j= ust before the HTLC timeout. * The victim-outgoing HTLC times out, making the victim broadcast a unilate= ral close attempt for the victim-attacker channel in order to enforce the H= TLC onchain. * Unfortunately for the victim, relay shenanigans prevent the latest comm= itment from being broadcast. * The attacker waits for the victim-incoming HTLC to timeout, which forces = the victim to `update_htlc_failed` the incoming HTLC or risk having that ch= annel closed (and losing future routing fees). * The attacker now gets back its outgoing funds. * The attacker lets the old-state transaction get relayed, and then re-seat= s the latest update transaction to that. * Once the latest transaction allows the HTLCs to be published, the attacke= r claims the victim-outgoing HTLC with the hashlock branch. * The attacker now gets its incoming funds, doubling its money, because t= hat is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works ri= ght? Hmmm. The only thing I can imagine helping here is for the forwarding node to dro= p channels onchain "early", i.e. if the HTLC will time out in say 14 blocks= we drop the channel onchain, so we have a little leeway in bumping up fees= for the commitment transaction. Maybe. I am sure Matt can find yet another relay attack that prevents that, at thi= s point, haha. "Are we *still* talking about onchain fees....?" - Adelaide 2018 Regards, ZmnSCPxj > > On Aug 4, 2020, at 00:23, ZmnSCPxj ZmnSCPxj@protonmail.com wrote: > > Good morning Matt, > > > > > While I admit I haven=E2=80=99t analyzed the feasibility, I want to t= hrow one additional design consideration into the ring. > > > Namely, it would ideally be trivial, at the p2p protocol layer, to re= lay a transaction to a full node without knowing exactly which input transa= ction that full node has in its mempool/active chain. This is at least pote= ntially important for systems like lighting where you do not know which cou= nterparty commitment transaction(s) are in a random node=E2=80=99s mempool = and you should be able to describe to that node that you are spending then = nonetheless. > > > This is (obviously) an incredibly nontrivial problem both in p2p prot= ocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT = rather useless for lighting without it. > > > The least we could do is think about the consensus design in that con= text, even if we have to provide an external overlay relay network in order= to make lighting transactions relay properly (presumably with miners runni= ng such software). > > > > Ah, right. > > A feasible attack, without the above, would be to connect to the fullno= de of the victim, and connect to miners separately. > > Then you broadcast to the victim one of the old txes, call it tx A, but= you broadcast to the miners a different old tx, call it B. > > The victim reacts only to tA, but does not react to B since it does not= see B in the mempool. > > On the other hand --- what the victim needs to react to is onchain conf= irmed transactions. > > So I think all the victim needs to do, in a Lightning universe utilizin= g primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain event= s and ignore mempool events. > > So if we give fairly long timeouts for our mechanisms, it should be eno= ugh, I think, since once a transaction is confirmed its txid does not malle= ate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" = to that txid, unless a reorg unconfirms the transaction. > > We only need to be aware of deep reorgs and re-broadcast with a malleat= ed prevout until the tx being spent is deeply confirmed. > > In addition, we want to implement scorch-the-earth, keep-bumping-the-fe= e strategies anyway, so we would keep rebroadcasting new versions of the sp= ending transaction, and spending from a transaction that is confirmed. > > Or are there other attack vectors you can see that I do not? > > I think this is fixed by looking at the blockchain. > > Regards, > > ZmnSCPxj