From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 11 Jun 2025 10:07:08 -0700 Received: from mail-oi1-f189.google.com ([209.85.167.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uPOup-0008QI-5n for bitcoindev@gnusha.org; Wed, 11 Jun 2025 10:07:08 -0700 Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-408e13258f5sf40644b6e.0 for ; Wed, 11 Jun 2025 10:07:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749661621; cv=pass; d=google.com; s=arc-20240605; b=FkL5g/P1Ra2eJoVNLAHT0g+uwMnk7pP+ZRNXQ1RrbcXiCRy0ubUrsI9XeLo0Rj3Vdf jV2/PkYW2AWquysCatTEtxhp/8CORIdkm7xK+tzzGuZJ7Q1RrN1I6ASAWcJ7NugOt010 VrXjsHceHb0bjltoi03+xpzOLuVfBOkNkeMUAkWCBT4RYkTWn97PMcTRnAhBHfmtkm5O 0ButK75PPBkg3WuImjC8Z7i6MpgcUcVK9CLGwfwlTyqNBy5aCai/rYd0cu5XT67Oupmx 9khpIaiKWx3a5u2s/A0O5uBZvp7ikEYM67awgbUtNTyWsvAPPFMYWwGeY2D01zyHMCvW EMJw== 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=ozTgSDFHudGokd/ObS3Xm8MoXsMM7sWyALYkNscOGyg=; fh=c6co1KEeFtk3Dnu2JKOSzu0COPUPVGOfegJK8OETjI4=; b=HUPyW/stJwy8Tn0wJJ+tnKwAg+zAdPrYULf5gpKB+W289UXnMJH1ISmVOLnBYBpqeR ONijiAGbkabHN6DZ0AiSo26m7KvDjHRh2Z6KUuX5+puCAlIm2rstb6q3EmekHAOYPB1A weqNV9BMKcduL1AdwRTgJ7O3dR3D6vOSzTWz0ZWC9gKPQOiDMnwwivRakgcarWodxVB7 MXZZt3Eq1w2HMKZ+4P4mM9ntHOuxQitAOSuDytHuPHjW4te/vjTF2xBU4q9MMXL7TeZZ hm7fHIBICcxAK8m+mSk9z1BSHXbtKZlAvuiGtcXvkYzLV5lOcNaXW1sf3tPcWTu7rVX8 VQ1w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TaEUNwPF; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::62d 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=1749661621; x=1750266421; 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=ozTgSDFHudGokd/ObS3Xm8MoXsMM7sWyALYkNscOGyg=; b=XHKH0IsD8Ta6+SVHO/c8cePJZw4QN2pFS+DvBaJQIVBrO9ugfEPHV7I8kjECIJ55/e aC1gQ4zQ78ACGRykDfOKgCLxtrceT4DQXeVOMPZQZezssMDTNme7OCE3bbDW6nwJ5r+r qBdcyM96132/LN17cXBxGmi70IOPwURHpprj4Wd1bUinw4oXeeoQ8X4JluGaj/N+DZll fllxls6A54EL8XIE3X0O4mpI36r33QtFin/R94Gfxe96jJG9oJuxftqzhu0135SOmgJq PY9Y6lMM61fgSvzhHN538quqek14GJDazhKdCUuHLgNoD+TfsFjrQB0OZpuIQJ7Wjx6H qhvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749661621; x=1750266421; 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=ozTgSDFHudGokd/ObS3Xm8MoXsMM7sWyALYkNscOGyg=; b=OvFCHBjJj4gukhtViLb2EoZ417svtEIPzoEsUV0SmU5Hl/NfL6YjtKPFKAseID1JR+ 8tdEiC68di/vDjVUOGoAHK1RZ9Li9qRhsLq5hKI9EogubaWQ4VwxrWbd1NdakdUB49Ya cGjG5kIm4rnYjLJGXEswgUQO0ZVY5K1HPriPd8hGXmOn+3pUATkYZbWfHHNkHcz0j3dQ QlupVs4DGq6/ur8jr5wLXkzi9bTsN2v0hggjM6u7L8LlpjkrFfQiabRJriOaionxeo9G GIS1UHXkOuv+L7m1wcJLp4Z8LDtR/0NB4H2a58gV0dt60hAddLsaDNUhAG8gdi6aRTnq kPgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749661621; x=1750266421; 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=ozTgSDFHudGokd/ObS3Xm8MoXsMM7sWyALYkNscOGyg=; b=ob0ORssDpXlk8vwjChFyLzkIhVbV+n6E+YwzFk52b+gxCqp09pIcE+eRz2W2Ty89sv oJsA/1Ba+gJNm2iu1qQyG6uTVsDjmgQsqV2x1zrGinjBg2ZK+KfOsWOnWzf+kebATrlL oGdrFHy/1zWUohXvvSWhD49Pokgv6lIKQalqpkDJRAbq8MOQOc1hrNmp29lr2V+JqC03 zI8qTAUp2kPY750H5NlxJJlQlhd6mZZ4ARVLEJSPszKexL056lnGJ432IsWEvzTfTr+n REECESE870O1ODFo6sX4kp/DVpFxjjhscnsoIMtsrIfQDqdnLfB1kuVYSa17+zu/18S0 yUFg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCX76lyd9hj0//hDkTuCnLXsaPExfc2d9nRFS89r3XaQFuiIbPeOrPh4vcc66xJQSug3Sqq3EGy4gWox@gnusha.org X-Gm-Message-State: AOJu0YzO/7VZ8b0yol57YpK8Pm014pAACvNo2/2CjZ9GF513Z2EDCbNs AAz1m1SaXShACBgGbnNENP7qbxYdRZGOqvQWXMRYWpnfyx3vfeqLNtnQ X-Google-Smtp-Source: AGHT+IGk4mHuowR+96zeyd/Ww4Ado0kyxNn81/vJ+5Ml4OzwObmO+KUGOy4QkOTHNaADdv/u1qfH0g== X-Received: by 2002:a05:6808:308b:b0:408:fef8:9c95 with SMTP id 5614622812f47-40a5d120b66mr2477438b6e.24.1749661621187; Wed, 11 Jun 2025 10:07:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeFmCLdzTbbS31BHmAQU3+VLmWmG/4qOKXkfFdTA0NXxA== Received: by 2002:a4a:d810:0:b0:60b:e31f:50c9 with SMTP id 006d021491bc7-60f283af795ls1201207eaf.1.-pod-prod-03-us; Wed, 11 Jun 2025 10:06:58 -0700 (PDT) X-Received: by 2002:a05:6808:2183:b0:3fb:85cc:9f27 with SMTP id 5614622812f47-40a5cef29bfmr2948784b6e.0.1749661616529; Wed, 11 Jun 2025 10:06:56 -0700 (PDT) Received: by 2002:a05:6808:83c1:b0:3f9:f009:458e with SMTP id 5614622812f47-40a5d371f87msb6e; Wed, 11 Jun 2025 09:50:38 -0700 (PDT) X-Received: by 2002:a05:6a00:1787:b0:746:25d1:b711 with SMTP id d2e1a72fcca58-7486ce17a7cmr4748081b3a.17.1749660637485; Wed, 11 Jun 2025 09:50:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749660637; cv=none; d=google.com; s=arc-20240605; b=RulH5ZpagMgIrAXH9tCUlsCkB/diE1gCi56Q/qT8MB/eMIIdhk4ehxIcLfAVNReA07 KuYf4YHyaPQcHl8NKdPW2roDk6GIR7SADU+kp3tKdRS5+89injGWbxNnp6/pF0T/uHe4 +89VAmFgEqpJOxK4eRN7POnKN+NkqWn5wU1K1Ret74gQ6Z9rtRQLpJB9cAW3NW47igJ+ iePmPE6C+DPIg/NSLXTK+gKVAVBTLTZsokHxYfSe9ubSHiyprLK8xMM6s4o5uwkx9BKV axcTpM/B9ewBx6vBC6G2fj0LwbrADSk8swvtZJiC3Bn8Nlm6ECMH4bJNv4ZWQYoMrUiR rUog== 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=eh4Qe+emgE4LiK+g2PW76227h4uHvA3NioaED877yec=; fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=; b=hzFrUp0p40TFT8ueqOxf2LVPK9/qeH6DQNh49PoqMOC0jEOEXdWeHxaCPYZWn0dgfz AkOZFPjfVTCTmqouZ/JdT/UIQJOcUUaSw5l4Pa/d3wNZ+OGVTZ64GtVoBWIV08Z9G1Rd Td+MxE6ZV9OreKrBsbVZ1rrZ0uiocNrtwrFgq8+i2S6h9fPbktAf5OByhnSyBI1dYWI9 WvDP6O1DAo1Zu5BxNkvMURxIhGcCGzgU6MlrcYI7PEgpur1eSJ41AYFI1q7H4FA484M0 cxVdd3zJyNBlQ1P8GvG6YkhXeh2oLs4Q8TGP3qcsMDCo3hui4+OjK1Y+Bf4xkOJ0n+2O ehxA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TaEUNwPF; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::62d 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-pl1-x62d.google.com (mail-pl1-x62d.google.com. [2607:f8b0:4864:20::62d]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-7482af366b1si505204b3a.2.2025.06.11.09.50.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Jun 2025 09:50:37 -0700 (PDT) Received-SPF: pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) client-ip=2607:f8b0:4864:20::62d; Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-235ef62066eso34125ad.3 for ; Wed, 11 Jun 2025 09:50:37 -0700 (PDT) X-Gm-Gg: ASbGncvZCexwowIpxnDkdhPSJbJo1q165HcdsTBB/reB3uZ+UG97yLnv92q+IV+uClT SpAo6sEIDyZvus1GSBgK8ptSfX3OqKQDWnwusSwUCz5JWDZDPzkVySdn/ZCGgurjSuVkhZYGIJE cDwOWR0WBXygN2kd0QVeBTzLU44KWl0/rqdkCxlPfCdg== X-Received: by 2002:a17:903:2302:b0:224:910:23f0 with SMTP id d9443c01a7336-23641b3f15bmr52430595ad.49.1749660636867; Wed, 11 Jun 2025 09:50:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Wed, 11 Jun 2025 12:50:25 -0400 X-Gm-Features: AX0GCFsngiFJX_NbaCr4vB655r7uwVNf-0lLESYEMQ-Wwx2bx5B-vCKYWTVAFUw Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Greg Sanders Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000bcf12406374e9c23" 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=TaEUNwPF; spf=pass (google.com: domain of james.obeirne@gmail.com designates 2607:f8b0:4864:20::62d 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 (/) --000000000000bcf12406374e9c23 Content-Type: text/plain; charset="UTF-8" Greg, > Just noting that the "what is the ultimatum" section is still a > standing question I think this is outside the scope of the letter and this discussion - different cosigners will have different ideas about what should happen if another 6 months goes by without a serious attempt at review and integration. We'll cross that bridge when/if we come to it. > I don't want to do crowd estimation but it seems clear to me there is > higher excitement for this one. We certainly agree there. I know I'm personally more excited about this package than just CTV. I only meant to suggest that there are many people who would have liked to see CTV active on its own earlier. > 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 . Worth noting that Portland himself, on behalf of MARA Pool, is a signer of the letter. > 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. I assume by "more script execution" you're talking about simply allowing the same script interpreter path that everything else uses for CTV on legacy, as it's currently written. Maybe others can debate about whether bumping to a new witness version is a larger or smaller conceptual burden than just dealing with legacy. I don't have a great sense of it. Naively it sounds workable to me, but I still don't really agree with the premise that enabling CTV in legacy is complicated or dangerous. > 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! Worth noting that even after the discovery that this hack isn't a real use for CTV, Robin still signed this letter. But I will let him speak for himself. > From my discussions with other BitVM implementers it certainly sounds > practical? Forgive me for not taking your word for it. I think we might be confused here - I'm certainly not calling BitVM impractical, or what they were trying to do more generally. I'm just saying that CTV might not be the appropriate tool for it, which I think is now clear to everyone. CTV shouldn't really be blamed for this because it was a known hack to begin with. > 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. The point of this whole discussion is that scope expansion continues to happen ad nauseam and consequently no progress is made. This can be a separate consideration with a separate design process without harming anything. > I still think CTV(again in the capability sense) + CSFS are worthy of > consideration, but this is a surefire way to sink it. I sincerely apologize if this has been a frustrating exchange, and I myself am far from a perfect communicator (or thinker!), but please understand that (at least for me) the scope of this letter and discussion are larger than BIP-119 per se. They are an attempt to address a kind of process malfunction that is characterized by a years' long sequence of delays brought on by ultimately minor considerations or appeals to more ambitious designs. Best, 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/CAPfvXfL%3D7bQvhN5ZOJoS-hQ8TmUku%3DmNhxNop%3DZhcyH%2Bkqs9jw%40mail.gmail.com. --000000000000bcf12406374e9c23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,

> Just = noting that the "what is the ultimatum" section is still a
>= ; standing question

I think this is outside the scope of the letter = and this discussion -
different cosigners will have different ideas abou= t what should happen
if another 6 months goes by without a serious attem= pt at review and
integration. We'll cross that bridge when/if we com= e to it.

> I don't want to do crowd estimation but it seems c= lear to me there is
> higher excitement for this one.

We certa= inly agree there. I know I'm personally more excited about this
pack= age than just CTV. I only meant to suggest that there are many
people wh= o would have liked to see CTV active on its own earlier.

> It cle= arly can be a liability if the relative utility of CTV is
> damaged b= y 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 .

Worth noting that Po= rtland himself, on behalf of MARA Pool, is a signer
of the letter.
> I offered the "P2CTV" template for exactly this purpose, p= lease
> consult the patch I wrote. There's no need to introduce m= ore script
> execution to support it.

I assume by "more s= cript execution" you're talking about simply allowing
the same = script interpreter path that everything else uses for CTV on
legacy, as = it's currently written.

Maybe others can debate about whether bu= mping to a new witness version
is a larger or smaller conceptual burden = than just dealing with legacy.
I don't have a great sense of it. Nai= vely it sounds workable to me, but
I still don't really agree with t= he premise that enabling CTV in legacy
is complicated or dangerous.
<= br>
> The Delving thread is declaring that it's a game-changer fo= r BitVM, to
> some knowledgeable people it's obviously considered= a feature. If I
> understand correctly it literally changed Robin Li= nus' opinion on the
> proposal for CTV!

Worth noting that= even after the discovery that this hack isn't a real
use for CTV, R= obin still signed this letter. But I will let him speak
for himself.
=

> From my discussions with other BitVM implementers it certainly= sounds
> practical? Forgive me for not taking your word for it.
<= br>I think we might be confused here - I'm certainly not calling BitVM<= br>impractical, or what they were trying to do more generally. I'm just=
saying that CTV might not be the appropriate tool for it, which I think=
is now clear to everyone. CTV shouldn't really be blamed for thisbecause it was a known hack to begin with.


> A way to commi= t to a neighbor prevout in some way. If that's the
> capability w= e want, we should design for it. If it's not, we should
> mitigat= e it by disallowing it.

The point of this whole discussion is that s= cope expansion continues to
happen ad nauseam and consequently no progre= ss is made. This can be a
separate consideration with a separate design = process without harming
anything.


> I still think CTV(agai= n in the capability sense) + CSFS are worthy of
> consideration, but = this is a surefire way to sink it.

I sincerel= y apologize if this has been a frustrating exchange, and I
myself am far= from a perfect communicator (or thinker!), but please
understand that (= at least for me) the scope of this letter and
discussion are larger than= BIP-119 per se. They are an attempt to
address a kind of process malfun= ction that is characterized by a years'
long sequence of delays brou= ght on by ultimately minor considerations or
appeals to more ambitious d= esigns.


Best,
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/CAPfvXfL%3D7bQvhN5ZOJoS-hQ8TmUku%3DmNhxNop%3DZhcyH%2= Bkqs9jw%40mail.gmail.com.
--000000000000bcf12406374e9c23--