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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
