Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2C923C002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion In-Reply-To: Date: Wed, 11 May 2022 18:03:25 +0200 Message-Id: <161249063-43e0faa99d531e0f159a89feef8a592b@pmq5v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 OP_EQUALVERIFY OP_CHECKSIG The P2SH template would be: OP_DUP OP_HASH160 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