From: Michael Folkson <michaelfolkson@protonmail.com>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Swift Activation - CTV
Date: Mon, 01 Jan 2024 16:37:35 +0000 [thread overview]
Message-ID: <JjjvS5JDzMsm_gr9M1li4rhxJbQroFXfC8CvIYkHsncrYTB9K723Ds68KnPPm7rKyDgvVdMcUoeg8QQgRKlPsaOSvp5vc6OjB_-TiQZ5iWE=@protonmail.com> (raw)
In-Reply-To: <CAJowKg+VR5sYkxOtfeMeaW_ZiU8=6YC_T-21jSBk9VuFO1739g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]
Hi Erik
> So what exactly are the risks of CTV over multi-sig?
It is a strange comparison. Multisig is active onchain and is being used today for all sorts of things including Lightning and setups that address risk of single key loss or malicious signing. When discussing risks of CTV there are all sorts of risks that don't apply to multisig. These include that it is never used for any of its speculated use cases (multisig is being used today), other proposals end up being used instead of it (I'm not sure there were or are competing proposals so that multisig stops being used, MuSig2 maybe?), chain split risks with activation if there isn't consensus to activate it etc. Plus usage of complex (non covenant) scripts that fully utilize Taproot trees is still low today. Going straight to covenants (imposing restrictions on where funds can be sent) and not bothering with imposing all the restrictions you'd like on how funds can be spent in the first place seems to me to be putting the cart before the horse. Covenants don't ultimately solve the key management issue, they just move it from the pre spending phase to the post spending phase. So the benefits (although non-zero) aren't as obvious as some of the covenant advocates are suggesting. And although CTV is a limited covenant (some argue too limited) covenants taken to wild extremes could create all sorts of second order effects where funds can't be spent because of complex combinations of covenants. Even the strongest CTV proponent seems to suggest that the introduction of covenants wouldn't end with CTV.
The way to reduce implementation risk for a use case of a particular proposal is to build out that use case and see if CTV is the best tool for the job. Repeatedly trying to activate CTV when there isn't consensus for it to be activated does not reduce that implementation risk in any way, shape or form.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> So what exactly are the risks of CTV over multi-sig?
>
>>
[-- Attachment #2: Type: text/html, Size: 7675 bytes --]
next prev parent reply other threads:[~2024-01-01 16:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 1:44 [bitcoin-dev] Swift Activation - CTV 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
2023-12-30 8:59 ` Erik Aronesty
2024-01-01 16:37 ` Michael Folkson [this message]
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='JjjvS5JDzMsm_gr9M1li4rhxJbQroFXfC8CvIYkHsncrYTB9K723Ds68KnPPm7rKyDgvVdMcUoeg8QQgRKlPsaOSvp5vc6OjB_-TiQZ5iWE=@protonmail.com' \
--to=michaelfolkson@protonmail.com \
--cc=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=erik@q32.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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