diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2020-08-04 09:10:02 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-08-04 13:10:06 +0000 |
| commit | 099c6797704072b0da12e204724a2188f3b7a1bb (patch) | |
| tree | e3c919b4690b82e8c22826a68dedabda7e0cb53b | |
| parent | b10258c4ad0333e064c12d5ca4c3edee6b2ca2dd (diff) | |
| download | pi-bitcoindev-099c6797704072b0da12e204724a2188f3b7a1bb.tar.gz pi-bitcoindev-099c6797704072b0da12e204724a2188f3b7a1bb.zip | |
Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
| -rw-r--r-- | 29/c9fc5248120fdf2111515c71af0f338d9b4799 | 109 |
1 files changed, 109 insertions, 0 deletions
diff --git a/29/c9fc5248120fdf2111515c71af0f338d9b4799 b/29/c9fc5248120fdf2111515c71af0f338d9b4799 new file mode 100644 index 000000000..a5948f11f --- /dev/null +++ b/29/c9fc5248120fdf2111515c71af0f338d9b4799 @@ -0,0 +1,109 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C6C1EC004C + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <lf-lists@mattcorallo.com> +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: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com> +In-Reply-To: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <ZmnSCPxj@protonmail.com> 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 + |