From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA35EC0037 for ; 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 ; 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 ; 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 ; 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 From: Michael Folkson Message-ID: <7NGPxdCD3faagkDFsyhVnjyXGu_BF3PfRW86QjZxP-nsDY-EvNGlyxXSEA7nf0SYzm5Ql45sA7gDGjKNpqWQoALLUz-MROUZTGjEFtzTdm8=@protonmail.com> In-Reply-To: References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com> <2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org> 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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