Hi Bitcoin Developers,
Summary for the last CTV meeting:
Topics:
1)APO version of the simple vault
2)APO as alternative to CTV
3)fiatjaf's CTV spacechain demo
4)Compare CTV with other covenant proposals
5)Recursive covenants
6)Responding to FUD
===================================================
APO version of the simple vault
===================================================
- It is vulnerable to the half-spend problem, where multiple vaulted outputs
(of the same denomination) can be spent together, burning all but the first to
fees. Fixing this requires amending APOAS to cover the current input index.
- The unvault transaction is third-party malleable (it can have more inputs
added to it). One practical implication is that you can't hand a list of the
unvault txids to a watchtower, you have to tell them which outpoints to watch
which is less privacy-preserving. Fixing this requires amending APOAS to cover
the number of inputs.
Both of these issues are fixed by the BIP 118 changes suggested by darosior
(although they still not officially spec'd afaik), which would basically make
APO have a CTV-equivalent hash mode (minus scriptSig of other inputs)
- simple-apo-vault could use APO-as-spec'd with
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend problem
(but not malleability) and have some other interesting properties, like more
natural dynamic fees (add inputs+change) and the ability spend multiple vaulted
outputs together. This would, however, introduce a tx pinning attack vector and
prevent rate-limited vaults.
===================================================
APO as alternative to CTV
===================================================
- Current APO is unusable as a CTV alternative, (revised)APO seems to be as
useful as CTV is (plus some extra flexibility from existing sighash flags)
- Main drawbacks being the additional witness satisfaction cost, the
network-side full-node validation costs of checking a signature instead of just
a hash, and not being segwit0-compatible (meaning, among others, not
quantumphobic-friendly)
- Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and
CTV-in-bare-spk get you even more savings
- APO is far from being ready, let alone (revised)APO
- APOv2 would be both better for Eltoo and better for CTV, since you can use a
trick to make the signatures smaller
- "layered commitments" is essential for eltoo to be usable or not is unclear.
AJ Towns thinks it is required while Christian Decker thinks it is not.
===================================================
fiatjaf's CTV spacechain demo
===================================================
https://github.com/fiatjaf/simple-ctv-spacechain
===================================================
Compare CTV with other covenant proposals
===================================================
Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really actually a
defined way to compare them. So one exercise of value would be if everyone
tries to actually either agree to or come up with their own framework for
comparing covenants.
Billy Tetrud's email:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html
- Prefers CTV for several reasons. Mainly because of being simple,
documentation, code, tools, review and testing.
- Everything else either introduces malleability, infinite recursion, or has
interactions with other proposed opcodes that could introduce potentially
undesirable effects like those.
- Anything involving OP_CAT is out for the time being. There are so many things
it can enable that it seems most people aren't comfortable adding it at the
moment.
- APO wallet vaults seem rather hacky, inefficient, and limited.
- TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and OP_CHECKOUTPUTVERIFY
allows recursive covenants
===================================================
Recursive covenants
===================================================
jamesob:
I don't particularly understand the aversion to infinite recursion, which seems
no different than the risk of potentially burning your coins. It's not like
infinite recursion on bitcoin is some kind of DoS vector or poses execution
overhead like an Ethereum VM bug might.
rgrant:
i think people who want recursion for cool stuff are worried that pedestrian
stuff will prevent it.
jeremyrubin:
i think people are afraid of weird shit happening, less so of recursion in
particular
hsjoberg:
"Recursive covenants" is the boogie man
shesek:
"recursion" translates to "complex black magic" for nondevs' -- recursion is
the new turing completeness
===================================================
Responding to FUD
===================================================
- It could be a good idea to include showing a way to do blacklists in the bug
bounty offer
- The potential concerns about recursive covenants have to clearly explained so
they can be properly examined.
- An article about CTV myths similar to segwit: :
https://blog.blockstream.com/en-segwit-myths-debunked/
- Some users think CTV might delay eltoo
TL;DR
"The initial resistance came from the Speedy Trial proposal. Then later on
rumors and FUD started spreading around regarding CTV and covenants."
- hsjoberg
https://gnusha.org/ctv-bip-review/2022-05-03.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
