From: "Jorge Timón" <jtimon@jtimon•cc>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Speedy covenants (OP_CAT2)
Date: Sat, 7 May 2022 00:30:01 +0200 [thread overview]
Message-ID: <CABm2gDoivzQKFr6KqeqW6+Lx7xFVprRCUAn1k3X6P29NPzw+yQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
OP_CAT was removed. If I remember correctly, some speculated that perhaps
it was removed because it could allow covenants.
I don't remember any technical concern about the OP besides enabling
covenants.
Before it was a common opinion that covenants shouldn't be enabled in
bitcoin because, despite having good use case, there are some nasty attacks
that are enabled with them too. These days it seems the opinion of the
benefits being worth the dangers is quite generalized. Which is quite
understandable given that more use cases have been thought since then.
Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating
a new OP_CAT2 that does the same would be a softfork.
As far a I know, this is the covenants proposal that has been implemented
for the longest time, if that's to be used as a selection criteria.
And as always, this is not incompatible with deploying other convenant
proposals later.
Personally I find the simplicity proposal the best one among all the
covenant proposals by far, including this one.
But I understand that despite the name, the proposal is harder to review
and test than other proposals, for it wouldn't simply add covenants, but a
complete new scripting language that is better in many senses.
Speedy covenants, on the other hand, is much simpler and has been
implemented for longer, so in principle, it should be easier to deploy in a
speedy manner.
What are the main arguments against speedy covenants (aka op_cat2) and
against deploying simplicity in bitcoin respectively?
Sorry if this was discussed before.
[-- Attachment #2: Type: text/html, Size: 1817 bytes --]
next reply other threads:[~2022-05-06 22:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 22:30 Jorge Timón [this message]
2022-05-07 3:06 ` ZmnSCPxj
2022-05-07 3:52 ` vjudeu
2022-05-07 13:31 ` Jorge Timón
2022-05-11 15:25 ` alicexbt
2022-05-11 16:03 ` vjudeu
2022-05-07 13:27 ` Jorge Timón
2022-05-07 14:08 ` ZmnSCPxj
[not found] ` <CABm2gDo1wTOoWcNgJ4mUgSB3KCtBSnjqe3nwVBSL+7=ziDJ==w@mail.gmail.com>
2022-05-07 22:28 ` ZmnSCPxj
2022-05-08 2:03 ` Nadav Ivgi
2022-05-08 2:19 ` ZmnSCPxj
2022-05-11 10:57 ` vjudeu
2022-05-11 11:42 ` ZmnSCPxj
2022-05-11 19:41 ` Russell O'Connor
2022-05-12 3:07 ` ZmnSCPxj
2022-05-12 10:48 ` Russell O'Connor
2022-05-13 21:43 ` Anthony Towns
2022-05-13 23:33 ` Russell O'Connor
2022-05-14 13:32 ` Erik Aronesty
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=CABm2gDoivzQKFr6KqeqW6+Lx7xFVprRCUAn1k3X6P29NPzw+yQ@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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