public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32•com>
To: "Jorge Timón" <jtimon@jtimon•cc>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] What to expect in the next few weeks
Date: Tue, 26 Apr 2022 09:42:43 -0400	[thread overview]
Message-ID: <CAJowKg+MNMLKbB2z4cwT6HfXT7ZF2MW7JqRpN8-4wCusf7MJnw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDq2w=oe94m5mmdhaUECfNwnXa8C5pQ_JaAJxCrndgjsWQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

>
>
> I would comment on this point, but I'm not sure I'm "technical enough". I
> have to admit: I've never played tennis.
>

You are technicial enough to read the nacks... everyone is:
https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

I can give a summary of the nack arguments here on one sentence:    "I am
resisting a consensus change because we don't have consensus"

It's lovely recursive logic

------

The most cogent *technical* arguments against ctv seem fall into 3 camps:

1. APO is better for eltoo:
https://twitter.com/rusty_twit/status/1518007923896578048?s=20&t=8IUgni_i5jcfSlJ1Gy7T1A

2. CTV doesn't have recursion, but i want recursion... which are swiftly
followed by arguments against recursion:
https://bitcoinops.org/en/newsletters/2022/03/09/#limiting-script-language-expressiveness

(I usually ignore this one)

3. TLUV is super cool for vaults, so why are we even talking about CTV when
TLUV is better?

I like this (positive vibes) summary:

https://raymonddurk.medium.com/bitcoin-after-taproot-86c93fe5cc0c

Nowhere in there would anyone say CTV is "bad".

Just that other opcodes will wind up being used more because they are more
purpose-fit for <insert use case here>

If only we had unlimited resources we could have APO/TLUV;/CTV all ready to
go and be able to evaluate them on a level playing field / signet.

Does this sound about right?   Am I missing something?


- Erik

[-- Attachment #2: Type: text/html, Size: 2903 bytes --]

  reply	other threads:[~2022-04-26 13:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22 16:38 Michael Folkson
2022-04-23  5:10 ` Billy Tetrud
2022-04-23 10:03   ` Michael Folkson
2022-04-25 22:26     ` Michael Folkson
2022-04-26  5:48       ` Jeremy Rubin
2022-04-26 10:47         ` Anthony Towns
2022-04-26 16:02           ` Jeremy Rubin
2022-04-26 13:53         ` Michael Folkson
2022-04-26 15:20           ` Jeremy Rubin
2022-04-27  5:59           ` alicexbt
2022-04-26 11:40       ` Jorge Timón
2022-04-26 13:42         ` Erik Aronesty [this message]
2022-04-26  6:39 ` Melvin Carvalho

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=CAJowKg+MNMLKbB2z4cwT6HfXT7ZF2MW7JqRpN8-4wCusf7MJnw@mail.gmail.com \
    --to=erik@q32$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jtimon@jtimon$(echo .)cc \
    /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