From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C4AB4C0037 for ; Mon, 1 Jan 2024 17:11:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9A09B60E13 for ; Mon, 1 Jan 2024 17:11:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9A09B60E13 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail-com.20230601.gappssmtp.com header.i=@gmail-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=njnRGknz X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNoxOh8vQuWk for ; Mon, 1 Jan 2024 17:11:39 +0000 (UTC) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4CB2D60DFA for ; Mon, 1 Jan 2024 17:11:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4CB2D60DFA Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-5f0e8a8d796so2135177b3.1 for ; Mon, 01 Jan 2024 09:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1704129098; x=1704733898; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uNpIutpRMzZh8YLbWAycghoM+ADC73yWayNAyp0ypS4=; b=njnRGknzzyfeiJ1yHjl+Xuk/KkJmSDjhhvk6dlzrLkgxRoTXGk2qeC8uht5JQfi3HN wt6Fc9+JvGBwKPTrWkd6e8ZrsjAwHjLvBQTNjTOen5U2IfN/XQt925mwc5yagONnpsg+ A2s4KK5U/53rdqRjwvhAxQ1+iNhNgkdqrLF4LJvxrQ3QdjGtmHHQ8qi1/kl/vNrxGJ7u OvI9tzd/pnvbgnZpkVoY01qnhQY+/y6qRn9UbrrtWdcGclj7poUEBA4jtofeNNKlvQrg N6T3a922S3Kt+gPQp9Sh+LLM/K2+2cGs3jshPv9ZfImHeMs9qjrnNlBhdCPyL3vSWDrE 1Ekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704129098; x=1704733898; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uNpIutpRMzZh8YLbWAycghoM+ADC73yWayNAyp0ypS4=; b=fqaK9ChNR9cyNzO9UB7Ra+Ajf2b7Mpa0dMCiNx5v9fPC010lJWlksML3teMgpeCpJN fARvI7NbEXTvM2IYdLWToYroQAbAf7JAq3tG16Nng+Zx+9DMawlZAKtL1BpjSswBL8Ty 9kyOMmz/Dd29UoKEhP2O4U0izToCYo5p7OlkVizFOXrgtLGRo8N2VlcOrWHwwuprMYSR DD0SezqhXMC+0JSZ/ru2UxH9+9n5dODyPTKDalrZORRlLREIqB5V0Mh3iWT/FsmKhC/f S+kQhaqpn8hFl1Lv1x2gXHNTp1+fvx0bPFHMdbExl+mMg5H3gzX22Hi7O6qGjOc1gYXk H4CA== X-Gm-Message-State: AOJu0Yw+7P4s4k5pV+s0+nTEqRnYlmgWI0jx1m3SCW7NAouV9Es6OoqT aSFzCrmOOwFNiZTDPgN67/U2VR9rntWsGTeHEQklazE= X-Google-Smtp-Source: AGHT+IGeh5KR7oqX+eBCVM3nneFkkB+10h9T/huMqQRlbBCS8TBAj4nsfa4q54z0HMpYBFCP82lptdh2rMZqazk/y6o= X-Received: by 2002:a05:6902:f0e:b0:dbe:33e5:44ae with SMTP id et14-20020a0569020f0e00b00dbe33e544aemr7671380ybb.2.1704129097242; Mon, 01 Jan 2024 09:11:37 -0800 (PST) MIME-Version: 1.0 References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com> <2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org> In-Reply-To: From: Erik Aronesty Date: Mon, 1 Jan 2024 12:11:24 -0500 Message-ID: To: Michael Folkson Content-Type: multipart/alternative; boundary="0000000000007e1c77060de57999" X-Mailman-Approved-At: Tue, 02 Jan 2024 12:08:20 +0000 Cc: Bitcoin Protocol Discussion , Anthony Towns Subject: Re: [bitcoin-dev] Swift Activation - CTV X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2024 17:11:40 -0000 --0000000000007e1c77060de57999 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1. Claiming that something that isn't activated (unusable) isn't used as a non-argument 2. Talking about activation methods is orthogonal. Bip8 is fine. 3. Covenants allow trustless utxos sharing and also are needed for vaulting. The numerous use cases are documented, built out and on signet to my knowledge. Check out utxos.org for a good list 3. No need to discuss wild extremes that are unrelated to ctvs well documented utility. Plus multi-sig allows governments to encumber (or accidentally ruin) destination addresses just like covenants. 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. Changing the bar is not up for discussion. CTV has already been demonstrated "useful for some". The question that needs to be answered is whether there are any specific objections to safety= . On Mon, Jan 1, 2024, 11:37 AM Michael Folkson wrote: > 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 CT= V > 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 n= ot > 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) script= s > that fully utilize Taproot trees is still low today. Going straight to > covenants (imposing restrictions on *where*=E2=80=8B funds can be sent) a= nd not > bothering with imposing all the restrictions you'd like on *how*=E2=80=8B= 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, the= y > just move it from the pre spending phase to the post spending phase. So t= he > 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 sort= s > 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 fo= r > 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 > 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? > > >> >> > --0000000000007e1c77060de57999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1. Claiming that something that isn't activated = (unusable) isn't used as a non-argument

2. Talking about activation methods is orthogonal.=C2=A0 Bip8= is fine.

3. Covenants a= llow trustless utxos sharing and also are needed for vaulting.=C2=A0 The nu= merous use cases are documented, built out and on signet to my knowledge.= =C2=A0 Check out utxos.org for a good list=

3. No need to discuss w= ild extremes that are unrelated to ctvs well documented utility.=C2=A0 Plus= multi-sig allows governments to encumber (or accidentally ruin) destinatio= n addresses just like covenants.

4. "Best tool for the job" is not the bar. "Safe f= or all" and "useful for some" is the bar. Like any opcodes o= r tech Bitcoin has deployed in the past.=C2=A0 Changing the bar is not up f= or discussion.


CTV has already been demonstrated "useful for some&= quot;.=C2=A0 The question that needs to be answered is whether there are an= y specific objections to safety.






=


On Mon, Jan 1, 2024, 11:37 AM Michael Folkson <michaelfolkson@protonmail.com> wrote= :
Hi Erik

>=C2=A0So what exactly are the risks= of CTV over multi-sig?

It is a strange comparison. Multisig is ac= tive onchain and is being used today for all sorts of things including Ligh= tning 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 a= pply to multisig. These include that it is never used for any of its specul= ated 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 c= omplex (non covenant) scripts that fully utilize Taproot trees is still low= today. Going straight to covenants (imposing restrictions on where= =E2=80=8B funds can be sent) and not bothering with imposing all the restri= ctions you'd like on how=E2=80=8B funds can be spent in the firs= t place seems to me to be putting the cart before the horse. Covenants don&= #39;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 n= on-zero) aren't as obvious as some of the covenant advocates are sugges= ting. And although CTV is a limited covenant (some argue too limited) coven= ants 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 o= f covenants wouldn't end with CTV.

The way to reduce implement= ation 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 act= ivate CTV when there isn't consensus for it to be activated does not re= duce that implementation risk in any way, shape or form.

Thanks
= Michael

--
Michael Folkson
<= span style=3D"font-family:'SFMono-Regular',Consolas,'Liberation= Mono',Menlo,monospace,monospace">Email:= michaelfolkson at protonmail.com<= span style=3D"font-family:'SFMono-Regular',Consolas,'Liberation= Mono',Menlo,monospace,monospace">
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

=20
=20

On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wro= te:

So what exactly are the risks of CTV over mul= ti-sig?




--0000000000007e1c77060de57999--