Date: Fri, 20 May 2022 01:03:11 +0000
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
Precedence: list

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