path: root/d7/56b5f5cba4748105dcdff7901825a6c92bcd0b

Return-Path: <alicexbt@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1B041C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 May 2022 23:24:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E9A0C60FA3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 May 2022 23:24:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fnyTLOypXQxW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 May 2022 23:24:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
 [185.70.40.140])
 by smtp3.osuosl.org (Postfix) with ESMTPS id CE01B60F9C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 May 2022 23:24:11 +0000 (UTC)
Date: Fri, 20 May 2022 23:23:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1653089048; x=1653348248;
 bh=vSKnzbrYJV3Ic19gJR84qJeuEYxUv3ZweNI09+TVccg=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
 Feedback-ID:Message-ID;
 b=CZl2ucX/fYWCidztdzqJuKyG0O8JDlGFnIar29awYZH8GTUkoX1RScdee5luDs5+s
 VuGiyBcJo9gFnv+BIMoP9K0TQlqzcz7Yqmd5WQ5GdBl8NFoey1wRu4n8x+1ajJa0Su
 rC5QfUbexjdFA6IP9jSfiHw7g/On997Ltif0a9nGesp43x9vAQw5byrHVNElTHeDQ5
 R5UD5qF1ue7GKxTR2kjKoJ9ooRVrABoVnXBy8Y9Yi1EA5a+lTkihLxSWcXddRrCPI4
 RDusXPBoM7c63tDCeJikifDYgl+TloFUgsaxBYMlBCUBDoVkUCRGFIK51w/5W5YVhu
 6nj4HqL/wNTvg==
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Reply-To: alicexbt <alicexbt@protonmail.com>
Message-ID: <15z3VVTB7kcfg_qPey-bpkPtF551URlIDOq_qIvO9SdYWBW6duAfZjCOXT0o5hkQIdDznLsGSP9WqVw3ChXalEDyvttuUMyXT9x9SAqNfiE=@protonmail.com>
In-Reply-To: <4FE6Gygz1J6ehzVcTMyfSGbhSPvvkg06LjxqKy-lhPgGlYOGAbxgjYEkGBys8iE09FCOOU1rzq2GLqnMNjMhbstTTdtYNqzHWaLro1CA5FM=@protonmail.com>
References: <Q26yJ8xABAnyKIAJ7nAt5er5Tok-tqvbQYhN7Wxh1xdlod-Kg5d7jefrxEgeini54ZIPup3jIGjmTx1gZBKEIjT7mYSQlXcTwG-Olo4pz8E=@protonmail.com>
 <4FE6Gygz1J6ehzVcTMyfSGbhSPvvkg06LjxqKy-lhPgGlYOGAbxgjYEkGBys8iE09FCOOU1rzq2GLqnMNjMhbstTTdtYNqzHWaLro1CA5FM=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 20 May 2022 23:57:56 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 23:24:14 -0000

Hi ZmnSCPxj,


> TLDR: MEV =3D Miner-extractable value, basically if your contracts are co=
mplex enough, miners can analyze which of the possible contract executions =
are most profitable for them, and order transactions on the block they are =
building in such a way that it is the most profitable path that gets execut=
ed.
> (do correct me if that summary is inaccurate or incomplete)

Yes its elaborated as Miner Extractable Value and also referred as Maximal =
Extractable Value sometimes because value could be extracted by validators,=
 sequencers and others in some chains. MEV is basically frontrunning some t=
ransactions based on mempool activity for profit. Profit could be achieved =
by order or include/exclude some transactions in block. Normally such oppor=
tunities are only found in complex smart contracts that allow trades being =
settled on-chain.

In this (IRC logs) context, Jeremy mentioned sandwich attack. An attacker l=
ooks for buy orders in mempool, buy before others and profit from selling a=
t higher price.

> 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 co=
ntract details should be as little-revealed as possible, to reduce the scop=
e of miner-extractable value.

This makes sense and Tarun has shared similar ideas for AMMs in this pdf: h=
ttps://drive.google.com/file/d/1W6PtJhGgqlNTCENE7I5pO5Brh2oqasVc/view?usp=
=3Dsharing

