Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5CFCEC0037 for ; Sat, 30 Dec 2023 08:46:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 37CFD82884 for ; Sat, 30 Dec 2023 08:46:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 37CFD82884 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOkgUysrY8WF for ; Sat, 30 Dec 2023 08:46:53 +0000 (UTC) X-Greylist: delayed 2449 seconds by postgrey-1.37 at util1.osuosl.org; Sat, 30 Dec 2023 08:46:53 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0AE1E82871 Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0AE1E82871 for ; Sat, 30 Dec 2023 08:46:52 +0000 (UTC) Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJUM2-0003y6-93 for bitcoin-dev@lists.linuxfoundation.org; Sat, 30 Dec 2023 18:06:00 +1000 Received: by email (sSMTP sendmail emulation); Sat, 30 Dec 2023 18:05:54 +1000 Date: Sat, 30 Dec 2023 18:05:54 +1000 From: Anthony Towns To: Bitcoin Protocol Discussion Message-ID: References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com> <2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam_score: -0.0 X-Spam_bar: / 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 08:46:54 -0000 Huh, this list is still active? On Fri, Dec 22, 2023 at 10:34:52PM +0000, alicexbt via bitcoin-dev wrote: > I think CTV is not ready for activation yet. Although I want it to be activated and use payment pools, we still have some work to do and AJ is correct that we need to build more apps that use CTV on signet. 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: * 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 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. 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. 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? [0] https://en.wikipedia.org/wiki/Target_fixation [1] https://bitcointalk.org/index.php?topic=278122.0 > - Apart from a few PoCs that do not achieve anything big on mainnet, nobody has tried to build PoC for a use case that solves real problems 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. Cheers, aj