On Thu, Jan 27, 2022 at 07:18:54PM -0500, James O'Beirne via bitcoin-dev wrote: > > I don't think implementing a CTV opcode that we expect to largely be > > obsoleted by a TXHASH at a later date is yielding good value from a soft > > fork process. > Caching for something > like TXHASH looks to me like a whole different ballgame relative to CTV, > which has a single kind of hash.
I don't think caching is a particular problem even for the plethora of flags Russell described: you cache each value upon use, and reuse that cached item if it's needed for other signatures within the tx; sharing with BIP 143, 341 or 342 signatures as appropriate. Once everything's cached, each signature then only requires hashing about 32*17+4 = ~548 bytes, and you're only hashing each part of the transaction once in order to satisfy every possible flag. > Even if we were to adopt something like TXHASH, how long is it going to > take to develop, test, and release? I think the work to release something like TXHASH is all in deciding: - if TXHASH or CTV or something else is the better "UX" - what is a good tx to message algorithm and how it should be parametized - what's an appropriate upgrade path for the TXHASH/CTV/??? mechanism BIP 119 provides one answer to each of those, but you still have to do the work to decide if its a *good* answer to each of them. > My guess is "a while" - If we want to get a good answer to those questions, it might be true that it takes a while; but even if we want to rush ahead with more of a "well, we're pretty sure it's not going to be a disaster" attitude, we can do that with TXHASH (almost) as easily as with CTV. > The utility of vaulting seems > underappreciated among consensus devs and it's something I'd like to write > about soon in a separate post. I think most of the opposition is just that support for CTV seems to be taking the form "something must be done; this is something, therefore it must be done"... I'd be more comfortable if the support looked more like "here are the alternatives to CTV, and here's the advantages and drawbacks for each, here's how they interact with other ideas, and here's why we think, on balance, we think this approach is the best one". But mostly the alternatives are dismissed with "this will take too long" or "this enables recursive covenants which someone (we don't know who) might oppose". Cheers, aj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
