Re: [bitcoin-dev] Swift Activation - CTV

[Anthony Towns <aj@erisian.com.au>]

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