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 4F4D3C004C for ; Tue, 4 Aug 2020 10:38:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 3EEED84C19 for ; Tue, 4 Aug 2020 10:38:35 +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 2QBtoMfvMhaj for ; Tue, 4 Aug 2020 10:38:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by fraxinus.osuosl.org (Postfix) with ESMTPS id D8A35849DF for ; Tue, 4 Aug 2020 10:38:33 +0000 (UTC) Received: by mail-ej1-f48.google.com with SMTP id kq25so28906792ejb.3 for ; Tue, 04 Aug 2020 03:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=88uM8A6Hd3yclt8ZTHWna57u2Ykmn/HjGQt9HTQlEMQ=; b=pM2FQtDHHhTTiAgrsvi4iHc5fgrRIcpmAEV4Ux77IHrf4gbtohESxM/42B8pgABXOE qpBBrMSELQOLKrkxU4KWKQKOY54Sbr8LztvmN77VMmWTVYnbvm4mWlYps/nEGLBbuTrY EbgHJKq8uhXYCVs0BYSqVo0n05yXglUWtH0HqdX98TGTs6AFqkvflYdEtjn4Nofhr6MG hxj3pwqJ8nvDhnDuNwzWOTheUlpeCXAFJVda5lHUJXKEF+T5QfSh1siPw0gm9ZHrL4Ph 8gnNfWN/n96MNJV8Wi+iH6BqgBQ/W1I4ixsTY/gP9PAorA4RBp5Lsz7sbyCAbploM31t iuag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=88uM8A6Hd3yclt8ZTHWna57u2Ykmn/HjGQt9HTQlEMQ=; b=YYAn/L22s+4fEKwQa8I7qxgbq6EQBhsPpQIrrNuZXFz8/OxWjn7o22JVsmz92CkXTM He9lwNf6FAF9KUNpN0XB146plVcBXhEAGSUFGUfVoHes7E9FazhZqLfviT4iL0acpjkO qNwteqqTJG3Iyd26H3cWjifd4p1gOm1m7KtohcGt9p7sFqP1q4DAi+/1dmfK4SUNNJq7 spSmGLDvZ4qhA+YihbRAleRiT/wwwSXPMEk0EcUAvEzL6RKSYG4Cz842HLDmvCCsrc0X bHUCtKJVpclWdvKZB1XBpg/8YV6wCgzGY9MBlwDyuOmVpMnLJCEq+7mB8KpHpFylchVy IeIw== X-Gm-Message-State: AOAM533ij2iYDO8GC5J7xoL4rLa5tO6VVvVKtHudyPAqurXjtAfzy6w+ OatAaKCXmV0eiWcj//lsL/k= X-Google-Smtp-Source: ABdhPJzwtR6Q2zP1+sBqn58wjmutqQYawAPviueefQfHhtBOtFKwzp9lheKLWUjDILadZCG3vA9OIQ== X-Received: by 2002:a17:906:1104:: with SMTP id h4mr20752414eja.456.1596537512098; Tue, 04 Aug 2020 03:38:32 -0700 (PDT) Received: from localhost (243.86.254.84.ftth.as8758.net. [84.254.86.243]) by smtp.gmail.com with ESMTPSA id x20sm18444142edl.8.2020.08.04.03.38.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Aug 2020 03:38:29 -0700 (PDT) From: Christian Decker To: ZmnSCPxj , Bitcoin Protocol Discussion , "lf-lists\@mattcorallo.com" , Bitcoin Protocol Discussion In-Reply-To: References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au> <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com> Date: Tue, 04 Aug 2020 12:38:20 +0200 Message-ID: <87zh7ay9ur.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain 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 10:38:35 -0000 > Ah, right. > > A feasible attack, without the above, would be to connect to the > fullnode 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* > confirmed transactions. So I think all the victim needs to do, in a > Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based > mechanisms, is to monitor onchain events and ignore mempool events. > > So if we give fairly long timeouts for our mechanisms, it should be > enough, I think, since once a transaction is confirmed its txid does > not malleate 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 malleated prevout until the tx being spent is deeply confirmed. This is indeed part of the reason why we chose to describe the protocol on-chain first in the paper and lift it off-chain after showing the basic functionality. This means that the protocol is still correct even if executed solely on information derived from blocks and confirmed transactions in those blocks. The timeouts have to be chosen carefully to allow reacting in a timely fashion, however that is true for all off-chain protocols. > In addition, we want to implement scorch-the-earth, > keep-bumping-the-fee strategies anyway, so we would keep > rebroadcasting new versions of the spending transaction, and spending > from a transaction that is confirmed. Correct, it might be desirable to give a misbehaving node a papercut by letting their update transaction confirm (taking their fee along with it) and then reacting to the outdated update by overriding the effects with a new update-settlement pair. So, while being able to react to a transaction in the memory pool early might be a nice addition, it is not strictly required for safety of the protocol. I say nice addition, because it can allow replacing the outdated transaction directly, thus saving the misbehaving node from the fee papercut, but also save a bit of blockspace which that fee would have paid for, and leave it available for other transactions. Cheers, Christian