From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: alicexbt <alicexbt@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP Meeting #9 Notes
Date: Fri, 20 May 2022 01:03:11 +0000 [thread overview]
Message-ID: <4FE6Gygz1J6ehzVcTMyfSGbhSPvvkg06LjxqKy-lhPgGlYOGAbxgjYEkGBys8iE09FCOOU1rzq2GLqnMNjMhbstTTdtYNqzHWaLro1CA5FM=@protonmail.com> (raw)
In-Reply-To: <Q26yJ8xABAnyKIAJ7nAt5er5Tok-tqvbQYhN7Wxh1xdlod-Kg5d7jefrxEgeini54ZIPup3jIGjmTx1gZBKEIjT7mYSQlXcTwG-Olo4pz8E=@protonmail.com>
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 it.
> 13:06 <@jeremyrubin> the covenants are "self executing" and can be e.g. sandwiched13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, 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, because then it makes complicated MEV extraction profitable, which then makes "smart" miners more profitable than "Dumb" ones, which is maybe centralising
Well that was interesting....
TLDR: MEV = Miner-extractable value, basically if your contracts are complex 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 executed.
(do correct me if that summary is inaccurate or incomplete)
As a concrete example: in a LN channel breach condition, the revocation transaction 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 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 bump up the fees and the miner could try again on the next block with the higher feerates.
Depending on the channel size and how the software behaves exactly, the miner 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 contract 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 revealed, however, in case of a dispute, multiple competing branches of the Taproot may be revealed by the disputants, and the miners may now be able to make 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 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 link between this previous transaction and some other one, a miner cannot extract additional value by messing with the ordering the transactions get confirmed on the blockchain, or whatever.
This may mean that mechanisms that inspect the block outside of the transaction being validated (e.g. `OP_BRIBE` for drivechains, or similar mechanisms that might be capable of looking beyond the transaction) should be verboten; such cross-transaction introspection should require an adaptor signature that is kept secret by the participants from the miner that might want to manipulate the transactions to make other alternate branches more favorable to the miner.
In addition, covenant mechanisms that require large witness data are probably 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 disputant 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 the contract, as they get more fees for less blockspace.
Of course, this mechanism itself can be used if we can arrange that the disputant 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
next prev parent reply other threads:[~2022-05-20 1:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-19 15:57 alicexbt
2022-05-20 1:03 ` ZmnSCPxj [this message]
2022-05-20 23:23 ` alicexbt
2022-05-20 23:47 ` ZmnSCPxj
2022-05-21 15:37 ` Bram Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='4FE6Gygz1J6ehzVcTMyfSGbhSPvvkg06LjxqKy-lhPgGlYOGAbxgjYEkGBys8iE09FCOOU1rzq2GLqnMNjMhbstTTdtYNqzHWaLro1CA5FM=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=alicexbt@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox