path: root/f3/37203e6ccc11432d9eaef85aaa977689fd03df

Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CA35EC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Dec 2023 13:54:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 97C62404F1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Dec 2023 13:54:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 97C62404F1
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=JT9OR3aK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7FL-9sJYP1mU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Dec 2023 13:54:29 +0000 (UTC)
Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com
 [188.165.51.139])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C691940143
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 30 Dec 2023 13:54:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C691940143
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1703944460; x=1704203660;
 bh=65DRgN2PYzuIfVBvWeQHG8QJNXAX7kOKOsjqbDML2Do=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=JT9OR3aKUKPqXvIf2vv3A70sO4ngWH4Dl+f/znRt4kfsXDA6FfccT9AoXg7fDGmRw
 +vc3id7HttHMix2PGwvD1FoFhY82GIg3J1TBQZdIHmJQT9LrOAgl5ug7QkQ7o/Vndy
 Yg8WGX3/EWepVg3PE9Y7ml/OCeSnkalNYwddk3Dq7dUZbLRiU67R6ZitR3RPNXJx1V
 rjr7AYIM1GUyAOaXmmo97Tl6i7reHe1Pf5YBznT533I2FkJVGpqHSG7D9zfBI3K4up
 fr4aaKFBxE1hnuwR3619iBqzyHYeQ2LvoMqzlATsPvXMWUfuZTyckCJsfWVRhNA2SQ
 mInZj7qJySyLQ==
Date: Sat, 30 Dec 2023 13:54:04 +0000
To: Anthony Towns <aj@erisian.com.au>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <7NGPxdCD3faagkDFsyhVnjyXGu_BF3PfRW86QjZxP-nsDY-EvNGlyxXSEA7nf0SYzm5Ql45sA7gDGjKNpqWQoALLUz-MROUZTGjEFtzTdm8=@protonmail.com>
In-Reply-To: <ZY/PYiO2Yg3FNiYV@erisian.com.au>
References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com>
 <2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org>
 <Tp6LkEd_YZUe-0sI-EXRmGTaq4Om2RSKIOUsXS0GIsYW5z_MFnicWPz2hB1KZYJ1mihv0KrJT8DmnuDr1RCcIpFM9jCOy82BvRJySkO7Im8=@protonmail.com>
 <fcOFuPPZB9Cn6nuIkAcvbECmYqISZQ-5O2hQGli-F8FOK68etbaGNlrMT4OuPSBFI9VjaBe_izZEgezy8KZbjeBIaO_QPNfwrF61IorSP44=@protonmail.com>
 <ZY/PYiO2Yg3FNiYV@erisian.com.au>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 30 Dec 2023 15:58:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Swift Activation - CTV
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Dec 2023 13:54:30 -0000

Hey AJ

Thanks for this, pretty much agree with all of it. It seems like a week doe=
sn't go by now without a new individual popping out the woodwork proposing =
an upcoming activation of CTV with no new PoCs and no new insights. I'm not=
 sure what it is about CTV (versus say other proposals) that it keeps attra=
cting these people that refuse to work on PoCs or anything that drives the =
research area forward and yet want to try to attempt activation where the s=
uccess scenario would be a chain split.

> > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") we=
re just a bad approach from the start.

It is hard to discuss APO in a vacuum when this is going on the background =
but I'm interested in you grouping APO with CTV in this statement. At the t=
ime of writing there clearly isn't consensus or advanced PoCs on any of the=
 use cases CTV claims to enable. (One rare exception on the use case front =
is James O'Beirne's OP_VAULT [0] that requires additional opcodes to OP_CTV=
). But APO does seem to be the optimal design and have broad consensus in t=
he Lightning community for enabling eltoo/LN-Symmetry. Any other use cases =
APO enables would be an additional benefit.

I don't think one can seriously think about an *upcoming* activation for AP=
O as there is still more work to do to convince the community that it would=
 be worth the risks of embarking on another activation process. But assumin=
g another year of concerted work on APO and the CTV woodwork of chaos (hope=
fully) being exhausted do you think an APO activation would be viable in sa=
y 2025/2026? Is your hesitancy on APO based on any particular technical con=
cerns or just fatigue from the CTV chaos?

Thanks
Michael

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/0=
21318.html

--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin


On Saturday, 30 December 2023 at 08:05, Anthony Towns via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:


> Huh, this list is still active?
>=20
> On Fri, Dec 22, 2023 at 10:34:52PM +0000, alicexbt via bitcoin-dev wrote:
>=20
> > I think CTV is not ready for activation yet. Although I want it to be a=
ctivated and use payment pools, we still have some work to do and AJ is cor=
rect that we need to build more apps that use CTV on signet.
>=20
>=20
> I've said it before, and I'll say it again, but if you want to change
> bitcoin consensus rules, IMO the sensible process is:
>=20
> * work out what you think the change should be
> * demonstrate the benefits so everyone can clearly see what they are,
> and that they're worth spending time on
> * review the risks, so that whatever risks there may be are well
> understood, and minimise them
> * iterate on all three of those steps to increase the benefits and
> reduce the risks
> * once "everyone" agrees the benefits are huge and the risks are low,
> work on activating it
>=20
> If you're having trouble demonstrating that the benefits really are
> worth spending time on, you probably need to go back to the first step
> and reconsider the proposal. The "covtools" and "op_cat" approaches are
> a modest way of doing that: adding additional opcodes that mesh well
> with CTV, increasing the benefits from making a change.
>=20
> But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO")
> were just a bad approach from the start. Presumably "activate CTV"
> is really intended as a step towards your actual goal, whether that be
> "make it harder for totalitarians to censor payments", "replace credit
> cards", "make lots of money", "take control over bitcoind evelopment",
> or something else. Maybe there's a better step towards some/all of
> whatever those goals may be than "activate CTV". Things like "txhash"
> take that approach and go back to the first step.
>=20
> To me, it seems like CTV has taken the odd approach of simultaneously
> maximising (at least perceived) risk, while minimising the potential
> benefits. As far as maximising risk goes, it's taken Greg Maxwell's
> "amusingly bad idea" post from bitcointalk in 2013 [1] and made the bad
> consequence described there (namely, "coin covenants", which left Greg
> "screaming in horror") as the centrepiece of the functionality being
> added, per its motivation section. It then minimises the potential
> benefits that accompany that risk by restricting the functionality being
> provided as far as you can without neutering it entirely. If you wanted
> a recipe for how to propose a change to bitcoin and ensure that it's
> doomed to fail while still gathering a lot of attention, I'm honestly
> not sure how you could come up with a better approach?
>=20
> [0] https://en.wikipedia.org/wiki/Target_fixation
> [1] https://bitcointalk.org/index.php?topic=3D278122.0
>=20
> > - Apart from a few PoCs that do not achieve anything big on mainnet, no=
body has tried to build PoC for a use case that solves real problems
>=20
>=20
> One aspect of "minimising the benefits" is that when you make something
> too child safe, it can become hard to actually use the tool at all. Just
> having ideas is easy -- you can just handwave over the complex parts
> when you're whiteboarding or blogging -- the real way to test if a tool
> is fit for purpose is to use it to build something worthwhile. Maybe a
> great chef can create a great meal with an easy-bake oven, but there's
> a reason it's not their tool of choice.
>=20
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev