Date: Mon, 31 Jan 2022 12:18:52 +1000
From: Anthony Towns <aj@erisian.com.au>
To: James O'Beirne <james.obeirne@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220131021852.GA4149@erisian.com.au>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
 <CAMZUoKmU1cwUAQaBv5m8oo8H3TWBvgsZ_OkQaMC0n0+3cpFtWg@mail.gmail.com>
 <CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPfvXfLr4n6RsS6VbEZR59=MRwAx41Crx88ko8-qnRXW4nFYGA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV
 and ANYPREVOUT
Precedence: list

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