1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id DA168C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
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 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
|
