diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2022-05-20 01:03:11 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-20 01:03:23 +0000 |
| commit | 1468f60423b2538d0ebe6352c2ea77f868d5bbac (patch) | |
| tree | bb0d82c6560333afd6b6914ddc1f5242d783894c | |
| parent | 34a8eb5d2c45b1f096123f1cc960d4ae499ad748 (diff) | |
| download | pi-bitcoindev-1468f60423b2538d0ebe6352c2ea77f868d5bbac.tar.gz pi-bitcoindev-1468f60423b2538d0ebe6352c2ea77f868d5bbac.zip | |
Re: [bitcoin-dev] CTV BIP Meeting #9 Notes
| -rw-r--r-- | 3b/479819190f11005fdb46049f0e39e177b67410 | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/3b/479819190f11005fdb46049f0e39e177b67410 b/3b/479819190f11005fdb46049f0e39e177b67410 new file mode 100644 index 000000000..f4a99c08b --- /dev/null +++ b/3b/479819190f11005fdb46049f0e39e177b67410 @@ -0,0 +1,152 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id DA168C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 20 May 2022 01:03:23 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id CFDD9844F1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 20 May 2022 01:03:23 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.602 +X-Spam-Level: +X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, + SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=protonmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id gsDO8dxHIT24 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 20 May 2022 01:03:22 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 09021844F0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 20 May 2022 01:03:21 +0000 (UTC) +Date: Fri, 20 May 2022 01:03:11 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1653008599; x=1653267799; + bh=Vjea3/vGI7VnQbdvSeDjvdIS3xAvc6jX+KqVXibBm6g=; + h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: + Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID; + b=hEsKwtue1mY7Y4sHkYPW8sKIcv+31L1aJrVnUixDs0iYIl8eqy+VOFMPTDv/Y6BCy + UDbg493dPwuy8VLehiLosXig5y0T41GXYpUr2IqmvIqHwyGcxSH6Mw0NwzHCFPbNQD + cdRzCTOeyhuYsYKo0Pt5cF9C5xT8HNJQpnTyM//JWYjdhKM7Hy/gKUE6Qr01NgR0v/ + kr7SD7niVzdYv98ZHRs2GevO1D9m6hKKNnQXElRZKVtoGxn/FxN1I6d4V4Uk+EMST/ + iFZyttbiulKzwpXS7f35TuONgr2xUAaAoDWIhannQADpK+725q8ZsmmhbRITZZTJri + gplaZvkn9nFhg== +To: alicexbt <alicexbt@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <4FE6Gygz1J6ehzVcTMyfSGbhSPvvkg06LjxqKy-lhPgGlYOGAbxgjYEkGBys8iE09FCOOU1rzq2GLqnMNjMhbstTTdtYNqzHWaLro1CA5FM=@protonmail.com> +In-Reply-To: <Q26yJ8xABAnyKIAJ7nAt5er5Tok-tqvbQYhN7Wxh1xdlod-Kg5d7jefrxEgeini54ZIPup3jIGjmTx1gZBKEIjT7mYSQlXcTwG-Olo4pz8E=@protonmail.com> +References: <Q26yJ8xABAnyKIAJ7nAt5er5Tok-tqvbQYhN7Wxh1xdlod-Kg5d7jefrxEgeini54ZIPup3jIGjmTx1gZBKEIjT7mYSQlXcTwG-Olo4pz8E=@protonmail.com> +Feedback-ID: 2872618:user:proton +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +Subject: Re: [bitcoin-dev] CTV BIP Meeting #9 Notes +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: Fri, 20 May 2022 01:03:24 -0000 + +Good morning fd0, + + +> MEV could be one the issues associated with general covenants. There are = +some resources on https://mev.day if anyone interested to read more about i= +t. +> 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. s= +andwiched13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackabl= +e, you'd see similar types of MEV as Eth sees13:07 <@jeremyrubin> v.s. the = +MEV of e.g. lightning channels +> 13:14 < _aj_> i guess i'd rather not have that sort of MEV available, bec= +ause then it makes complicated MEV extraction profitable, which then makes = +"smart" miners more profitable than "Dumb" ones, which is maybe centralisin= +g + +Well that was interesting.... + +TLDR: MEV =3D Miner-extractable value, basically if your contracts are comp= +lex enough, miners can analyze which of the possible contract executions ar= +e most profitable for them, and order transactions on the block they are bu= +ilding in such a way that it is the most profitable path that gets executed= +. +(do correct me if that summary is inaccurate or incomplete) + +As a concrete example: in a LN channel breach condition, the revocation tra= +nsaction must be confirmed within the CSV timeout, or else the theft will b= +e accepted and confirmed. +Now, some software will be aware of this timeout and will continually raise= + the fee of the revocation transaction per block. +A rational miner which sees a channel breach condition might prefer to not = +mine such a transaction, since if it is not confirmed, the software will bu= +mp up the fees and the miner could try again on the next block with the hig= +her feerates. +Depending on the channel size and how the software behaves exactly, the min= +er may be able to make a decision on whether it should or should not work o= +n the revocation transaction and instead hold out for a later higher fee. + +Now, having thought of this problem for no more than 5 minutes, it seems to= + me, naively, that a mechanism with privacy would be helpful, i.e. the cont= +ract details should be as little-revealed as possible, to reduce the scope = +of miner-extractable value. +For instance, Taproot is good since only one branch at a time can be reveal= +ed, however, in case of a dispute, multiple competing branches of the Tapro= +ot may be revealed by the disputants, and the miners may now be able to mak= +e a choice. + +Probably, it is best if our covenants systems take full advantage of the li= +nearity of Schnorr signing, in that case, if there is at all some kind of b= +ranch involved; for example, a previous transaction may reveal, if you have= + the proper adaptor signature, some scalar, and that scalar is actually the= + `s` component for a signature of a different transaction. +Without knowledge of the adaptor signature, and without knowledge of the li= +nk between this previous transaction and some other one, a miner cannot ext= +ract additional value by messing with the ordering the transactions get con= +firmed on the blockchain, or whatever. + +This may mean that mechanisms that inspect the block outside of the transac= +tion being validated (e.g. `OP_BRIBE` for drivechains, or similar mechanism= +s that might be capable of looking beyond the transaction) should be verbot= +en; such cross-transaction introspection should require an adaptor signatur= +e that is kept secret by the participants from the miner that might want to= + manipulate the transactions to make other alternate branches more favorabl= +e to the miner. + +In addition, covenant mechanisms that require large witness data are probab= +ly more vulnerable to MEV. +For instance, if in a dispute case, one of the disputants needs to use a la= +rge witness data while the other requires a smaller one, then the disputant= + with the smaller witness data would have an advantage, and can match the f= +ee offered by the disputant with the larger witness. +Then a fee-maximizing miner would prefer the smaller-witness branch of the = +contract, as they get more fees for less blockspace. +Of course, this mechanism itself can be used if we can arrange that the dis= +putant that is inherently "wrong" (i.e. went against the expected behavior = +of the protocol) is the one that is burdened with the larger witness. + +Or I could be entirely wrong and MEV is something even worse than that. + +Hmmmmmm + +Regards, +ZmnSCPxj + |