JeremyRubin
Discuss CTV+CSFS followed by CAT+Math+EcMath
I like the spirit behind this sequence, but still think we should be cautious about adding CAT without ergonomic granular introspection. As I was discussing on X with the bcashers the other day, if you enable CAT but not more ergonomic ways to access its capabilities, you risk contracts being created that less precisely or less completely express the intended outcomes of the participants. Those contracts end up being much more subject to MEV and if many of them are developed in rapid succession after a fork to add CAT or similar to bitcoin then we may run into a block template centralization pressure.
Perhaps this option should be either CTV+CSFS followed by PAIRCOMMIT+Math+EcMath OR CTV+CSFS followed by CAT+introspection+Math+EcMath?
Thanks for initiating this discussion. CTV + CSFS seems to have good enough developers support and common denominator in many combinations. All the objections have been addressed.
I think eventually you will see a group of "influential developers" asking for use cases. Hopefully, it's already been answered with resources like:
https://utxos.org/uses/ https://en.bitcoin.it/wiki/Covenants_Uses https://covenants.info/use-cases/
An issue with EcMath is that the amount of code that needs to be introduced to bitcoind can be enormous.
This was one of the reasons why Ethereum didn't do EIP-2537 or EIP-1962. The foundation's engineers basically "refused" to maintain that codebase, even though EIP-1962 (and/or) 2537 were voted to be included in Ethereum network upgrades.
An issue with EcMath is that the amount of code that needs to be introduced to bitcoind can be enormous.
This was one of the reasons why Ethereum didn't do EIP-2537 or EIP-1962. The foundation's engineers basically "refused" to maintain that codebase, even though EIP-1962 (and/or) 2537 were voted to be included in Ethereum network upgrades.
The code for EcMath is already in Bitcoin? In libsecp256k1 library? wdym otherwise?
secp256k1 curve is not very useful for the curves we used in SNARK.
(Is that the intention of EcMath?)
No, the intent for EcMath is to be able to compute taproot key tweaks and other key derivation stuff... not sure that we'd want to support arbitrary curves? cc @apoelstra -- also curious about the libsecq stuff
We don't have anything production-ready that uses libsecq, and its use (AFAIK) is pretty limited for fast SNARKs. Although I am several years out of touch on the state of BP-like ZKPs. Back when I was looking at it closely, it was just a weird curiosity that you could technically do recursive BPs with this, at the expense of 3xing your verification time every time you recursed. Probably this is no longer the case.
hey Jeremy,
not sure if anyone else has offered to create activation client for CTV/CSFS yet, if not I would be happy to take this on.
you can find my fork here: https://github.com/monlovesmango/bitcoin/tree/checkops
there is still some refactoring that I would like to do. for now I am thinking of naming it 'checkops', but open to changing that. was also considering 'ctv+', 'check++', 'doublecheck'. you have any ideas? or maybe just go with CTV+CSFS? how important is naming?
as far as activation goes, I wouldn't feel comfortable releasing anything with less than a 6mo activation window. my ideal would 9mo tbh. and I wouldn't feel comfortable starting the activation period before June/July. this is mostly because I may need a certain amount of hand-holding and want to make sure I have enough time to do a quality job. it would also be nice to have time to stand up some demos prior to activation window starting.
as a disclaimer I:
- don't have any experience working with bitcoin core, however since all the code seems to be written already I feel comfortable that I can take it on and its a great way for me to learn :)
- don't have any plans on taking this activation path further than CTV/CSFS at this time
- don't commit to doing anything much on the marketing/PM side
however, I would be more than happy to host IRC sessions, create some POC implementations, and other technical support type work. right now I am working on a vault demo where you can switch between CAT and CTV covenants. would also be cool to get an lnsymmetry demo though I have no idea how much work that entails at this moment.
I am sorry I missed your deadline, took me longer than I expected to get my fork prepared. I am just doing this because I agree with you that CTV/CSFS is an easy win and should be our next soft fork but haven't seen anyone step forward to implement this soft fork. ideally someone more qualified than me would be doing this but if there really is no one else then I'll do it because I feel strongly that this should be an option for the next soft fork.
let me know how you feel about this and whether you think its worthwhile for me to continue.
