Just noting that the "what is the ultimatum" section is still a standing question, though I appreciate Andrew's e-mails and am taking that as a partial answer that he at least wants everyone to take a serious look at the proposal.
> 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 I presumed they were being bundled together because of complementary capabilities to convince people over the previously failed CTV-only activation attempts. I don't want to do crowd estimation but it seems clear to me there is higher excitement for this one. > In the meantime, CTV not committing to the annex does not make it any less useful or any more of a future liability. It clearly can be a liability if the relative utility of CTV is damaged by a possible future change, even non-consensus ones, some of which are already being deployed with non-zero miner support such as https://x.com/PortlandHODL/status/1921350395424563572 . This could have led to legitimate usage of CTV being trivially DoS'able. Good news is there are practical if not beautiful mitigations to this that don't involve annex commitment. See https://github.com/bitcoin/bitcoin/pull/32453 and https://github.com/petertodd/bitcoin/pull/10 for some relevant details. > 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. I offered the "P2CTV" template for exactly this purpose, please consult the patch I wrote. There's no need to introduce more script execution to support it. > 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. > 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 The Delving thread is declaring that it's a game-changer for BitVM, to some knowledgeable people it's obviously considered a feature. If I understand correctly it literally changed Robin Linus' opinion on the proposal for CTV! From my discussions with other BitVM implementers it certainly sounds practical? Forgive me for not taking your word for it. We shouldn't offer extremely sharp edges if there will be market demand for it, we should properly address the issue one way or another. > 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]. Incentivizing frankly insane usage is a danger to a proposal. To be surprised by a now sought after use-case that abuses legacy script's deformities, nearly 5 years after the spec hasn't changed, and to ask a question on a thread about a proposal? That's tabloid thinking? Let's be serious. > 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. Granted, TXHASH may even introduce even *weirder* edge cases (though it would have mitigated this specific one), but a middle-ground could be offering exactly what is being desired: A way to commit to a neighbor prevout in some way. If that's the capability we want, we should design for it. If it's not, we should mitigate it by disallowing it. > Fractalized delays on things that haven't really changed in years. > 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. This letter is asking for feedback from the technical community and this is my feedback. Undeployed BIPs that have not received any updates in years is generally not a sign of proposal health, and certainly not a foundation to reject technical advice from someone who's paid close attention. I reject this framing, the raising of the bar of changes to this proposal to only egregious breaks, and I obviously reject a time based ultimatum for BIP119 as-is. I still think CTV(again in the capability sense) + CSFS are worthy of consideration, but this is a surefire way to sink it. Greg On Wed, Jun 11, 2025 at 10:12 AM James O'Beirne <[email protected]> wrote: > 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAB3F3Dsf8%3DrbOyPf1yTQDzyQQX6FAoJWTg16VC8PVs4_uBkeTw%40mail.gmail.com.
