From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id DA168C002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <4FE6Gygz1J6ehzVcTMyfSGbhSPvvkg06LjxqKy-lhPgGlYOGAbxgjYEkGBys8iE09FCOOU1rzq2GLqnMNjMhbstTTdtYNqzHWaLro1CA5FM=@protonmail.com> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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