diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-08-04 04:23:03 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-08-04 04:23:13 +0000 |
| commit | 88b74e8d11e882d55b3e2e9cd6d6dcbf56571642 (patch) | |
| tree | 31b64662e52049852b578491f4edfcc799155ba1 | |
| parent | ba6720270db9c64630d6c0669dcb01a643fba92f (diff) | |
| download | pi-bitcoindev-88b74e8d11e882d55b3e2e9cd6d6dcbf56571642.tar.gz pi-bitcoindev-88b74e8d11e882d55b3e2e9cd6d6dcbf56571642.zip | |
Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
| -rw-r--r-- | 1d/43c21eea66735e15273c779784db9d9e5f2dbc | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/1d/43c21eea66735e15273c779784db9d9e5f2dbc b/1d/43c21eea66735e15273c779784db9d9e5f2dbc new file mode 100644 index 000000000..d6dafa5d3 --- /dev/null +++ b/1d/43c21eea66735e15273c779784db9d9e5f2dbc @@ -0,0 +1,108 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C9492C004C + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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" <lf-lists@mattcorallo.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com> +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 <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 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 + |