path: root/d8/64d0d7154b5d5be1be78d35ebcea9296c785d4

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 <bitcoindev+bncBCV5B3G674FRBX46U3BAMGQE73PJRSQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <aEdoIvOgNNtT6L4s@mail.wpsoftware.net> <CAKaEYh+tLtzaqAcN26RLw3AeNhF6VYvMdKrQY6dfCdhYg2Ad3w@mail.gmail.com>
 <b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com>
In-Reply-To: <b17d0544-d292-4b4d-98c6-fa8dc4ef573cn@googlegroups.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Wed, 11 Jun 2025 10:12:21 -0400
X-Gm-Features: AX0GCFsD4PQS3g39gagpdd_tadoxmJIhcuJ4k4HLfqUvQrnbchLZQRd0OsUh3to
Message-ID: <CAPfvXfKEgA0RCvxR=mP70sfvpzTphTZGidy=JuSK8f1WnM9xYA@mail.gmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: Greg Sanders <gsanders87@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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

<div dir=3D"ltr"><div dir=3D"ltr">Greg,<br><br>Thanks for your thoughtful r=
eply. I appreciate how thoroughly you&#39;ve<br>considered this stuff, and =
while I have objections to certain<br>characterizations you make in the pos=
t, it is in general a strong<br>contribution to the discussion.<br><br>Repl=
ies inline:<br><br>&gt; I think there is general agreement that CTV alone w=
as insufficiently<br>&gt; exciting to enough of the technical community to =
be deployed on its<br>&gt; own.<br><br>I don&#39;t think that&#39;s an accu=
rate read; there is a fairly large<br>contingent of technical people who wo=
uld have happily deployed CTV on<br>its own. We never got an explicit count=
 of how large that group is, but<br>I can say anecdotally that many signers=
 of this letter would likely hold<br>that view.<br><br>The CTV-on-its-own a=
pplications (vaults -- both as &quot;ingredient&quot; and<br>&quot;full sol=
ution,&quot; DLC improvements, trustless mining payouts, ...) are<br>compel=
ling enough to many. And over time it&#39;s become obvious that having<br>a=
 consensus primitive that allows commitment to spend by a predetermined<br>=
sequence of transactions is a necessary component of the complete<br>realiz=
ation of many layer twos. BIP-119 is just the simplest formation<br>of this=
.<br><br><br>&gt; Why not TXHASH+CSFS? If the cost is a year of concentrate=
d development<br>&gt; to do something better, we should just do it.<br><br>=
I think the unit of a &quot;year of engineering time&quot; rarely makes sen=
se,<br>especially in an open source bitcoin context, and especially when we=
&#39;re<br>talking about bitcoin consensus changes. <br><br>We don&#39;t kn=
ow what kind of delays a &quot;year of concentrated development&quot;<br>wi=
ll induce, or what kind of environment the ecosystem will find itself<br>in=
 when the change is finally &quot;ready.&quot;<br><br>The appealing part of=
 CTV+CSFS is that the changes are already baked,<br>and have been unchanged=
 for years. Even with your concerns about legacy<br>scriptSig usage, the re=
ality is that if we merged the changes as<br>proposed, they would work well=
 and safely for anything resembling an<br>advertised use.<br><br><br>&gt; W=
ith TXHASH+CSFS we can let app developers decide what they find<br>&gt; imp=
ortant, versus the opinionated CTV default, whatever that is.<br><br>The &q=
uot;opinionated CTV default&quot; is simply the most basic way to generate =
a<br>commitment to a future sequence of transactions without malleability.<=
br>&quot;Whatever it is&quot; is clearly defined in the BIP and implementat=
ion.<br><br><br>&gt; Why not commit to annex? I had considered future annex=
 relay as<br>&gt; problematic for rolling out BIP119 due to its lack of com=
mitment to<br>&gt; the annex field.<br><br>For those who don&#39;t recall, =
BIP-341 (which introduced the annex) writes:<br><br>&gt; Until the meaning =
of this field is defined by another softfork, users<br>&gt; SHOULD NOT incl=
ude annex in transactions, or it may lead to PERMANENT<br>&gt; FUND LOSS.<b=
r><br>As you point out, right now BIP-119 does not commit to the annex. If =
the<br>annex is ever given meaning via consensus change, and if for some<br=
>reason, some use needs a commitment to its contents in CTV, we can<br>upgr=
ade CTV in any number of different ways (longer CTV arg, new opcode,<br>...=
) to accomodate this when we have a specific use. <br><br>In the meantime, =
CTV not committing to the annex does not make it any<br>less useful or any =
more of a future liability.<br><br>But another, maybe better, reason not to=
 commit to the annex within the<br>CTV hash is that it would then constrain=
 the possible purpose of the<br>annex itself to information that can be kno=
wn ahead of spend time.<br><br>The annex should first figure out its use --=
 timeline indeterminate on<br>that one -- before CTV does. Once that happen=
s, this can be handled<br>easily with the various upgrade hooks that script=
 now has.<br><br><br>&gt; [Legacy CTV use] considerably increases review su=
