From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 11 Jun 2025 07:15:07 -0700 Received: from mail-qv1-f58.google.com ([209.85.219.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uPMEM-0007ZI-8P for bitcoindev@gnusha.org; Wed, 11 Jun 2025 07:15:07 -0700 Received: by mail-qv1-f58.google.com with SMTP id 6a1803df08f44-6fb2494ef24sf58019576d6.2 for ; Wed, 11 Jun 2025 07:15:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749651300; cv=pass; d=google.com; s=arc-20240605; b=EB1edBES7u7sIsvxjgyUAdmfbizd36BBoXjbSZaF7cXb/iWvF+DX9cND27NVaY3bna Y0XwsEdh/SjotrU/hZftEUhfmH3JIpQnoGqzEbpPf9pSEw/lBB++NrSsyU0WVyU0c6xe 2yAkXEeIOX240OkQuVAFHwO1Lv4d5FItIdbMLs/T/7ueoLxi6hIffHdxobGDIEtdjJCX OUPbzsobuhFsq43jx1xCl1EZOSZltrSxGJiwy14sPt7HWisFqdnSy04Nob9nDJYwb3fJ rZoelnn6aOqlmK2mywA8Yuhlchk/oi67Ivon5HD1bFYEtgp1H1aJJo/p/BoDp6tqgwUf bf3g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=8yMQu9TpW5fb+5zQUQKFbuSBPRHQr+7auVcZBsAv3e4=; fh=QN2Ko/RZh2AC7Wb7QbjzyXRBaGjHVhLn+B9+vRklqjY=; b=DmnQMZVN9XynjXEYuXOU4vLaBJ9Xq2vJDLTKi18rHasYKMpwjaNGq/+HJOfvj8wYbx S53TAVZL5i4uITTUfbM1J1jZKMkjAgX7nFftlxU6Y8GEN182YeSLVmS3ObqEkcpkX5v1 sVEA6jIwNj7M9bdWijzUEbHzh8EpNYuEVaRkQc0kLr2ebin9W9YKl9Lh5Fz3i+AmTDcm ek7e9da9JDkavVjdA3ICBKSfM18MHO3szwjoP6R55mMF26rh2mSCzpGfBXPn7bkr+LIz nITTqNMjoiUk1KKp/dPtdUlQf8O050tn3zhCM1dZUoCl4JbRLqedSSZHLzxXUWkXqc1w hoag==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=WR810K0Y; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::102d as permitted sender) smtp.mailfrom=james.obeirne@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749651300; x=1750256100; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=8yMQu9TpW5fb+5zQUQKFbuSBPRHQr+7auVcZBsAv3e4=; b=GAV5RsMBXheUpU5CZCh8iEiNuQYliy0fn16108NPVLreEvo9N9lAWUY3CAX32RCcHU 8SUpZRZyVULswJNq3HRqgCqIN1TdiZrVHqRbiMiaB/l2O7J74spWkq1J0VMdSFXGwcjB arit6R9JGpDyURK2e5uK1EIkuzRrJaqaXVzlxWuMdn6tLSzUbjPD1iqJ2USoHNIVpoEY Myja2KlcFFN9vZMoyEb8aoDKbO/qScEW/I212/JHYjBBxg5I4sK//gpWoPMKIdbh56iK tmVEogGHxKNNtVXpbyzgqpH+eIgAJ0Cmq+QkcBHLT5XskLhkT9YydM0OAeOqFM8Des2S kksA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749651300; x=1750256100; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8yMQu9TpW5fb+5zQUQKFbuSBPRHQr+7auVcZBsAv3e4=; b=aiPat5RxW/ZIPoWCTkAXVPh8Nq00CGVxTSb2uPshUI2SJhcnqrhl6Z/A6TrWh8QGif FC6pAH8Q0lvnWYJkB8vKbnMmZoGKJq/SmcQ9tifjRbdFWTaa4HxetDACg+Rx52X+dXTj oE7jIzI9N5HCYPs/ypBL7wDOzppwAfpvZTx2JLf/0bTEphFfxIWbic85wZbfWoOsTEyq xrnQdUCaafYTZzQvMlPULr8dHPdNJgEtiSCCw6JGGQYnXH2oPGGwnwywzCPG3M2mo2FV dmHLBMNp7JgTdfXrCc1UcpTL8em+5rVh0UaUZH0Vh1dr8jC8st70ydzRLHKDwodV7SEO pk7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749651300; x=1750256100; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=8yMQu9TpW5fb+5zQUQKFbuSBPRHQr+7auVcZBsAv3e4=; b=KvPR0DolULR3kBuuLAdNyy5dH3Q9H7/nyI+nGRExy8yl9XTvhZ5xGrd3IUhGxEHpTB Jl6z1J1dFOXyZCmAj1ZXx0kdOmXdDNtoIz27v9sMN5VqjRbJ5kvWys/gumxxBQcA7pAy HHyNNU3dafpiJdE2V9TZI3K5AXyFzuFbf7KBgeMQCmxIHbhdetr8wHgM0TKSz+HI32s1 KrLZMMQH7vYsPUrfl/MPTyebXB0gbBq1taSGAzLze+iSK3XwH5dxqiD8xb793M6qPJxh AoHgK6kF839VGiVMGgDZocnMveWCUf5gG8hxzaohnb/03RwOj6uZEoCRGQNsr/s0o3Ir i7hA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWfsEp22cqdrdvTFCYitdKqRguW1LRMNBBSG92TiwnPJia6Auw5eHhF7QUoIY/l0DDP02Gz/9GAlMIU@gnusha.org X-Gm-Message-State: AOJu0Yy2n0pdIG5TK8uEPLRVMfv3XwpUwKGqoDTYd6pB1yrr7Xr1XZsJ RS5NolXU4GuIWYQLaon/Lf1bUFmp83G2GPy6N0iwLHrWhoj8r/g64Btl X-Google-Smtp-Source: AGHT+IE0UtWyziq2EJh6Kr+L9foP318EzFvyz1Rw8/BedHBtseL04r7UJOwcmu7zvpKryhIsW8/RJg== X-Received: by 2002:a05:6214:2347:b0:6fa:ccff:352a with SMTP id 6a1803df08f44-6fb2d17d9dfmr47104866d6.37.1749651299598; Wed, 11 Jun 2025 07:14:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeA94rdbxPgkWDZ2OsA2exa1LIKXx+hdNm9i6l1TPhWtw== Received: by 2002:ad4:4ee5:0:b0:6fa:fa9c:42ad with SMTP id 6a1803df08f44-6faffe5b4e4ls126556236d6.0.-pod-prod-04-us; Wed, 11 Jun 2025 07:14:55 -0700 (PDT) X-Received: by 2002:a05:6214:2503:b0:6f2:d25e:8f60 with SMTP id 6a1803df08f44-6fb2d14f417mr39865966d6.22.1749651295428; Wed, 11 Jun 2025 07:14:55 -0700 (PDT) Received: by 2002:a05:620a:17aa:b0:7c5:495f:5415 with SMTP id af79cd13be357-7d3a8d97834ms85a; Wed, 11 Jun 2025 07:12:34 -0700 (PDT) X-Received: by 2002:ad4:5f0f:0:b0:6fb:17a:c428 with SMTP id 6a1803df08f44-6fb2d0f3944mr43644426d6.16.1749651153371; Wed, 11 Jun 2025 07:12:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749651153; cv=none; d=google.com; s=arc-20240605; b=MMfffo9gVRZzrEfgZcTF0GmsjEYKBkbCgoAKZOYeDegtJkl+EY2+CE6IB0N9sZIxb4 tiaLZvpX1toBtPvGt/VtI/v5B8bZ+XU1yv+0OO0GWz1BCbqUNgoNr41sINzwofCIupJL 6NCKqDCZ6ZmM1jwtb5YE36ME0rFP2sM7f5iwtoaHZZcA5NXUqaa/3BZIKpBnqyzSpBLT 63PrU6Fi7wj3roirYaXjOk8N+TD2idPIdaXT36z/VTl9uDeiuuH06cV8srA6eM1cj8Sl 1mmZ7VjXFmjHta+LP8enN3RNIpTRLxsTWbaoOtiOIbZrne4sOuTloYTk8MRVvXEEl0fk pswA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=a0KMcQ9lt4oxzEYytOTdgOd47vzgmkh2v3RkRuDeWf4=; fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=; b=GUIGTaCt2vouBGekgpyt6GDobP69Y1HMNpnnqA3tsz2UR5oOSGWbx0qmdLyM3XINKU 5iG+uKXFsPaFvk+eUpqAUfqJht+7I5vYDlzBHsTngfw5DnzEfV7lhYh4NBZkelODTAkz O0avSpybFXE6d0mtnXuGOR9Ei6445Q5YPb2BVhJ2Sc7ixn069WnH4zsC1L48bJegDIto ravxgqLSsoDoRiM5qErPr+e+epvq9SSi32eRYTpVLvP3RXNtEUW5P0uQKLNXdz4TKC1b ZMzJJ5YxmJmghYKlfTxv4aQE0FJeiX+mbhUlqEftOlNZ4ONIIVVOJdg2tPMrYjK61XXh Nhnw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=WR810K0Y; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::102d as permitted sender) smtp.mailfrom=james.obeirne@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com. [2607:f8b0:4864:20::102d]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-6fb09abc088si5509236d6.1.2025.06.11.07.12.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Jun 2025 07:12:33 -0700 (PDT) Received-SPF: pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::102d as permitted sender) client-ip=2607:f8b0:4864:20::102d; Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-3122368d7cfso5229241a91.1 for ; Wed, 11 Jun 2025 07:12:33 -0700 (PDT) X-Gm-Gg: ASbGnctp2lhNM5rCbt1wZPKaqT+sPNkOjgLchPWAn9lychI1c6D36fPZMS4+607ITuR V8IuUvXut7x0X1KqgaEGylQ74H70YkpsKNBxFqpGTZQNqLU5D3ykF2SKqGxpVhEyK8dh+vXcqPB isvEPXohBVVOQEjgZl2HaFv4yLZFN03EUW3nKYmIc6fQ== X-Received: by 2002:a17:90b:384a:b0:312:e49b:c972 with SMTP id 98e67ed59e1d1-313b1f39483mr3855824a91.15.1749651152533; Wed, 11 Jun 2025 07:12:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Wed, 11 Jun 2025 10:12:21 -0400 X-Gm-Features: AX0GCFsD4PQS3g39gagpdd_tadoxmJIhcuJ4k4HLfqUvQrnbchLZQRd0OsUh3to Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Greg Sanders Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006d814006374c6723" X-Original-Sender: james.obeirne@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=WR810K0Y; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::102d as permitted sender) smtp.mailfrom=james.obeirne@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000006d814006374c6723 Content-Type: text/plain; charset="UTF-8" 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. --0000000000006d814006374c6723 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,

Thanks for your thoughtful r= eply. I appreciate how thoroughly you've
considered this stuff, and = while I have objections to certain
characterizations you make in the pos= t, it is in general a strong
contribution to the discussion.

Repl= ies inline:

> I think there is general agreement that CTV alone w= as insufficiently
> exciting to enough of the technical community to = be deployed on its
> own.

I don't think that's an accu= rate read; there is a fairly large
contingent of technical people who wo= uld 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 a= pplications (vaults -- both as "ingredient" and
"full sol= ution," DLC improvements, trustless mining payouts, ...) are
compel= ling 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
realiz= ation of many layer twos. BIP-119 is just the simplest formation
of this= .


> Why not TXHASH+CSFS? If the cost is a year of concentrate= d development
> to do something better, we should just do it.

= I think the unit of a "year of engineering time" rarely makes sen= se,
especially in an open source bitcoin context, and especially when we= 're
talking about bitcoin consensus changes.

We don't kn= ow what kind of delays a "year of concentrated development"
wi= ll 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 re= ality is that if we merged the changes as
proposed, they would work well= and safely for anything resembling an
advertised use.


> W= ith TXHASH+CSFS we can let app developers decide what they find
> imp= ortant, versus the opinionated CTV default, whatever that is.

The &q= uot;opinionated CTV default" is simply the most basic way to generate = a
commitment to a future sequence of transactions without malleability.<= br>"Whatever it is" is clearly defined in the BIP and implementat= ion.


> Why not commit to annex? I had considered future annex= relay as
> problematic for rolling out BIP119 due to its lack of com= mitment 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 incl= ude 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 somereason, some use needs a commitment to its contents in CTV, we can
upgr= ade 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 kno= wn ahead of spend time.

The annex should first figure out its use --= timeline indeterminate on
that one -- before CTV does. Once that happen= s, this can be handled
easily with the various upgrade hooks that script= now has.


> [Legacy CTV use] considerably increases review su= rface for no known
> capability gain and no known savings for protoco= ls.

I think this is a pretty hefty mischaracterization taken for gra= nted.
While it "increases review surface" in that we have to c= onsider 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 directl= y to bare CTV scripts, saving
8vB (=3D 32WU) for each output.

Con= gestion control trees, which have various known and possible uses in
L2s= , trustless mining payouts[0], and potential future uses like batched
ex= change withdrawals, save a multiple of 8vB that grows _exponentially_
at= each level of the tree[1].

[0]: https://delvingbitcoin.o= rg/t/scaling-noncustodial-mining-payouts-with-ctv
[1]: https://utxos.org/uses/scaling/

W= e get the option of all those future savings for free simply by not
touc= hing the existing (reviewed) proposal, which has been in its current
for= m for years. You personally may not be convinced that bare congestion
co= ntrol will ever be used, but some disagree, and even more at least
belie= ve we should allow for the possibility when the marginal cost is so
litt= le.


> BIP119 committing to other prevouts very indirectly is = a surprising
> anti-feature [...]
> This feature is proported t= o make specific BitVM constructions trustless

This isn't a claim= ed "feature" of BIP-119 - it's a non-obvious,
off-label us= e that was pretty quickly found to have problems.

CTV commits to sc= riptSigs (if they exist) in order to avoid txid
malleability when used w= ith other legacy inputs (as it says in
BIP-119[2]). This is the only cla= imed purpose of the commitment.

[2]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committin= g-to-the-scriptsigs-hash

That the proposed BitVM use described i= n the Delving thread is broken is
sort of like saying we shouldn't h= ave SIGHASH_SINGLE because trying to
slam together input/output pairs wi= th SIGHASH_SINGLE|ANYONECANPAY for a
coinjoin scheme inadvertently intro= duces pinning vectors.


> BIP119 activated alone seemingly inc= entivizes 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 ho= w BIP-119 is incentivizing anything other than the many
advertised uses = that it's been aimed at.

To my knowledge there isn't a propo= sal that actually satisfies this
particular use without stepping up the = implementation complexity by an
order of magnitude, as in the case of TX= HASH. See again: upgrade hooks
when we finalize use-case.


>= ; What other surprising capabilities lurk in BIP119 that would
> ince= ntivize deranged usage like this? Maybe nothing?

This reads like a t= abloid headline; you could make similar arguments
about any possible pro= posal 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 rel= atively constrained like CTV is not realistic.

[3]: https://bip= bounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af


>= ; I'm hopeful on this front but 6 months to get things like this done i= n
> addition to everything else seems very short.

It is this k= ind of message and thinking that's brought us to this point.
Fractal= ized delays on things that haven't really changed in years.

The = amount you've written in this post and the concerns you've raisedmight make the reader think there are a number of fundamental, scary
u= ncertainties 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 mer= ited. 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAPfvXfKEgA0RCvxR%3DmP70sfvpzTphTZGidy%3DJuSK8f1WnM9xYA%= 40mail.gmail.com.
--0000000000006d814006374c6723--