> Probably, it is best if our covenants systems take full advantage of the =
linearity of Schnorr signing, in that case, if there is at all some kind of=
 branch involved; for example, a previous transaction may reveal, if you ha=
ve the proper adaptor signature, some scalar, and that scalar is actually t=
he `s` component for a signature of a different transaction.
> Without knowledge of the adaptor signature, and without knowledge of the =
link between this previous transaction and some other one, a miner cannot e=
xtract additional value by messing with the ordering the transactions get c=
onfirmed on the blockchain, or whatever.

I am assuming this is possible using all the bitcoin covenant proposals inc=
luding CTV.

> In addition, covenant mechanisms that require large witness data are prob=
ably more vulnerable to MEV.

Which covenant mechanisms require large witness data?


/dev/fd0

Sent with ProtonMail secure email.
------- Original Message -------
On Friday, May 20th, 2022 at 6:33 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wr=
ote:


> Good morning fd0,
>
> > MEV could be one the issues associated with general covenants. There ar=
e some resources on https://mev.day if anyone interested to read more about=
 it.
> > 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g.=
 sandwiched13:07 <@jeremyrubin> so given that bitmatrix is sandwich attacka=
ble, you'd see similar types of MEV as Eth sees13:07 <@jeremyrubin> v.s. th=
e 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 co=
mplex enough, miners can analyze which of the possible contract executions =
are most profitable for them, and order transactions on the block they are =
building in such a way that it is the most profitable path that gets execut=
ed.
> (do correct me if that summary is inaccurate or incomplete)
>
> As a concrete example: in a LN channel breach condition, the revocation t=
ransaction must be confirmed within the CSV timeout, or else the theft will=
 be accepted and confirmed.
> Now, some software will be aware of this timeout and will continually rai=
se the fee of the revocation transaction per block.
> A rational miner which sees a channel breach condition might prefer to no=
t mine such a transaction, since if it is not confirmed, the software will =
bump up the fees and the miner could try again on the next block with the h=
igher feerates.
> Depending on the channel size and how the software behaves exactly, the m=
iner may be able to make a decision on whether it should or should not work=
 on 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 co=
ntract details should be as little-revealed as possible, to reduce the scop=
e of miner-extractable value.
> For instance, Taproot is good since only one branch at a time can be reve=
aled, however, in case of a dispute, multiple competing branches of the Tap=
root may be revealed by the disputants, and the miners may now be able to m=
ake a choice.
>
> Probably, it is best if our covenants systems take full advantage of the =
linearity of Schnorr signing, in that case, if there is at all some kind of=
 branch involved; for example, a previous transaction may reveal, if you ha=
ve the proper adaptor signature, some scalar, and that scalar is actually t=
he `s` component for a signature of a different transaction.
> Without knowledge of the adaptor signature, and without knowledge of the =
link between this previous transaction and some other one, a miner cannot e=
xtract additional value by messing with the ordering the transactions get c=
onfirmed on the blockchain, or whatever.
>
> This may mean that mechanisms that inspect the block outside of the trans=
action being validated (e.g. `OP_BRIBE` for drivechains, or similar mechani=
sms that might be capable of looking beyond the transaction) should be verb=
oten; such cross-transaction introspection should require an adaptor signat=
ure that is kept secret by the participants from the miner that might want =
to manipulate the transactions to make other alternate branches more favora=
ble to the miner.
>
> In addition, covenant mechanisms that require large witness data are prob=
ably more vulnerable to MEV.
> For instance, if in a dispute case, one of the disputants needs to use a =
large witness data while the other requires a smaller one, then the disputa=
nt with the smaller witness data would have an advantage, and can match the=
 fee offered by the disputant with the larger witness.
> Then a fee-maximizing miner would prefer the smaller-witness branch of th=
e contract, as they get more fees for less blockspace.
> Of course, this mechanism itself can be used if we can arrange that the d=
isputant that is inherently "wrong" (i.e. went against the expected behavio=
r 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