path: root/3c/3b420aaac603c6cdeba673a795e23f3d745a33

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2C923C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 16:03:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 23AF183E56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 16:03:36 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
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 BN0v7Top50mw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 16:03:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo104.poczta.onet.pl (smtpo104.poczta.onet.pl
 [213.180.149.157])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5A4B483E55
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 16:03:34 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4Kz07d5682zmK9;
 Wed, 11 May 2022 18:03:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1652285005; bh=fZwePO9Z5CYuJ+0HswIwuMmdkK1BnPWuFywPJh1RG8o=;
 h=From:Cc:To:In-Reply-To:Date:Subject:From;
 b=vhmnMUrI1TDLY5b+8g0/amUzIu6r1m7HXZwgk0Goh8GofvxwOKxz+HzSVHTejjEF8
 TgOEbJk4HLCWgacZ1214fPIzmCdgRf1PFsT9PfPsEvUUdGkv57h53jnTefKlXebiJW
 Lu82DVuZgykPr4dqFbwRLUqTMFwJFwsUJaiFBhqE=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.224.255] by pmq5v.m5r2.onet via HTTP id ;
 Wed, 11 May 2022 18:03:25 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: alicexbt <alicexbt@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <b4X11F5edHpTf3LtKIQ53TOvUYP7l4AS689gAveWrDpfoeCC_5X8GzxoN8esnd0InoC4gAP46OX-YhxQoBp6nVfolMpNRkkk4DGqoLH2VDg=@protonmail.com>
Date: Wed, 11 May 2022 18:03:25 +0200
Message-Id: <161249063-43e0faa99d531e0f159a89feef8a592b@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.224.255;PL;4
X-Mailman-Approved-At: Wed, 11 May 2022 16:37:05 +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: Wed, 11 May 2022 16:03:36 -0000

> This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 + 0=
.00073 =3D 0.00147) which is more than output amount 0.001 tBTC

It was created without the second input, see: https://bitcointalk.org/index=
.php?topic=3D5390103.msg59616324#msg59616324
I didn't touch that later, the signatures are the same. Some user named coi=
nlatte just completed it: https://bitcointalk.org/index.php?topic=3D5390103=
.msg60029953#msg60029953


On 2022-05-11 17:25:41 user alicexbt <alicexbt@protonmail.com> wrote:

Hi vjudeu,

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


This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 +=C2=
=A00.00073 =3D 0.00147)=C2=A0which is more than output amount 0.001 tBTC


/dev/fd0





Sent with ProtonMail secure email.

------- Original Message -------
On Saturday, May 7th, 2022 at 9:22 AM, vjudeu via bitcoin-dev bitcoin-dev@l=
ists.linuxfoundation.org wrote:







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-e=
nabled in a soft-fork way. For now, OP_CAT in TapScript simply means "anyon=
e can move those coins", so adding some restrictions is all we need to re-e=
nable 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 rath=
er 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 dat=
a expansion is the only problem, then we can focus on getting it smaller. O=
r better, we could use OP_FIND that would return true/false answer if eleme=
nt 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, w=
e 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 pa=
id by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher a=
mount in outputs than inputs is enough to do that, see testnet3 transaction=
 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.

On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linu=
xfoundation.org wrote:

Good morning Jorge,

OP_CAT was removed. If I remember correctly, some speculated that perhaps i=
t was removed because it could allow covenants.I don't remember any technic=
al concern about the OP besides enabling covenants.Before it was a common o=
pinion that covenants shouldn't be enabled in bitcoin because, despite havi=
ng good use case, there are some nasty attacks that are enabled with them t=
oo. These days it seems the opinion of the benefits being worth the dangers=
 is quite generalized. Which is quite understandable given that more use ca=
ses have been thought since then.

I think the more accurate reason for why it was removed is because the foll=
owing 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 si=
milar behavior (consider that multiplying two 32-bit numbers results in a 6=
4-bit number, similar to OP_CATting a vector to itself).

OP_CAT was removed long before covenants were even expressed as a possibili=
ty.

Covenants were first expressed as a possibility, I believe, during discussi=
ons 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 scriptPub=
Key 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 th=
e receiver.

Thus, OP_EVAL and the P2SH concept was conceived.
Instead of the scriptPubKey containing the k-of-n multisignature, you creat=
e a separate script containing the public keys, then hash it, and the scrip=
tPubKey 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 SCRI=
PTs by quining using OP_CAT.
OP_CAT was already disabled by then, but people were talking about re-enabl=
ing 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 si=
ze, because recursive covenants).
In particular, OP_CAT in combination with OP_CHECKSIGFROMSTACK and OP_CHECK=
SIG, 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 actual=
ly enabled.

(OP_EVAL cannot replace an OP_NOP in a softfork, but it is helpful to remem=
ber 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 see=
med) 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, crea=
ting a new P2WSHv2 (or whatever version) that enables these opcodes.

As far a I know, this is the covenants proposal that has been implemented f=
or the longest time, if that's to be used as a selection criteria.And as al=
ways, this is not incompatible with deploying other convenant proposals lat=
er.

No, it was OP_EVAL, not OP_CAT.
In particular if OP_EVAL was allowed in the redeemScript then it would enab=
le covenants as well.
It was just pointed out that OP_CAT enables recursive covenenats in combina=
tion with OP_EVAL-in-redeemScript.

In particular, in combination with OP_CAT, OP_EVAL not only allows recursiv=
e covenants, but also recursion within a SCRIPT i.e. unbounded SCRIPT execu=
tion.
Thus, OP_EVAL is simply not going to fly, at all.

Personally I find the simplicity proposal the best one among all the covena=
nt proposals by far, including this one.But I understand that despite the n=
ame, 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 simpl=
er and has been implemented for longer, so in principle, it should be easie=
r to deploy in a speedy manner.

What are the main arguments against speedy covenants (aka op_cat2) and agai=
nst 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev