Hi Bitcoin Developers,
Summary for the last CTV meeting:
Topics:
1)OP_TX
2)OP_CAT / CSFS / General Covenants
3)Script interpreter flags
===================================================
OP_TX
===================================================
Jeremy Rubin thinks that if folks believe OP_TX is a superior upgrading path,
he would be delighted to shift focus. Although prefers more thorough evaluation
of CTV / NOP upgradability vs the multibyte op-success.
Anthony Towns doesn't find OP_TX interesting if it just does CTV from start. He
prefers adding SEPARATELY, UNHASHED and maybe things to do APO equivalent
behavior.
Harding considers OP_TX==OP_CTV only somewhat more interesting than just OP_CTV
because it provides a very clear upgrade path. He would be more interested if
it came with a few more initial features.
===================================================
OP_CAT / CSFS / General Covenants
===================================================
Harding believes that concerns regarding general covenants are unfounded. He
indicated an interest in learning more about one of ZmnSCPxj's criticisms,
which is the only one about which he is personally concerned. It has to do with
general covenants making scripts more difficult to evaluate.
Harding's thoughts on CAT+CSFS:
13:01 < harding> Without regard to the generalized covenants concern, I think
CAT+CSFS add the smallest amount of consensus complexity to enable the greatest
amount of experimentation with covenants and other features (like signature
delegation), which can provide significant data about real-world usage for
informing future soft fork designs. There'd still be lots of question marks,
plus chances for abuse (e.g. the sort of tx spamming we saw during the block
13:01 < harding> size debates), but I think it's worth giving devs the tools to
experiment onchain (with only their and their supporters' money) and allowing
economic full node operators to evualuate actual use before agreeing to enforce
future soft forks whose code will need to be maintained in perpetuitity.
13:02 < harding> Consensus stability is a reference to, for example, being able
to implement something like drivechains on top of CAT+CSFS?
Jeremy Rubin shared some issues that are being discussed on mailing list and
social media related to general bitcoin covenants:
- Scripts harder to analyze
- Fungibility
- MEV & consensus stability
- Whitelist/Blacklist
Anthony Towns and TechMiX added that some users think covenants can be imposed
on their coins without consent or everyone will accept covenants so unable to
pay them. Some bitcoin users in Iran are afraid that a generalized form of the
covenants would enable some kind of censorship.
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.
sandwiched
13:07 <@jeremyrubin> so given that bitmatrix is sandwich attackable, you'd see
similar types of MEV as Eth sees
13: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
===================================================
Script interpreter flags
===================================================
Anthony Towns likes the idea of documenting exactly what rules the flags are
meant to enforce (associated BIPs).
13:54 <@jeremyrubin> The test flags infrastructure relies on some particular
features of validity/invalidity and flagging, which has previously been avoided
surfacing because upgrades were at the output type level. The way the flagging
works is a not quite the right thing for testability and simple consensus code,
it's worth re-evaluating?
13:55 < _aj_> we changed how "things are done" with taproot, and need to
re-evaluate how we do script enforcement in light of wanting to keep doing
things that way?
13:56 < _aj_> we don't really have to do things the way we did for taproot, but
i thought it was kind-of nice, i guess
13:56 <@jeremyrubin> Well taproot just sidestepped the issue because it was an
outputtype
13:56 < _aj_> taproot had it easy because it was an outputtype
13:57 <@jeremyrubin> yes
IRC Logs: https://gnusha.org/ctv-bip-review/2022-05-17.log
/dev/fd0
Sent with [ProtonMail](https://protonmail.com/) secure email.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