rface for no known<br>&gt; capability gain and no known savings for protoco=
ls.<br><br>I think this is a pretty hefty mischaracterization taken for gra=
nted.<br>While it &quot;increases review surface&quot; in that we have to c=
onsider the<br>legacy case, I think it&#39;s much less a task than you&#39;=
re making it out to<br>be.<br><br>Supposed review burden aside, there _are_=
 known savings for protocols;<br>vaults may ultimately want to send directl=
y to bare CTV scripts, saving<br>8vB (=3D 32WU) for each output.<br><br>Con=
gestion control trees, which have various known and possible uses in<br>L2s=
, trustless mining payouts[0], and potential future uses like batched<br>ex=
change withdrawals, save a multiple of 8vB that grows _exponentially_<br>at=
 each level of the tree[1].<br><br>[0]: <a href=3D"https://delvingbitcoin.o=
rg/t/scaling-noncustodial-mining-payouts-with-ctv">https://delvingbitcoin.o=
rg/t/scaling-noncustodial-mining-payouts-with-ctv</a><br>[1]: <a href=3D"ht=
tps://utxos.org/uses/scaling/">https://utxos.org/uses/scaling/</a><br><br>W=
e get the option of all those future savings for free simply by not<br>touc=
hing the existing (reviewed) proposal, which has been in its current<br>for=
m for years. You personally may not be convinced that bare congestion<br>co=
ntrol will ever be used, but some disagree, and even more at least<br>belie=
ve we should allow for the possibility when the marginal cost is so<br>litt=
le.<br><br><br>&gt; BIP119 committing to other prevouts very indirectly is =
a surprising<br>&gt; anti-feature [...]<br>&gt; This feature is proported t=
o make specific BitVM constructions trustless<br><br>This isn&#39;t a claim=
ed &quot;feature&quot; of BIP-119 - it&#39;s a non-obvious,<br>off-label us=
e that was pretty quickly found to have problems. <br><br>CTV commits to sc=
riptSigs (if they exist) in order to avoid txid<br>malleability when used w=
ith other legacy inputs (as it says in<br>BIP-119[2]). This is the only cla=
imed purpose of the commitment.<br><br>[2]: <a href=3D"https://github.com/b=
itcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-scriptsigs-has=
h">https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committin=
g-to-the-scriptsigs-hash</a><br><br>That the proposed BitVM use described i=
n the Delving thread is broken is<br>sort of like saying we shouldn&#39;t h=
ave SIGHASH_SINGLE because trying to<br>slam together input/output pairs wi=
th SIGHASH_SINGLE|ANYONECANPAY for a<br>coinjoin scheme inadvertently intro=
duces pinning vectors.<br><br><br>&gt; BIP119 activated alone seemingly inc=
entivizes very non-standard<br>&gt; scriptSigs on legacy scripting, rather =
than directly offering the<br>&gt; functionality desired<br><br>This is not=
 an advertised use-case (or even one that works), so I&#39;m not<br>sure ho=
w BIP-119 is incentivizing anything other than the many<br>advertised uses =
that it&#39;s been aimed at.<br><br>To my knowledge there isn&#39;t a propo=
sal that actually satisfies this<br>particular use without stepping up the =
implementation complexity by an<br>order of magnitude, as in the case of TX=
HASH. See again: upgrade hooks<br>when we finalize use-case.<br><br><br>&gt=
; What other surprising capabilities lurk in BIP119 that would<br>&gt; ince=
ntivize deranged usage like this? Maybe nothing?<br><br>This reads like a t=
abloid headline; you could make similar arguments<br>about any possible pro=
posal on the table, except none of the other ones<br>have been scrutinized =
for as long as BIP-119 has, and none of the other<br>ones have sat with a 5=
.3 BTC bounty on them for a few years[3].<br><br>I&#39;m not saying you&#39=
;re claiming this, but to think that a more complex<br>proposal like TXHASH=
 (or variant) is going to have fewer surprising<br>cases than something rel=
atively constrained like CTV is not realistic.<br><br>[3]: <a href=3D"https=
://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af">https://bip=
bounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af</a><br><br><br>&gt=
; I&#39;m hopeful on this front but 6 months to get things like this done i=
n<br>&gt; addition to everything else seems very short.<br><br>It is this k=
ind of message and thinking that&#39;s brought us to this point.<br>Fractal=
ized delays on things that haven&#39;t really changed in years.<br><br>The =
amount you&#39;ve written in this post and the concerns you&#39;ve raised<b=
r>might make the reader think there are a number of fundamental, scary<br>u=
ncertainties with BIP-119 - but in actuality, they&#39;re minor points that=
<br>have been addressed in the past elsewhere, although admittedly not in a=
<br>single place.<br><br>The reality is that these changes could be merged =
as-is and there would<br>be no negative externalities to bitcoin. Quite the=
 opposite.<br><br>I&#39;m certainly not opposed to making changes where mer=
ited. But any<br>changes made are going to set back the clock on deployment=
 and<br>activation as they need to be propagated through the various layers=
 of<br>technical review. We should only do this for real, good reasons.<br>=
<br><br>Warm regards,<br>James</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAPfvXfKEgA0RCvxR%3DmP70sfvpzTphTZGidy%3DJuSK8f1WnM9xYA%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAPfvXfKEgA0RCvxR%3DmP70sfvpzTphTZGidy%3DJuSK8f1WnM9xYA%=
40mail.gmail.com</a>.<br />

--0000000000006d814006374c6723--