Greg,
Thanks for your thoughtful reply. I appreciate how thoroughly you've
considered this stuff, and while I have objections to certain
characterizations you make in the post, it is in general a strong
contribution to the discussion.
Replies inline:
> I think there is general agreement that CTV alone was insufficiently
> exciting to enough of the technical community to be deployed on its
> own.
I don't think that's an accurate read; there is a fairly large
contingent of technical people who would have happily deployed CTV on
its own. We never got an explicit count of how large that group is, but
I can say anecdotally that many signers of this letter would likely hold
that view.
The CTV-on-its-own applications (vaults -- both as "ingredient" and
"full solution," DLC improvements, trustless mining payouts, ...) are
compelling enough to many. And over time it's become obvious that having
a consensus primitive that allows commitment to spend by a predetermined
sequence of transactions is a necessary component of the complete
realization of many layer twos. BIP-119 is just the simplest formation
of this.
> Why not TXHASH+CSFS? If the cost is a year of concentrated development
> to do something better, we should just do it.
I think the unit of a "year of engineering time" rarely makes sense,
especially in an open source bitcoin context, and especially when we're
talking about bitcoin consensus changes.
We don't know what kind of delays a "year of concentrated development"
will induce, or what kind of environment the ecosystem will find itself
in when the change is finally "ready."
The appealing part of CTV+CSFS is that the changes are already baked,
and have been unchanged for years. Even with your concerns about legacy
scriptSig usage, the reality is that if we merged the changes as
proposed, they would work well and safely for anything resembling an
advertised use.
> With TXHASH+CSFS we can let app developers decide what they find
> important, versus the opinionated CTV default, whatever that is.
The "opinionated CTV default" is simply the most basic way to generate a
commitment to a future sequence of transactions without malleability.
"Whatever it is" is clearly defined in the BIP and implementation.
> Why not commit to annex? I had considered future annex relay as
> problematic for rolling out BIP119 due to its lack of commitment to
> the annex field.
For those who don't recall, BIP-341 (which introduced the annex) writes:
> Until the meaning of this field is defined by another softfork, users
> SHOULD NOT include annex in transactions, or it may lead to PERMANENT
> FUND LOSS.
As you point out, right now BIP-119 does not commit to the annex. If the
annex is ever given meaning via consensus change, and if for some
reason, some use needs a commitment to its contents in CTV, we can
upgrade CTV in any number of different ways (longer CTV arg, new opcode,
...) to accomodate this when we have a specific use.
In the meantime, CTV not committing to the annex does not make it any
less useful or any more of a future liability.
But another, maybe better, reason not to commit to the annex within the
CTV hash is that it would then constrain the possible purpose of the
annex itself to information that can be known ahead of spend time.
The annex should first figure out its use -- timeline indeterminate on
that one -- before CTV does. Once that happens, this can be handled
easily with the various upgrade hooks that script now has.
> [Legacy CTV use] considerably increases review surface for no known
> capability gain and no known savings for protocols.
I think this is a pretty hefty mischaracterization taken for granted.
While it "increases review surface" in that we have to consider the
legacy case, I think it's much less a task than you're making it out to
be.
Supposed review burden aside, there _are_ known savings for protocols;
vaults may ultimately want to send directly to bare CTV scripts, saving
8vB (= 32WU) for each output.
Congestion control trees, which have various known and possible uses in
L2s, trustless mining payouts[0], and potential future uses like batched
exchange withdrawals, save a multiple of 8vB that grows _exponentially_
at each level of the tree[1].
[0]:
https://delvingbitcoin.org/t/scaling-noncustodial-mining-payouts-with-ctv[1]:
https://utxos.org/uses/scaling/We get the option of all those future savings for free simply by not
touching the existing (reviewed) proposal, which has been in its current
form for years. You personally may not be convinced that bare congestion
control will ever be used, but some disagree, and even more at least
believe we should allow for the possibility when the marginal cost is so
little.
> BIP119 committing to other prevouts very indirectly is a surprising
> anti-feature [...]
> This feature is proported to make specific BitVM constructions trustless
This isn't a claimed "feature" of BIP-119 - it's a non-obvious,
off-label use that was pretty quickly found to have problems.
CTV commits to scriptSigs (if they exist) in order to avoid txid
malleability when used with other legacy inputs (as it says in
BIP-119[2]). This is the only claimed purpose of the commitment.
[2]:
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-scriptsigs-hashThat the proposed BitVM use described in the Delving thread is broken is
sort of like saying we shouldn't have SIGHASH_SINGLE because trying to
slam together input/output pairs with SIGHASH_SINGLE|ANYONECANPAY for a
coinjoin scheme inadvertently introduces pinning vectors.
> BIP119 activated alone seemingly incentivizes very non-standard
> scriptSigs on legacy scripting, rather than directly offering the
> functionality desired
This is not an advertised use-case (or even one that works), so I'm not
sure how BIP-119 is incentivizing anything other than the many
advertised uses that it's been aimed at.
To my knowledge there isn't a proposal that actually satisfies this
particular use without stepping up the implementation complexity by an
order of magnitude, as in the case of TXHASH. See again: upgrade hooks
when we finalize use-case.
> What other surprising capabilities lurk in BIP119 that would
> incentivize deranged usage like this? Maybe nothing?
This reads like a tabloid headline; you could make similar arguments
about any possible proposal on the table, except none of the other ones
have been scrutinized for as long as BIP-119 has, and none of the other
ones have sat with a 5.3 BTC bounty on them for a few years[3].
I'm not saying you're claiming this, but to think that a more complex
proposal like TXHASH (or variant) is going to have fewer surprising
cases than something relatively constrained like CTV is not realistic.
[3]:
https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af> I'm hopeful on this front but 6 months to get things like this done in
> addition to everything else seems very short.
It is this kind of message and thinking that's brought us to this point.
Fractalized delays on things that haven't really changed in years.
The amount you've written in this post and the concerns you've raised
might make the reader think there are a number of fundamental, scary
uncertainties with BIP-119 - but in actuality, they're minor points that
have been addressed in the past elsewhere, although admittedly not in a
single place.
The reality is that these changes could be merged as-is and there would
be no negative externalities to bitcoin. Quite the opposite.
I'm certainly not opposed to making changes where merited. But any
changes made are going to set back the clock on deployment and
activation as they need to be propagated through the various layers of
technical review. We should only do this for real, good reasons.
Warm regards,
James