From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: alicexbt <alicexbt@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV BIP Meeting #9 Notes
Date: Fri, 20 May 2022 23:47:54 +0000 [thread overview]
Message-ID: <bLiy9L3lrXcUEjguWaAamJ07dQAe7frz2118VgwGu9ikIHsUSD1rwpcF22ko4LmnKCza60-_4YlU7kmsfOBztGQcHvj2xVMfrGLNWw-mYgE=@protonmail.com> (raw)
In-Reply-To: <15z3VVTB7kcfg_qPey-bpkPtF551URlIDOq_qIvO9SdYWBW6duAfZjCOXT0o5hkQIdDznLsGSP9WqVw3ChXalEDyvttuUMyXT9x9SAqNfiE=@protonmail.com>
Good morning fd0,
> > In addition, covenant mechanisms that require large witness data are probably more vulnerable to MEV.
>
>
> Which covenant mechanisms require large witness data?
`OP_CSFS` + `OP_CAT`, which requires that you copy parts of the transaction into the witness data if you want to use it for covenants.
And the script itself is in the witness data, and AFAIK `OP_CSFS` needs large scripts if used for covenants.
Arguably though `OP_CSFS` is not designed for covenants, it just *happens to enable* covenants when you throw enough data at it.
If we are going to tolerate recursive covenants, we might want an opcode that explicitly supports recursion, instead of one that happens to enable recursive covenants, because the latter is likely to require more data to be pushed on the witness stack.
E.g. instead of the user having to quine the script (i.e. the script is really written twice, so it ends up doubling the witness size of the SCRIPT part), make an explicitly quining opcode.
Basically, Do not Repeat Yourself.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-05-20 23:48 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
2022-05-20 23:23 ` alicexbt
2022-05-20 23:47 ` ZmnSCPxj [this message]
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='bLiy9L3lrXcUEjguWaAamJ07dQAe7frz2118VgwGu9ikIHsUSD1rwpcF22ko4LmnKCza60-_4YlU7kmsfOBztGQcHvj2xVMfrGLNWw-mYgE=@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