From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B8F2C0037 for ; 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 ; 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 ; 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 ; 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 From: alicexbt Message-ID: In-Reply-To: References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com> <2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org> 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 , 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: 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 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 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= wrote: > > >=20 > > >=20 > > > > So what exactly are the risks of CTV over multi-sig? > > > >=20 > > > >=20 > > > > >=20 > > > > >