public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Swift Activation - CTV
Date: Sat, 30 Dec 2023 18:05:54 +1000	[thread overview]
Message-ID: <ZY/PYiO2Yg3FNiYV@erisian.com.au> (raw)
In-Reply-To: <fcOFuPPZB9Cn6nuIkAcvbECmYqISZQ-5O2hQGli-F8FOK68etbaGNlrMT4OuPSBFI9VjaBe_izZEgezy8KZbjeBIaO_QPNfwrF61IorSP44=@protonmail.com>

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


  reply	other threads:[~2023-12-30  8:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20  1:44 alicexbt
2023-12-22  1:05 ` Luke Dashjr
2023-12-22  1:56   ` alicexbt
2023-12-22 22:34     ` alicexbt
2023-12-30  8:05       ` Anthony Towns [this message]
2023-12-30  8:59         ` Erik Aronesty
2024-01-01 16:37           ` Michael Folkson
2024-01-01 17:11             ` Erik Aronesty
2024-01-02 13:52               ` Michael Folkson
2024-01-02 14:32                 ` Erik Aronesty
2024-01-02 16:24                 ` Ryan Breen
2024-01-02 16:43                 ` alicexbt
2023-12-30 13:54         ` Michael Folkson
2024-01-03  8:36           ` Anthony Towns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZY/PYiO2Yg3FNiYV@erisian.com.au \
    --to=aj@erisian$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox