path: root/f7/9fc9f38719769176704758642b4e2013e323ac

Return-Path: <eth3rs@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C9FC9C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Oct 2023 01:54:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id ACCC7822A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Oct 2023 01:54:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ACCC7822A6
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=C/54VBiM
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 URI_DOTEDU=0.001] autolearn=ham autolearn_force=no
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 s43Y_QLRR1ZK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Oct 2023 01:54:23 +0000 (UTC)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 41B85822A4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Oct 2023 01:54:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 41B85822A4
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-53dd752685fso482380a12.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 25 Oct 2023 18:54:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1698285261; x=1698890061;
 darn=lists.linuxfoundation.org; 
 h=content-transfer-encoding:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=IxyXRqXBDWI0lHk+KDRt8c4479uaLzWOf2qdkuFKABY=;
 b=C/54VBiM/uLPxZPcBemk3fHu/jdn+uHOZxoP4oqXNw5NESlrrCDlzc/yiKI3Ds5Ay6
 mLBCCez+YX6qyTcqnbRRKbfsrqw7qLBmgYBF4xiAZe6Pyz9EqIriw25pBDPtPTEE/Qdz
 qnEkH7rdD0fFvTqVmw60/iaxPfAoJk/11e2SciYiTNadFZ+CD/kScq+LkStHiqtrXPTo
 krlFnJxBZxTw5kYIWlSc0HgXsKJzlPm8bXkGngrhBjvM/7b5zrAZ5Gd3kNKzKJINHXUQ
 aCDBIh6O/33E+Q6JmJNFbwdBim1RCLN5HrlS+vrQsd6tRG6rjxrbKqDudJu74QATSfNC
 VgDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698285261; x=1698890061;
 h=content-transfer-encoding:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=IxyXRqXBDWI0lHk+KDRt8c4479uaLzWOf2qdkuFKABY=;
 b=eIQqpei5+zuLeDReuNusAWOqVc0OpvglEKL9Lrjz+cICs+iD1mjkEjx1mEbgJqckqr
 YVzOudeJ//QhoeuPCTQsDZvdxXg8618stQWfZuJbN4Ad/W1SgxEfBq9/L1BPrc7vI1mN
 Y17WJ4jtqENbl6dXyD2SIVy4GXp7TRP3d+xLNN3HAqO2YbtC3lyNjL7Se28hSIVTHk+T
 C5S7+t11+erv/h3BVfYJzRM5WXMx963LeaF/+FBvwRitCGKYyXCJEpxHmRq0ORlyjaYK
 pa/G7vk+bZnKq9fftoeaTEkSpWQLJOpLxoewpQdPLwE4hDP1UOHOLXvZZhS1A4uQIwqp
 IqSg==
X-Gm-Message-State: AOJu0YzWuKjei4TeNwkQ+FhHoqpwCMBPh6s/01T2av3z/X2l2EUeDOFO
 6lgHuOYg5c+iwxCzEeC+U9zU7OxzGkFYTz8B4VTm+OeoEjs=
X-Google-Smtp-Source: AGHT+IG/UPnk4MwWnATnpYBtvst6W/jUlGC9XWrHncS1Z9X9qtT16C/sxxidxzghoTiDU5Etp+0BdTVQjmEVrxR9BYE=
X-Received: by 2002:a50:cd1e:0:b0:53e:78ed:924d with SMTP id
 z30-20020a50cd1e000000b0053e78ed924dmr13917054edi.5.1698285260944; Wed, 25
 Oct 2023 18:54:20 -0700 (PDT)
MIME-Version: 1.0
References: <194372901-852eeb9299035adb7fdfc7fe5aa21080@pmq3v.m5r2.onet>
 <c76d5c5f-091a-8c41-f1e7-74774c9607c5@roose.io>
In-Reply-To: <c76d5c5f-091a-8c41-f1e7-74774c9607c5@roose.io>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Wed, 25 Oct 2023 21:53:44 -0400
Message-ID: <CAEM=y+X_VL8ZRsVhrcG6ymK=k75MUteZ5c8qxA+LPyCf7LxHpA@mail.gmail.com>
To: Steven Roose <steven@roose.io>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
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: Thu, 26 Oct 2023 01:54:24 -0000

If there is sufficient interest in enabling OP_CAT on Bitcoin and
there is a strong desire in the community for using OP_SUCCESS126
rather than OP_SUCCESS80 then I'd be happy to switch to OP_SUCCESS126.
I don't have any particular affinity for OP_SUCCESS80.

Is there anyone who objects to using OP_SUCCESS126 rather than OP_SUCCESS80=
?

On Tue, Oct 24, 2023 at 4:12=E2=80=AFPM Steven Roose via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I agree that there is no reason not to use OP_SUCCESS126, i.e. the origin=
al OP_CAT opcode 0x7e. In many codebases, for example in Core, there might =
be two OP_CAT constants than which might be confusing.
>
> On 10/22/23 09:58, vjudeu via bitcoin-dev wrote:
>
> > This opcode would be activated via a soft fork by redefining the opcode=
 OP_SUCCESS80.
>
> Why OP_SUCCESS80, and not OP_SUCCESS126? When there is some existing opco=
de, it should be reused. And if OP_RESERVED will ever be re-enabled, I thin=
k it should behave in the same way, as in pre-Taproot, so it should "Mark t=
ransaction as invalid unless occuring in an unexecuted OP_IF branch". Which=
 means, "<condition> OP_VERIFY" should be equivalent to "<condition> OP_NOT=
