path: root/5b/93ef738f711c44a5f7e80ea00287c2b1d34a07

Return-Path: <alicexbt@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2B8F2C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 16:43:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0719380BE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 16:43:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0719380BE4
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=wlug1YVE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hC3ih2QxFFMd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 16:43:43 +0000 (UTC)
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
 [185.70.40.137])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 2AD2880BBF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 16:43:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2AD2880BBF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1704213821; x=1704473021;
 bh=WZvnwLwOXSJ97gfsm2zKF7GqEdAVF8jVnSxaYPxo4Jc=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=wlug1YVE8WnOpZbIG4sMLkkmXZH7SHFpxprxkbrYSwjYImWilkv7Dlz+kiTLCJpm1
 ruSy5GvguRefi8NuJpqRHd5rGiFpdhslyZt6sDfUR88R+lkBDRphr8gQn1mCSxh9Ux
 TyAFbHfLIYVhGFPDT7zvFCtupl1RKWhHbJ6f+3JVDrvi9Di0oc+NzG42ectmd6W9kk
 bsbtUvImTgEEsqhzACbIy8XWiHKyTw7HJy0r0w9JKnALXYj1i++ISQkPgrmgIc2f33
 lqgnLtjv+G6Y3aaJo9neDYBP8C9mSe35QwWJ6xLGYs17zDUQ/mYK4coAuypOD/7Jph
 PO/F+MUqK1Ghw==
Date: Tue, 02 Jan 2024 16:43:22 +0000
To: Michael Folkson <michaelfolkson@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <ISvX58I2-K-suhB33yY9A-zeW7xEFpF83jUgYClJH-nu469Gqa4V-YoikUfSb4BPVdFEHJh_JpH7b6OGPZdPQm_HI9_LtKRd_6vno0HdLRI=@protonmail.com>
In-Reply-To: <Zzpp9sp69_QmkUre4YUawBxOLECIfHHUf_OoD8UXXZ8Xwtmr5R62_rlGV2iwLivkST-vWusc0X9horY9qHEHKP2g4GR2ppCAuIE57VANUP0=@protonmail.com>
References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com>
 <2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org>
 <Tp6LkEd_YZUe-0sI-EXRmGTaq4Om2RSKIOUsXS0GIsYW5z_MFnicWPz2hB1KZYJ1mihv0KrJT8DmnuDr1RCcIpFM9jCOy82BvRJySkO7Im8=@protonmail.com>
 <fcOFuPPZB9Cn6nuIkAcvbECmYqISZQ-5O2hQGli-F8FOK68etbaGNlrMT4OuPSBFI9VjaBe_izZEgezy8KZbjeBIaO_QPNfwrF61IorSP44=@protonmail.com>
 <ZY/PYiO2Yg3FNiYV@erisian.com.au>
 <CAJowKg+VR5sYkxOtfeMeaW_ZiU8=6YC_T-21jSBk9VuFO1739g@mail.gmail.com>
 <JjjvS5JDzMsm_gr9M1li4rhxJbQroFXfC8CvIYkHsncrYTB9K723Ds68KnPPm7rKyDgvVdMcUoeg8QQgRKlPsaOSvp5vc6OjB_-TiQZ5iWE=@protonmail.com>
 <CAJowKg+CQWiHxcJLPE7bHbfwGo3WGQSqBNAQU-aEyCJH8YGO3w@mail.gmail.com>
 <Zzpp9sp69_QmkUre4YUawBxOLECIfHHUf_OoD8UXXZ8Xwtmr5R62_rlGV2iwLivkST-vWusc0X9horY9qHEHKP2g4GR2ppCAuIE57VANUP0=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 03 Jan 2024 16:20:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2024 16:43:45 -0000

> Your knowledge is incorrect. As far as I know in the getting on for 2 yea=
rs since the first CTV activation talk/attempt literally no one has built o=
ut a CTV use case and demonstrated it on signet with the possible exception=
 of James O'Beirne's OP_VAULT which requires other new opcodes in addition =
to CTV.=20

This is not true.

https://github.com/AdamISZ/pathcoin-poc

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Tuesday, January 2nd, 2024 at 1:52 PM, Michael Folkson via bitcoin-dev <=
bitcoin-dev@lists.linuxfoundation.org> wrote:


