Date: Fri, 20 May 2022 23:23:58 +0000
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP Meeting #9 Notes
Precedence: list

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