IF OP_RESERVED OP_ENDIF".
>
>
>
> On 2023-10-21 07:09:13 user Ethan Heilman via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>
> Hi everyone,
>
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>
> OP_CAT was available in early versions of Bitcoin. It was disabled as
> it allowed the construction of a script whose evaluation could create
> stack elements exponential in the size of the script. This is no
> longer an issue in the current age as tapscript enforces a maximum
> stack element size of 520 Bytes.
>
> Thanks,
> Ethan
>
> =3D=3DAbstract=3D=3D
>
> This BIP defines OP_CAT a new tapscript opcode which allows the
> concatenation of two values on the stack. This opcode would be
> activated via a soft fork by redefining the opcode OP_SUCCESS80.
>
> When evaluated the OP_CAT instruction:
> # Pops the top two values off the stack,
> # concatenate the popped values together,
> # and then pushes the concatenated value on the top of the stack.
>
> OP_CAT fails if there are less than two values on the stack or if a
> concatenated value would have a combined size of greater than the
> maximum script element size of 520 Bytes.
>
> =3D=3DMotivation=3D=3D
> Bitcoin tapscript lacks a general purpose way of combining objects on
> the stack restricting the expressiveness and power of tapscript. For
> instance this prevents among many other things the ability to
> construct and evaluate merkle trees and other hashed data structures
> in tapscript. OP_CAT by adding a general purpose way to concatenate
> stack values would overcome this limitation and greatly increase the
> functionality of tapscript.
>
> OP_CAT aims to expand the toolbox of the tapscript developer with a
> simple, modular and useful opcode in the spirit of Unix[1]. To
> demonstrate the usefulness of OP_CAT below we provide a non-exhaustive
> list of some usecases that OP_CAT would enable:
>
> * Tree Signatures provide a multisignature script whose size can be
> logarithmic in the number of public keys and can encode spend
> conditions beyond n-of-m. For instance a transaction less than 1KB in
> size could support tree signatures with a thousand public keys. This
> also enables generalized logical spend conditions. [2]
> * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport
> signatures merely requires the ability to hash and concatenate values
> on the stack. [3]
> * Non-equivocation contracts [4] in tapscript provide a mechanism to
> punish equivocation/double spending in Bitcoin payment channels.
> OP_CAT enables this by enforcing rules on the spending transaction's
> nonce. The capability is a useful building block for payment channels
> and other Bitcoin protocols.
> * Vaults [5] which are a specialized covenant that allows a user to
> block a malicious party who has compromised the user's secret key from
> stealing the funds in that output. As shown in A. Poelstra, "CAT
> and Schnorr Tricks II", 2021,
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html
> OP_CAT is sufficent to build vaults in Bitcoin.
> * Replicating CheckSigFromStack  A. Poelstra, "CAT and Schnorr
> Tricks I", 2021,
> https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
>  which would allow the creation of simple covenants and other
> advanced contracts without having to presign spending transactions,
> possibly reducing complexity and the amount of data that needs to be
> stored. Originally shown to work with Schnorr signatures, this result
> has been extended to ECDSA signatures. [6]
>
> The opcode OP_CAT was available in early versions of Bitcoin. However
> OP_CAT was removed because it enabled the construction of a script for
> which an evaluation could have memory usage exponential in the size of
> the script.
> For instance a script which pushed an 1 Byte value on the stack then
> repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack
> value whose size was greater than 1 Terabyte. This is no longer an
> issue because tapscript enforces a maximum stack element size of 520
> Bytes.
>
> =3D=3DSpecification=3D=3D
>
> Implementation
>
>   if (stack.size() < 2)
>     return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>   valtype vch1 =3D stacktop(-2);
>   valtype vch2 =3D stacktop(-1);
>
>   if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
>       return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>
>   valtype vch3;
>   vch3.reserve(vch1.size() + vch2.size());
>   vch3.insert(vch3.end(), vch1.begin(), vch1.end());
>   vch3.insert(vch3.end(), vch2.begin(), vch2.end());
>
>   popstack(stack);
>   popstack(stack);
>   stack.push_back(vch3);
>
> The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes =3D=3D Reference Implem=
entation =3D=3D [Elements](https://github.com/ElementsProject/elements/blob=
/master/src/script/interpreter.cpp#L1043) =3D=3DReferences=3D=3D [1]: R. Pi=
ke and B. Kernighan, "Program design in the UNIX environment", 1983, https:=
//harmful.cat-v.org/cat-v/unix_prog_design.pdf [2]: P. Wuille, "Multisig on=
 steroids using tree signatures", 2015, https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2021-July/019233.html [3]: J. Rubin, "[bitcoin-dev] OP=
_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Val=
ues]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-J=
uly/019233.html [4]: T. Ruffing, A. Kate, D. Schr=C3=B6der, "Liar, Liar, Co=
ins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://ci=
teseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.727.6262&rep=3Drep1&type=
=3Dpdf [5]: M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://f=
c16.ifca.ai/bitcoin/papers/MES16.pdf [6]: R. Linus, "Covenants with CAT and=
 ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf=
34d5e85#file-covenants_cat_ecdsa-md _______________________________________=
________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> 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