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 C6C1EC004C for ; Tue, 4 Aug 2020 13:10:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id B595487E98 for ; Tue, 4 Aug 2020 13:10:06 +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 c8mY4aYZFISR for ; Tue, 4 Aug 2020 13:10:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id 97B3187E80 for ; Tue, 4 Aug 2020 13:10:05 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 8F7F42C1937; Tue, 4 Aug 2020 13:10:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Tue, 4 Aug 2020 09:10:02 -0400 Message-Id: <735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com> References: In-Reply-To: To: ZmnSCPxj 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 13:10:06 -0000 Hmm, apologies that little context was provided - this was meant in the cont= ext 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 for as pl= acing commitment transactions in mempools can be used to prevent honest node= s from broadcasting the latest state. This implies that HTLC security may be= at risk. > On Aug 4, 2020, at 00:23, ZmnSCPxj wrote: >=20 > =EF=BB=BFGood morning Matt, >=20 >> While I admit I haven=E2=80=99t analyzed the feasibility, I want to throw= one additional design consideration into the ring. >>=20 >> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a= transaction to a full node without knowing exactly which input transaction t= hat full node has in its mempool/active chain. This is at least potentially i= mportant for systems like lighting where you do not know which counterparty c= ommitment transaction(s) are in a random node=E2=80=99s mempool and you shou= ld be able to describe to that node that you are spending then nonetheless. >>=20 >> This is (obviously) an incredibly nontrivial problem both in p2p protocol= complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rathe= r useless for lighting without it. >>=20 >> 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 m= ake lighting transactions relay properly (presumably with miners running suc= h software). >=20 > Ah, right. >=20 > 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 yo= u 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 se= e B in the mempool. >=20 > On the other hand --- what the victim needs to react to is *onchain* confi= rmed transactions. > So I think all the victim needs to do, in a Lightning universe utilizing p= rimarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events an= d ignore mempool events. >=20 > 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 w= ithout a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to tha= t 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. >=20 > In addition, we want to implement scorch-the-earth, keep-bumping-the-fee s= trategies anyway, so we would keep rebroadcasting new versions of the spendi= ng transaction, and spending from a transaction that is confirmed. >=20 > Or are there other attack vectors you can see that I do not? > I think this is fixed by looking at the blockchain. >=20 > Regards, > ZmnSCPxj