Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-28 📝 Original message:On Thu, Jan 27, 2022 at ...
📅 Original date posted:2022-01-28
📝 Original message:On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne <james.obeirne at gmail.com>
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.
>
> This presumes the eventual adoption of TXHASH (or something like it).
> You're presenting a novel idea that, as far as I know, hasn't had much time
> to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
> of flags and the implications that has for testing. Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
>
Let's not overstate the concern around the combinatorics of TXHASH. It's
not like there is a vast amount of cross-flag interaction we are talking
about here. There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test
every single possible Script program.
> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release? My guess is "a while" - in the
> meantime, users of Bitcoin are without a vault strategy that doesn't
> require either presigning transactions with ephemeral keys (operationally
> difficult) or multisig configurations that would make Rube Goldberg blush
> (operationally difficult and precarious). The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
>
> > The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its
> simplicity - it's relatively easy to reason about and, at this point,
> pretty well understood. It seems like a low-risk change relative to some of
> the other covenant proposals, nearly all of which elicit a good deal of
> headscratching (at least from me) and seem to require not only larger
> on-chain footprints but sizable code changes.
>
> > I am sensitive to technical debt and soft fork processes
>
> If OP_CTV ends up being the most practical approach for vaulting - among
> other things - in terms of weight (which it seems to be at the moment) I
> don't think "technical debt" is an applicable term.
>
Technical debt isn't a measure of weight of transactions. It's a measure
of the code complexity needed to implement, in this case, a Bitcoin Script
interpreter.
By itself, adding a single new hash format for CTV isn't that complex, and
it is certainly simpler than this TXHASH proposal. But then we need to add
another two slightly different hash formats for APO support. And tomorrow
we will need yet another set of transaction hash formats for the next
thing, and so on, with each instance requiring going through its own
soft-fork process. It is at that point we end up with something more
complicated and with more deployment risk than if we had just done
something like TXHASH at the very beginning. But unlike other programming
environments, we cannot refactor our way out of such a situation. We
cannot make a new script version while deprecating the old one. Our only
option here is to be mindful of the long term implications of the design
choices we are making today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/a793638a/attachment-0001.html>;
📝 Original message:On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne <james.obeirne at gmail.com>
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.
>
> This presumes the eventual adoption of TXHASH (or something like it).
> You're presenting a novel idea that, as far as I know, hasn't had much time
> to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
> of flags and the implications that has for testing. Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
>
Let's not overstate the concern around the combinatorics of TXHASH. It's
not like there is a vast amount of cross-flag interaction we are talking
about here. There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test
every single possible Script program.
> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release? My guess is "a while" - in the
> meantime, users of Bitcoin are without a vault strategy that doesn't
> require either presigning transactions with ephemeral keys (operationally
> difficult) or multisig configurations that would make Rube Goldberg blush
> (operationally difficult and precarious). The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
>
> > The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its
> simplicity - it's relatively easy to reason about and, at this point,
> pretty well understood. It seems like a low-risk change relative to some of
> the other covenant proposals, nearly all of which elicit a good deal of
> headscratching (at least from me) and seem to require not only larger
> on-chain footprints but sizable code changes.
>
> > I am sensitive to technical debt and soft fork processes
>
> If OP_CTV ends up being the most practical approach for vaulting - among
> other things - in terms of weight (which it seems to be at the moment) I
> don't think "technical debt" is an applicable term.
>
Technical debt isn't a measure of weight of transactions. It's a measure
of the code complexity needed to implement, in this case, a Bitcoin Script
interpreter.
By itself, adding a single new hash format for CTV isn't that complex, and
it is certainly simpler than this TXHASH proposal. But then we need to add
another two slightly different hash formats for APO support. And tomorrow
we will need yet another set of transaction hash formats for the next
thing, and so on, with each instance requiring going through its own
soft-fork process. It is at that point we end up with something more
complicated and with more deployment risk than if we had just done
something like TXHASH at the very beginning. But unlike other programming
environments, we cannot refactor our way out of such a situation. We
cannot make a new script version while deprecating the old one. Our only
option here is to be mindful of the long term implications of the design
choices we are making today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/a793638a/attachment-0001.html>;