From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C9492C004C for ; Tue, 4 Aug 2020 04:23:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id C38BA87939 for ; Tue, 4 Aug 2020 04:23:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3INYdruWymrd for ; Tue, 4 Aug 2020 04:23:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by hemlock.osuosl.org (Postfix) with ESMTPS id DAF8087935 for ; Tue, 4 Aug 2020 04:23:11 +0000 (UTC) Date: Tue, 04 Aug 2020 04:23:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1596514989; bh=KUbu7f+99mNV6AF23J6Ppas7LIbsUL7SzMBLFJ7hr1I=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=h6dXnmAnmwl1wmqC5x7OQwcDSOAfjBKoOdy7Y1qs1+t4CoD6jY3yJC9SWe0SrThRn F7ZPwWU1/7SezVdlXKfLWHLrkvLaruh3vEqaIQWJplbGjd7Jmd3r1EQZoqkpQpy6Yu oFpyXg8kfkBC/I8wH2y6rhXs5utFslefsGwNW7UY= To: "lf-lists@mattcorallo.com" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com> References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au> <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 04:23:13 -0000 Good morning Matt, > While I admit I haven=E2=80=99t analyzed the feasibility, I want to throw= one additional design consideration into the ring. > > Namely, it would ideally be trivial, at the p2p protocol layer, to relay = a transaction to a full node without knowing exactly which input transactio= n that full node has in its mempool/active chain. This is at least potentia= lly important for systems like lighting where you do not know which counter= party 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 none= theless. > > This is (obviously) an incredibly nontrivial problem both in p2p protocol= complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rath= er useless for lighting without it. > > The least we could do is think about the consensus design in that context= , even if we have to provide an external overlay relay network in order to = make lighting transactions relay properly (presumably with miners running s= uch software). Ah, right. A feasible attack, without the above, would be to connect to the fullnode o= f 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* confir= med transactions. So I think all the victim needs to do, in a Lightning universe utilizing pr= imarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events an= d 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 t= hat txid, unless a reorg unconfirms the transaction. We only need to be aware of deep reorgs and re-broadcast with a malleated p= revout until the tx being spent is deeply confirmed. In addition, we want to implement scorch-the-earth, keep-bumping-the-fee st= rategies anyway, so we would keep rebroadcasting new versions of the spendi= ng 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