path: root/26/5c7714ad8aecfd3365fb46f6e5d121e368a7f8

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B9CABC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 03:52:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 9EAF9410A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 03:52:57 +0000 (UTC)
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,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JqY7xisK_nr6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 03:52:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo115.poczta.onet.pl (smtpo115.poczta.onet.pl
 [213.180.149.168])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 89666409F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 03:52:55 +0000 (UTC)
Received: from mta3.m5r2.onet (mta3.m5r2.onet [10.174.35.137])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4KwD6S2yJczlg7nf;
 Sat,  7 May 2022 05:52:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1651895568; bh=acGSKY6SF9orJDwLdOHYr5BmF/C84iQjz+j35hJ2EI8=;
 h=From:To:In-Reply-To:Subject:Date:From;
 b=U/eIjIh1Wh3omKHJsZbZzFU2vN0A3I7W7vc9KEdjKXVpl81zHfWH0Sy2moBuDmwGN
 RPjeQ9L1G9T7w8kyTTFPXN0lx/sBRpFv9+I3n/A6GLMv/e/oDi4ZnpK8JJO9iWCicF
 3hZtouB1lc2UdKqYBop7hRRxOFsCTJTOjB7iO9aM=
Content-Type: text/plain; charset=utf-8
X-Mailer: onet.poczta
X-Priority: 3
X-Onet-Pmq: <vjudeu@gazeta.pl>;5.173.233.66;PL;1
Received: from [5.173.233.66] by mta1.m5r2.onet with HTTP id
 8c1486aa3ecfee37; Sat, 07 May 2022 05:52:48 +0200
From: vjudeu@gazeta.pl
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, =?UTF-8?Q?Jorge_Tim=C3=B3n?=
 <jtimon@jtimon.cc>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <1JO1xrnJ9GwGM4TgLH_rL_LpnZgSb1SyeEOJ9Gzc1VMbKUrmxSh-zUXKwFNvp_5wyiDtRviOf-gRJbrfbhOJl-qym1eEHXpoDAgjE9juucw=@protonmail.com>
Message-ID: <629505ec-81ba-013d-43a0-009d61fada23@gazeta.pl>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 07 May 2022 03:52:48 +0000
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 07 May 2022 08:54:25 +0000
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
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: Sat, 07 May 2022 03:52:57 -0000

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

We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be =
re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means =
"anyone can move those coins", so adding some restrictions is all we need =
to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless =
it will be totally different, but then it should not be named as OP_CAT2, =
but rather as OP_SOMETHING_ELSE, it depends how different it will be from =
OP_CAT.

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

So we can use OP_SUBSTR instead. Maybe =
even OP_SPLIT will be enough, if data expansion is the only problem, then =
we can focus on getting it smaller. Or better, we could use OP_FIND that =
would return true/false answer if element A is a part of element B, when we=
 do byte-to-byte comparison. In general, we can use many different =
string-based functions to do the same things, we can choose something that =
will not exponentially explode as OP_CAT.

> It was considered unfair that =
the sender is paying for the security of the receiver.

It can be changed by using different sighashes, for example, it is possible=
 to create a "negative fee transaction", where all transaction costs are =
paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher=
 amount in outputs than inputs is enough to do that, see testnet3 =
transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf4=
0.

On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev