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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Swift Activation - CTV
Precedence: list

> 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
> > > > >