From: Erik Aronesty <erik@q32•com>
To: Billy Tetrud <billy.tetrud@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Date: Sat, 23 Apr 2022 10:48:30 -0400 [thread overview]
Message-ID: <CAJowKg+Pa78-h-gnD8JVDFNx76DR0NC51mU=YwwEMtpZJ_WvPg@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDZgZgcK1noNPx7zFh5hs3=jW8ZC4fbCcbf0uXJX2RUw+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]
On Sat, Apr 23, 2022, 5:05 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> @Zac
> > More use cases means more blockchain usage which increases the price of
> a transaction for *everyone*.
>
> This is IMO a ridiculous opposition. Anything that increases the utility
> of the bitcoin network will increase usage of the blockchain and increase
> the price of a transaction on average. It is absurd to say such a thing is
> bad for bitcoin. Its like the old saying: "nobody goes there any more -
> its too crowded".
>
> > I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
> users.
>
> This is a fair opinion to take on the face of it. However, I completely
> disagree with it. Why must any change benefit *all* users? Did segwit
> benefit all users? Did taproot? What if an upgrade benefits 90% of users
> a LOT and at the same time doesn't negatively affect the other 10%? Is that
> a bad change? I think you'd find it very difficult to argue it is.
>
> Regardless of the above, I think CTV *does *in fact likely provide
> substantial benefit to all users in the following ways:
>
> 1. CTV allows much easier/cheaper ways of improving their security via
> wallet vaults,
>
Maybe. But there are enough security caveats that it probably needs other
opcodes too to be useful.
DLCs, channels
>
APO (BIP118) handles these with a smaller footprint
and many other use cases.
>
Someone want to volunteer to make a table of use cases, proposed opcodes
(CTV, APO) and a maturity and efficiency rating at each intersection?
Hard to juggle all this.
I'm not a fan of the squeaky wheel method of consensus.
I do think most people believe some form of restricted, well-tested
covenants that don't allow for recursion should make it into Bitcoin at
some point.
[-- Attachment #2: Type: text/html, Size: 3118 bytes --]
next prev parent reply other threads:[~2022-04-23 14:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 16:45 Michael Folkson
2022-04-21 23:36 ` Keagan McClelland
2022-04-22 9:03 ` Zac Greenwood
2022-04-22 15:40 ` Corey Haddad
2022-04-23 5:07 ` Billy Tetrud
2022-04-23 14:48 ` Erik Aronesty [this message]
2022-04-24 14:47 ` Peter Todd
2022-04-25 5:36 ` ZmnSCPxj
2022-04-25 9:06 ` Zac Greenwood
2022-04-25 10:01 ` ZmnSCPxj
2022-04-22 9:53 ` Michael Folkson
2022-04-23 20:40 ` Jorge Timón
2022-04-24 12:17 ` Michael Folkson
2022-04-24 12:57 ` Jorge Timón
2022-04-24 12:55 ` Ryan Grant
2022-04-24 13:11 ` Jorge Timón
2022-04-24 13:15 ` Ryan Grant
2022-04-25 16:11 alicexbt
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+Pa78-h-gnD8JVDFNx76DR0NC51mU=YwwEMtpZJ_WvPg@mail.gmail.com' \
--to=erik@q32$(echo .)com \
--cc=billy.tetrud@gmail$(echo .)com \
--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