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-hash That 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 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPfvXfKEgA0RCvxR%3DmP70sfvpzTphTZGidy%3DJuSK8f1WnM9xYA%40mail.gmail.com.