From: "Jorge Timón" <jtimon@jtimon•cc>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Date: Sat, 7 May 2022 15:27:16 +0200 [thread overview]
Message-ID: <CABm2gDrdwMjLu=i0p2m4SZ_91xpr-RvwSSWOnS9jhaQ3uaCxPA@mail.gmail.com> (raw)
In-Reply-To: <1JO1xrnJ9GwGM4TgLH_rL_LpnZgSb1SyeEOJ9Gzc1VMbKUrmxSh-zUXKwFNvp_5wyiDtRviOf-gRJbrfbhOJl-qym1eEHXpoDAgjE9juucw=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5713 bytes --]
Thanks a lot for the many clarifications.
Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things.
I guess this wouldn't be a covenants proposal then.
But simplicity would enable covenants too indeed, no?
Or did I get that wrong too?
On Sat, May 7, 2022 at 5:06 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning Jorge,
>
> > 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.
>
> I think the more accurate reason for why it was removed is because the
> following SCRIPT of N size would lead to 2^N memory usage:
>
> OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP
> OP_CAT OP_DUP OP_CAT ...
>
> In particular it was removed at about the same time as `OP_MUL`, which has
> similar behavior (consider that multiplying two 32-bit numbers results in a
> 64-bit number, similar to `OP_CAT`ting a vector to itself).
>
> `OP_CAT` was removed long before covenants were even expressed as a
> possibility.
>
> Covenants were first expressed as a possibility, I believe, during
> discussions around P2SH.
> Basically, at the time, the problem was this:
>
> * Some receivers wanted to use k-of-n multisignature for improved security.
> * The only way to implement this, pre-P2SH, was by putting in the
> `scriptPubKey` all the public keys.
> * The sender is the one paying for the size of the `scriptPubKey`.
> * It was considered unfair that the sender is paying for the security of
> the receiver.
>
> Thus, `OP_EVAL` and the P2SH concept was conceived.
> Instead of the `scriptPubKey` containing the k-of-n multisignature, you
> create a separate script containing the public keys, then hash it, and the
> `scriptPubKey` would contain the hash of the script.
> By symmetry with the P2PKH template:
>
> OP_DUP OP_HASH160 <hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIG
>
> The P2SH template would be:
>
> OP_DUP OP_HASH160 <hash160(redeemScript)> OP_EQUALVERIFY OP_EVAL
>
> `OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT.
>
> It was then pointed out that `OP_EVAL` could be used to create recursive
> SCRIPTs by quining using `OP_CAT`.
> `OP_CAT` was already disabled by then, but people were talking about
> re-enabling it somehow by restricting the output size of `OP_CAT` to limit
> the O(2^N) behavior.
>
> Thus, since then, `OP_CAT` has been associated with ***recursive***
> covenants (and people are now reluctant to re-enable it even with a limit
> on its output size, because recursive covenants).
> In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and
> `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too
> to quine.
>
> Because of those concerns, the modern P2SH is now "just a template" with
> an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL`
> being actually enabled.
>
> (`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to
> remember that P2SH was pretty much what codified the difference between
> softfork and hardfork, and the community at the time was small enough (or
> so it seemed) that a hardfork might not have been disruptive.)
>
> > 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.
>
> If you are willing to work in Taproot the same OP-code can be enabled in a
> softfork by using a new Tapscript version.
>
> If you worry about quantum-computing-break, a new SegWit version (which is
> more limited than Tapscript versions, unfortunately) can also be used,
> creating a new P2WSHv2 (or whatever version) that enables these opcodes.
>
> > 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.
>
> No, it was `OP_EVAL`, not `OP_CAT`.
> In particular if `OP_EVAL` was allowed in the `redeemScript` then it would
> enable covenants as well.
> It was just pointed out that `OP_CAT` enables recursive covenenats in
> combination with `OP_EVAL`-in-`redeemScript`.
>
> In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows
> recursive covenants, but also recursion *within* a SCRIPT i.e. unbounded
> SCRIPT execution.
> Thus, `OP_EVAL` is simply not going to fly, at all.
>
> > 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.
>
> `OP_CAT`, by itself, does not implement any covenants --- instead, it
> creates recursive covenants when combined with almost all covenant opcodes.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 6268 bytes --]
next prev parent reply other threads:[~2022-05-07 13:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 22:30 Jorge Timón
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 [this message]
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='CABm2gDrdwMjLu=i0p2m4SZ_91xpr-RvwSSWOnS9jhaQ3uaCxPA@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--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