> In the interests of time I'll just pick two to respond to but I don't agr=
ee with any of your points.
>=20
> > Covenants allow trustless utxos sharing and also are needed for vaultin=
g. The numerous use cases are documented, built out and on signet to my kno=
wledge. Check out=C2=A0utxos.org=C2=A0for a good list
>=20
> Your knowledge is incorrect. As far as I know in the getting on for 2 yea=
rs since the first CTV activation talk/attempt literally no one has built o=
ut a CTV use case and demonstrated it on signet with the possible exception=
 of James O'Beirne's OP_VAULT which requires other new opcodes in addition =
to CTV. I wish this wasn't the case. It is pitiful that we have these indiv=
iduals (such as yourself) that are so convinced CTV should be activated but=
 refuse to address any concerns raised by others and refuse to work on any =
of the speculated use cases, instead choosing to just beat the activation d=
rum over and over again.
>=20
> >=C2=A04. "Best tool for the job" is not the bar. "Safe for all" and "use=
ful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in =
the past. Changing the bar is not up for discussion.
>=20
> If you want to avoid a chain split with an activation attempt (it is poss=
ible you don't care but if you do) you have to address concerns others have=
 with a particular proposal. Just because Satoshi was able to make whatever=
 changes he liked in the early days of Bitcoin's history and smaller groups=
 of contributors then were able to activate changes without much scrutiny (=
Bitcoin was worth a fraction of what it is today and was only supporting a =
tiny ecosystem back then) doesn't mean we can do the same today. Appointing=
 Erik as the new Satoshi who can make whatever changes he likes, who define=
s the bar with ultimate certainty and decides what is and what isn't up for=
 discussion also isn't a viable option.
>=20
> Thanks
> Michael
>=20
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>=20
>=20
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>=20
>=20
> On Monday, 1 January 2024 at 17:11, Erik Aronesty <erik@q32.com> wrote:
>=20
>=20
> > 1. Claiming that something that isn't activated (unusable) isn't used a=
s a non-argument
> > 2. Talking about activation methods is orthogonal. Bip8 is fine.
> >=20
> > 3. Covenants allow trustless utxos sharing and also are needed for vaul=
ting. The numerous use cases are documented, built out and on signet to my =
knowledge. Check out utxos.org for a good list
> >=20
> > 3. No need to discuss wild extremes that are unrelated to ctvs well doc=
umented utility. Plus multi-sig allows governments to encumber (or accident=
ally ruin) destination addresses just like covenants.
> >=20
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful f=
or some" is the bar. Like any opcodes or tech Bitcoin has deployed in the p=
ast. Changing the bar is not up for discussion.
> >=20
> >=20
> > CTV has already been demonstrated "useful for some". The question that =
needs to be answered is whether there are any specific objections to safety=
.
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > On Mon, Jan 1, 2024, 11:37 AM Michael Folkson <michaelfolkson@protonmai=
l.com> wrote:
> >=20
> > > Hi Erik
> > >=20
> > >=20
> > > > So what exactly are the risks of CTV over multi-sig?
> > >=20
> > >=20
> > > It is a strange comparison. Multisig is active onchain and is being u=
sed today for all sorts of things including Lightning and setups that addre=
ss risk of single key loss or malicious signing. When discussing risks of C=
TV 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 bei=
ng used today), other proposals end up being used instead of it (I'm not su=
re 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 full=
y utilize Taproot trees is still low today. Going straight to covenants (im=
posing restrictions on where funds can be sent) and not bothering with impo=
sing 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-ze=
ro) aren't as obvious as some of the covenant advocates are suggesting. And=
 although CTV is a limited covenant (some argue too limited) covenants take=
n to wild extremes could create all sorts of second order effects where fun=
ds can't be spent because of complex combinations of covenants. Even the st=
rongest CTV proponent seems to suggest that the introduction of covenants w=
ouldn't end with CTV.
> > >=20
> > >=20
> > > 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 i=
t to be activated does not reduce that implementation risk in any way, shap=
e or form.
> > >=20
> > >=20
> > > Thanks
> > > Michael
> > >=20
> > >=20
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson at protonmail.com
> > > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> > >=20
> > >=20
> > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> > >=20
> > >=20
> > > On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev=
 <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >=20
> > >=20
> > > > So what exactly are the risks of CTV over multi-sig?
> > > >=20
> > > >=20
> > > > >=20
> > > > >