From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 01 Jan 2025 17:24:50 -0800 Received: from mail-yb1-f186.google.com ([209.85.219.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tT9xB-0003l7-Ab for bitcoindev@gnusha.org; Wed, 01 Jan 2025 17:24:50 -0800 Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e5382ab0b41sf379967276.2 for ; Wed, 01 Jan 2025 17:24:48 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1735781083; cv=pass; d=google.com; s=arc-20240605; b=bCEJEhbZVBo179AHhfB5Yix59sNG4dEkBs/Ezmn7PgdFQdTUa6xjHP/vDn3X1JodHg BHD6SdQzSyTXurHnIelPG8uiywXotNjQFeBGeeQzoazyFGTsH2h0rY/nvdWJpYPEXgLm /X8Sz9YwNLnUnkiWygEadCTAbJCVxrYNz/S0WEEK8qs5KAQWmqdiSOKijkJyQlNcz8mI +asI0Q/+ss5MaGWtC93ttfR5+flxq8jatbHZ9i7ELl9xzQHHAr/lZDYFd9g51HF6SnOf sk9EWfGGv75VqbPqrbK9JjzNly6lb1VIj8S0NuYFFgohTLVktRofeaXnSQrs29k8+p5b KMXg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=; fh=GMt1VkO63i7KsAeUbhnNJXmrghg1ivjjInDKv0PonxM=; b=jVlWshqgJBKvYX1J8vxmsEYeBOQnE+4yAxPQccBPhSL4v//zU8J2TXCZaJVkDYg7ws mNW4pmY/aF+1FUfQNOKG0pUSDFMpolbOlk4ILPYCpx5Le6+Az2OL3L0KGd23YBQTEUhD O7vtnTnvB1WPVuHKG9vMkxz0/tRK7CjPFC4ppv0r1nJ6q5tXd91zOo3ytxSwmdS4Yll+ SgVfBykmRJsqosATcM9ltPmrNMJEGdrCOCX/snQP67lOl0JfbuAh02w1RrP4GOJjoqc7 nAR8DHb79kDpLAnLMyQQQndRh2Hmp2uZyxT26PU1Dyaapg4Dcn1VEDhkYYrgwTn4a90L Dpug==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kkcwymkJ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1735781083; x=1736385883; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=; b=hv6HCH5DtFBMh0oQsF+juivV2v65iLZZUDO8BwiiBMVdPwshgGvYTYxWAv7DZ2R/li nY0bpqsEtoequ4g5Zx8uQfN6dGFUpQuET/Ll6quee/ngVnUDD2VR9iP5iVuqbqLrnGW6 xkKhkXGBfX4ZgjJNkouuPfTVJhcDpLDAoKnQpyvQKOwzYNgoA6bzvPXd7oYtD+A6Y4rm oy5gNWYGaN9rj5uiOaLzbJWRumyuHzG5rTyvqB9Cl40TOZvQeuKptIVoIiiKEh7s7owI v7OK1ydRoAJhG/wUGBs2/7v02aIdqqiPuBbxmrn0PddbNWTcR1OZ9K08wX+nDI44zauH c6Xg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735781083; x=1736385883; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=; b=S5/eeR9XBzFcMZhCf8/ZOZOZnh4r+PkkchiTd8lDb88ArFrNq1qD4Gg867FghdmsL6 lbt//SKhRmRHLSFvfv5iWVB3Tdsn1YFXX70fDcmp0vA5Z/00mbPvK5+G5vNSpOagan3z +F08q9npsfS9il8KLpjm+FasGlJ5N0X1brILaB2NjFuUhx4Jh38H97xvd32r0TQQV+7A WzKMx5t631JFgS3PDTr5+jnWiTcN47RC+neZvIIi0p2++8HR0BAlRW3eLu4Fzv2XZjd5 OqU15ONH8ourWZ+WzsmmD32Ql+7mKgLHKLr28aQnrvTx6VAdHlCEPtPkUu3wbTiKUU/D EtNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735781083; x=1736385883; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=UEIqKn5dlcccoC9Upyi3RDkTb+Q5wG1GvrPrUimvBOk=; b=Lom26NrHvKLc2CBsQxsblachU2B9CBtiFvC68rtRNC449J61VZuG/Semu8BkG8XLvx bIikxYakIWXgJHnJusGTsbLlQLCf2qepSoe3NFYhfceSIyHY1Px2tvG4MDLZiioarenP Nm5tdBUiqd/m4MuNLbT4zJ6h3wJMoZYJ9YfIegYh3jzwDZKEocI1Hx21VU+welmpNdUi jFUrLF2e70NNybG5UrfE7Kro7CFJhUXtrhjQj9rS928Etw+rXXtrzqCNb+mNMmaL+XHY DigWIiCrx/CjcvbBwTAZT+lc21UVsvr7LoXHG+o3xP3ZijWHd8dJdRFNCP9tQSmNp9AI IyQw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCW/eHklDlhRIyPikZ/0HiXMttjsxS4uZlqr9OEnKoU2yYGkYhxbrgJdWBmipzeCLvzfiyU5qxEMzyxv@gnusha.org X-Gm-Message-State: AOJu0YygC6WWcLjk/tIdTdrL8MkhrvDk+PwZKDMkeIOKo1fgalwuzrOO od6z+QwsQXOcT61yuqBTxbFh+2vje48/37gRBpFZk9uoFfH26yQi X-Google-Smtp-Source: AGHT+IHlxAl7Vktn0zU41MPioLSRzhnB7SO4IaFA+31fIogJOmf2Wd2hLyT6s0gf+qHMkg23xkL3fQ== X-Received: by 2002:a05:6902:248e:b0:e4a:8132:26b3 with SMTP id 3f1490d57ef6-e538c40e1a7mr30301846276.47.1735781082653; Wed, 01 Jan 2025 17:24:42 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:aa69:0:b0:e48:25c2:a5d7 with SMTP id 3f1490d57ef6-e5411996a94ls2990495276.0.-pod-prod-06-us; Wed, 01 Jan 2025 17:24:40 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUyQdIihQiLgVUYZdZOBsM7TzPYRdmowIDpJnyPNDDJBAcMncPT8bgcIQFWaFuwm+D5IfDbiGLzwgFv@googlegroups.com X-Received: by 2002:a05:690c:6407:b0:6ef:4e42:64d0 with SMTP id 00721157ae682-6f3f81253d5mr254406717b3.11.1735781079897; Wed, 01 Jan 2025 17:24:39 -0800 (PST) Received: by 2002:a05:690c:951:b0:6ef:b1a3:15f0 with SMTP id 00721157ae682-6f3f552f45fms7b3; Wed, 1 Jan 2025 17:23:20 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWn7TWjaOAGRewKoVAptnwH8BV08eiQb9sp+EcLcVPoh55B6CavNFvPRBq/1RouhXr46mYnEGk+KGVM@googlegroups.com X-Received: by 2002:a05:6902:2610:b0:e4a:fc25:30cb with SMTP id 3f1490d57ef6-e538c40c90amr30928530276.46.1735780999474; Wed, 01 Jan 2025 17:23:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1735780999; cv=none; d=google.com; s=arc-20240605; b=ZnZT4WpmE1B0R3s4478itwvtrZezZjLkR3moQWdCizXvKp1W4zoG8zp/xyHpX2hPaE Eu2Q7x3edF1MOAgVIZfLonAM65hFVqxOJEkUHvnJZ5TUgAjC/wF9yU79SvDWc6bd8eiB phnQHxXDjO06iG9Fl0mSipNfENFQKaDY83e8phI0IwAG2BClm1lDSa8uW/hiOY0yVPZa IloNuo+O5FKMXQqfkm3G/76fR91iHili+8mnIu91Ev3Dk9N2oxS0BW4kP2ez2zCtAEhE xTgYvfFvNwIK2bL/U3ZCsCdfTRLUQHgPJCHOAXHH7gK/xl2KNEhsByyONEZJAsyjM0v9 vTjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=PQGXIn1YFjxjLYo5+2iuY1cuME9ULKy6D+7DIPghF/s=; fh=IEg/iXUBTFPwmhcumGuuPv+LgOJa1X9ae1fKQ33VqzQ=; b=WBWRsqlmApcsMDQiLTOVq00Qc0cQqfFVj3UY4qXuAsYUoyEpUvxSAmkvcd711KoJNV Wfl4ZadvNwQ3BcBvuPt4de7X1qe2VJSUylhVihgHuok89KS0pONNyWcv9+L7IfF0eh9I +zmyUBk0NzxlKl1mZt6xT3gWJf9hsRxMBFZDoDQ+X2cvh2gKLTMogKY752SkhR8i2/k+ RxXxkR073BYXiU8FSRCQ2AO9xww1kpqGwzKFcuBwWjPU0DScDQffUwHLil7FktJGtZhq 6oL72ULdQgj1nZwEUluRsRGPXln8FrMs7gHkD2k1cxdrJIKoxljcvv3EfF0mg87VOY1z M3gQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kkcwymkJ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com. [2607:f8b0:4864:20::c31]) by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e537cc20c65si1019341276.1.2025.01.01.17.23.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jan 2025 17:23:19 -0800 (PST) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) client-ip=2607:f8b0:4864:20::c31; Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-5f2d5b3c094so2120894eaf.1 for ; Wed, 01 Jan 2025 17:23:19 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVe8TO2x8AmWUlx+F+QExjiRObvyWtWBnFYELgykoqJwuYA9Q0j5gi5cntrwrrUM85TATAJAELi+pxU@googlegroups.com X-Gm-Gg: ASbGnctO3pT4AesPG0JmKdDg+3ZF1Qz0ue70xVxxKi2BRVCvl5CM+LCGl4gXQFag3w2 EFclvCCYQLbAwOoH6DUl6r1HA+8JHxLuaJRlcF70D X-Received: by 2002:a05:6870:3921:b0:297:241b:1471 with SMTP id 586e51a60fabf-2a7fb4181d6mr24888164fac.41.1735780997374; Wed, 01 Jan 2025 17:23:17 -0800 (PST) MIME-Version: 1.0 References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> In-Reply-To: From: "/dev /fd0" Date: Thu, 2 Jan 2025 06:52:58 +0530 Message-ID: Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki To: Ethan Heilman Cc: moonsettler , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000c1ad61062aaf01c5" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kkcwymkJ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c31 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --000000000000c1ad61062aaf01c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ethan, OP_CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP_PAIRCOMMIT is a part of LNHANCE. In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN SYMMETRY can be achieved with other opcodes. Note: The objections shared in this thread are a summarised version of all the rationales and not my person opinion. /dev/fd0 floppy disk guy On Wed, Jan 1, 2025, 11:49 PM Ethan Heilman wrote: > One of the CAT authors here > > > > [PAIR_COMMIT] Adds unnecessary complexity > > That's a subjective value judgement it enables something that was no > possible before which is interacting with Merkle trees and multi-element > commitments in script. PAIRCOMMIT is not significantly more complicated > than CAT, and in a lot of actual use cases CAT was desired for it's more > complex and resource intensive to safely use CAT than PAIRCOMMIT due to > witness malleability. > > PAIR_COMMIT (BIP-442) for all intents and purposes is as simple in > implementation at CAT (BIP-347). I have no technical objection to > PAIRCOMMIT and it provides much needed functionality. > > My primary concern is not PAIRCOMMIT itself, but the rationale for > PAIRCOMMIT. > > The rationale for PAIRCOMMIT rests on the assumption that the Bitcoin > community does not want the expressiveness of CAT. If we assume this > is the case, then we should be very careful PAIRCOMMIT does not enable > this expressiveness as well. On the other hand, if the Bitcoin > community does want the expressiveness of CAT, then we should merge > CAT. PAIRCOMMIT is well designed to be less expressive than CAT and it > is likely that you can not simulate CAT with PAIRCOMMIT. That said, I > am not convinced it is impossible that there is no way to simulate CAT > with PAIRCOMMIT, nor I do feel confident that I know how much less > powerful PAIRCOMMIT is than CAT. > > Playing devil's advocate for a second, if I was opposed to CAT on > grounds that we should limit expressiveness I would want to really > understand the limits of PAIRCOMMIT. For instance can you do arbitrary > computation by building STARKs with PAIRCOMMIT merkle trees? If not, > why not? > > That said, I have not heard any argument against PAIRCOMMIT from those > against CAT, so perhaps they are comfortable with it. > > Since I am in favor of CAT, I am also in favor of PAIRCOMMIT. > > On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler' via Bitcoin Develop= ment > Mailing List wrote: > > > > Hi All, > > > > One thing I would like to make clear before people get the wrong idea > and think this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is > part of LNhance and will be part of the activation client we release soon= . > The only way to change that is to demonstrate actual harm. You liking > something else more, is your problem. What you can do about it, is write > your activation client and try to gain consensus on that. There are plent= y > of version bits available. Replacing PAIRCOMMIT with CAT would be really > easy, but while CAT is indeed very popular and has a wide support base it > is also strongly opposed by many who did not choose to participate. I'm n= ot > convinced that this table represents actual developer, let alone ecosyste= m > consensus. If you decide you want to run an alternative activation effort > with CAT instead of PAIRCOMMIT feel free to fork our repo! > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > OP_PARCOMMIT > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > OP_PARCOMMIT seems to be controversial at this moment. > > > > I strongly disagree. In my book that's not what controversial means. > Literally nobody managed to come up with a single use case anyone worth > noting objects to for PAIRCOMMIT. Also inclined to ignore the "No" from > those that prefer CAT as plain trolling. This BIP is young, there is a > clear correlation between the age of the proposals and their support with > the sole exception of APO. > > > > > Adds unnecessary complexity > > > > That's a subjective value judgement it enables something that was no > possible before which is interacting with Merkle trees and multi-element > commitments in script. PAIRCOMMIT is not significantly more complicated > than CAT, and in a lot of actual use cases CAT was desired for it's more > complex and resource intensive to safely use CAT than PAIRCOMMIT due to > witness malleability. > > > > > Not convinced it is impossible that there is no way to simulate CAT > with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than > CAT. > > > > This is sufficiently addressed in the BIP. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > OP_VAULT > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > No demand for vaults. > > > > It's safe to completely ignore that "argument". > > > > BR, > > moonsettler > > > > > > On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 < > alicexbtong@gmail.com> wrote: > > > > > Hi Bitcoin Developers, > > > > > > I had shared covenants support wiki page link here on [mailing > list][1] in the last week of November 2024. Multiple changes were made > based on the feedback: > > > > > > - Removed 'community support' from 'No'. Rephrased definitions for > 'Prefer' and 'Evaluating'. > > > - Added LNHANCE category for a combination of opcodes. > > > - Added links for BIP drafts and a column for 'rationale'. > > > - Created a separate table for evaluations without a rationale. > > > > > > Murch and Gloria shared their feedback in the bitcoin optech [podcast > 333][2]. I have started working on a [page][3] that lists use cases, > prototype links and primitives used. We can still add more use cases in i= t. > This list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] > alone or in combination with other opcodes like [LN SYMMETRY][5]. > > > > > > I had verified each entry to avoid spam and fake evaluations. Rearden > was assigned moderator permissions on 8 December 2024 by Theymos to help = me > with the moderations. Some edits have been approved by other moderators. > > > > > > Some insights from the table that could help developers working on > different covenant proposals: > > > > > > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO > lacks interest among developers, contrary to the belief prior to this > exercise. > > > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of > multiple covenant proposals. > > > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not > reviewed by enough developers. OP_PARCOMMIT seems to be controversial at > this moment. > > > > > > Objections: > > > > > > ``` > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > SIGHASH_APO > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > LN SYMMETRY is possible with combination of a few opcodes which is > more efficient. Its not the best option for covenants and cannot be used = to > improve Ark. Some developers prefer opcodes and not sighash flags. > > > > > > Seems to be the result of an attempt to fix signatures to make them > work for a specific use-case, but the end-result is hard-to-reason (for m= e) > and not flexible. In general, SIGHASH flags are an encoding of specific > predicates on the transaction, and I think the Script is better suited to > carry the predicate. There is no interesting SIGHASH flag that couldn't b= e > functionally simulated by introspection + CHECKSIGFROMSTACK (or other > Script-based approaches), and that seems to me a much cleaner and ergonom= ic > way to achieve the same goals. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_TXHASH > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > More expressive, many flag configurations, untested and undesirable > use cases. Unaddressed comments in the BIP and the delay doesn't make sen= se > because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same > thing. Makes hash caching complex, potentially opening up DoS vectors or > quadratic sighash. > > > > > > Most templates you'd obtain with various combinations of parameters > are meaningless. It implements state-carrying UTXOs in a very dirty way: > adding additional inputs/outputs with no other meaning than "storing some > state". This is ugly, inefficient, and bloats the UTXO set - and it > definitely will happen if TXHASH is enabled without also enabling a clean > way to carry state. > > > > > > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune it > to what people are actually using covenants for, instead of prematurely > optimizing everything with no data. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_VAULT > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > No demand for vaults. Customized for a specific use case. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_CAT > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Can be used for various complex scripts including undesirable use > cases (DEX, AMM and Hashrate Escrow). Enables granular transaction > introspection through abuse of schnorr signatures and OP_CHECKSIG. Can be > used for interesting use cases but alone does it poorly and inefficiently= . > > > > > > People can and will litter the chain with inefficient/ugly Scripts if > activated alone. Since it happens to enable generic introspection by > accident, and therefore an ugly version of state-carrying UTXOs, it > shouldn't be enabled without more ergonomic opcodes for those use cases. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_INTERNALKEY > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > There are 3 'No' in the table, I couldn't find anything relevant in > the rationales. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_PAIRCOMMIT > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Adds unnecessary complexity, redundant if OP_CAT is activated in > future and added for specific use case. LN SYMMETRY is possible without > this opcode. It does not compose with anything that involves transaction > introspection due to its specified tagged hash. Some developers prefer > OP_CAT. > > > > > > Not convinced it is impossible that there is no way to simulate CAT > with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than > CAT. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > OP_CHECKTEMPLATEVERIFY > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Limited in scope and not recursive. > > > ``` > > > > > > I have tried my best to remain unbiased in writing this summary and > approving edits. There are a few things that I want to share and it could > be a result of the aggressive marketing: > > > > > > - A spammer had edited the table to remove all evaluations except in > favor of OP_CAT and it was rejected. > > > - [Rationale][6] added by Aaron (sCrypt) does not mention anything > about other opcodes and SIGHASH_APO. It is only focused on OP_CAT however > evaluations exist in the table. > > > - I [requested][7] Udev (CatSwap) to add details about evaluation of > other opcodes and SIGHASH_APO. > > > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with > incorrect signet stats and seems to be rephrased version of another > rationale. Evaluation had 'weak' for OP_CTV before adding the rationale. > > > - An edit with duplicate rationale (in support of OP_CAT) was rejecte= d > because sharing the link for a rationale submitted by other developer add= s > no value in the table. > > > > > > Evaluations without a rationale have some 'No' in different cells. > Although none of them are backed by a rationale so cannot be considered f= or > consensus discussion. The table is still updated regularly so you may see > some of them with a rationale in 2025. Any suggestions to help achieve > technical consensus are most welcome. > > > > > > What's next? > > > > > > - More rationales in the table > > > - Discuss objections on mailing list (if any) > > > - Workshops > > > - Add a table for economic nodes and their opinion > > > - Build activation client and discuss parameters > > > > > > Finally, I would thank all the developers who added their evaluations > in the table and everyone who shared updates on twitter. It was a > coordinated effort to reach some technical consensus. You can read all th= e > rationales in detail to understand different perspectives and reasons to > support a combination of opcodes over others. > > > > > > [1]: > https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ > > > [2]: https://bitcoinops.org/en/podcast/2024/12/17/ > > > [3]: https://en.bitcoin.it/wiki/Covenants_Uses > > > [4]: https://github.com/bitcoin/bips/blob/master/bip-0348.md > > > [5]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7 > > > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9 > > > [7]: > https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?permali= nk_comment_id=3D5359072#gistcomment-5359072 > > > [8]: > https://en.bitcoin.it/w/index.php?title=3DCovenants_support&diff=3Dprev&o= ldid=3D70520 > > > > > > /dev/fd0 > > > floppy disk guy > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d > an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a4= 2a9a9007n%40googlegroups.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to bitcoindev+unsubscribe@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmc= uQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frB= WXac%3D%40protonmail.com > . > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1= HfaFsB3kXg-LbtppyZG0xjAa7DBaA%40mail.gmail.com > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA%40mail.gmail.com. --000000000000c1ad61062aaf01c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ethan,

OP= _CAT is not proposed as an opcode to enable LN SYMMETRY. Whereas OP_PAIRCOM= MIT is a part of LNHANCE.

In this context, OP_PAIRCOMMIT adds unnecessary complexity because LN SYM= METRY can be achieved with other opcodes.

=
Note: The objections shared in this thread are a summaris= ed version of all the rationales and not my person opinion.

/dev/fd0
flopp= y disk guy

=
On Wed, Jan 1, 2025, 11:49 PM Ethan H= eilman <eth3rs@gmail.com> wro= te:
One of the CAT authors here

> > [PAIR_COMMIT] Adds unnecessary complexity
> That's a subjective value judgement it enables something that was = no possible before which is interacting with Merkle trees and multi-element= commitments in script. PAIRCOMMIT is not significantly more complicated th= an CAT, and in a lot of actual use cases CAT was desired for it's more = complex and resource intensive to safely use CAT than PAIRCOMMIT due to wit= ness malleability.

PAIR_COMMIT (BIP-442) for all intents and purposes is as simple in
implementation at CAT (BIP-347). I have no technical objection to
PAIRCOMMIT and it provides much needed functionality.

My primary concern is not PAIRCOMMIT itself, but the rationale for PAIRCOMM= IT.

The rationale for PAIRCOMMIT rests on the assumption that the Bitcoin
community does not want the expressiveness of CAT. If we assume this
is the case, then we should be very careful PAIRCOMMIT does not enable
this expressiveness as well. On the other hand, if the Bitcoin
community does want the expressiveness of CAT, then we should merge
CAT. PAIRCOMMIT is well designed to be less expressive than CAT and it
is likely that you can not simulate CAT with PAIRCOMMIT. That said, I
am not convinced it is impossible that there is no way to simulate CAT
with PAIRCOMMIT, nor I do feel confident that I know how much less
powerful PAIRCOMMIT is than CAT.

Playing devil's advocate for a second, if I was opposed to CAT on
grounds that we should limit expressiveness I would want to really
understand the limits of PAIRCOMMIT. For instance can you do arbitrary
computation by building STARKs with PAIRCOMMIT merkle trees? If not,
why not?

That said, I have not heard any argument against PAIRCOMMIT from those
against CAT, so perhaps they are comfortable with it.

Since I am in favor of CAT, I am also in favor of PAIRCOMMIT.

On Tue, Dec 31, 2024 at 9:23=E2=80=AFAM 'moonsettler' via Bitcoin D= evelopment
Mailing List <bitcoindev@googlegroups.com> wrote:
>
> Hi All,
>
> One thing I would like to make clear before people get the wrong idea = and think this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is p= art of LNhance and will be part of the activation client we release soon. T= he only way to change that is to demonstrate actual harm. You liking someth= ing else more, is your problem. What you can do about it, is write your act= ivation client and try to gain consensus on that. There are plenty of versi= on bits available. Replacing PAIRCOMMIT with CAT would be really easy, but = while CAT is indeed very popular and has a wide support base it is also str= ongly opposed by many who did not choose to participate. I'm not convin= ced that this table represents actual developer, let alone ecosystem consen= sus. If you decide you want to run an alternative activation effort with CA= T instead of PAIRCOMMIT feel free to fork our repo!
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> OP_PARCOMMIT
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> > OP_PARCOMMIT seems to be controversial at this moment.
>
> I strongly disagree. In my book that's not what controversial mean= s. Literally nobody managed to come up with a single use case anyone worth = noting objects to for PAIRCOMMIT. Also inclined to ignore the "No"= ; from those that prefer CAT as plain trolling. This BIP is young, there is= a clear correlation between the age of the proposals and their support wit= h the sole exception of APO.
>
> > Adds unnecessary complexity
>
> That's a subjective value judgement it enables something that was = no possible before which is interacting with Merkle trees and multi-element= commitments in script. PAIRCOMMIT is not significantly more complicated th= an CAT, and in a lot of actual use cases CAT was desired for it's more = complex and resource intensive to safely use CAT than PAIRCOMMIT due to wit= ness malleability.
>
> > Not convinced it is impossible that there is no way to simulate C= AT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than= CAT.
>
> This is sufficiently addressed in the BIP.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> OP_VAULT
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> > No demand for vaults.
>
> It's safe to completely ignore that "argument".
>
> BR,
> moonsettler
>
>
> On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 <alicexbto= ng@gmail.com> wrote:
>
> > Hi Bitcoin Developers,
> >
> > I had shared covenants support wiki page link here on [mailing li= st][1] in the last week of November 2024. Multiple changes were made based = on the feedback:
> >
> > - Removed 'community support' from 'No'. Rephrase= d definitions for 'Prefer' and 'Evaluating'.
> > - Added LNHANCE category for a combination of opcodes.
> > - Added links for BIP drafts and a column for 'rationale'= .
> > - Created a separate table for evaluations without a rationale. > >
> > Murch and Gloria shared their feedback in the bitcoin optech [pod= cast 333][2]. I have started working on a [page][3] that lists use cases, p= rototype links and primitives used. We can still add more use cases in it. = This list does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] a= lone or in combination with other opcodes like [LN SYMMETRY][5].
> >
> > I had verified each entry to avoid spam and fake evaluations. Rea= rden was assigned moderator permissions on 8 December 2024 by Theymos to he= lp me with the moderations. Some edits have been approved by other moderato= rs.
> >
> > Some insights from the table that could help developers working o= n different covenant proposals:
> >
> > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_= APO lacks interest among developers, contrary to the belief prior to this e= xercise.
> > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of mu= ltiple covenant proposals.
> > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are n= ot reviewed by enough developers. OP_PARCOMMIT seems to be controversial at= this moment.
> >
> > Objections:
> >
> > ```
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > SIGHASH_APO
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > LN SYMMETRY is possible with combination of a few opcodes which i= s more efficient. Its not the best option for covenants and cannot be used = to improve Ark. Some developers prefer opcodes and not sighash flags.
> >
> > Seems to be the result of an attempt to fix signatures to make th= em work for a specific use-case, but the end-result is hard-to-reason (for = me) and not flexible. In general, SIGHASH flags are an encoding of specific= predicates on the transaction, and I think the Script is better suited to = carry the predicate. There is no interesting SIGHASH flag that couldn't= be functionally simulated by introspection + CHECKSIGFROMSTACK (or other S= cript-based approaches), and that seems to me a much cleaner and ergonomic = way to achieve the same goals.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > OP_TXHASH
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > More expressive, many flag configurations, untested and undesirab= le use cases. Unaddressed comments in the BIP and the delay doesn't mak= e sense because OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the= same thing. Makes hash caching complex, potentially opening up DoS vectors= or quadratic sighash.
> >
> > Most templates you'd obtain with various combinations of para= meters are meaningless. It implements state-carrying UTXOs in a very dirty = way: adding additional inputs/outputs with no other meaning than "stor= ing some state". This is ugly, inefficient, and bloats the UTXO set - = and it definitely will happen if TXHASH is enabled without also enabling a = clean way to carry state.
> >
> > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune= it to what people are actually using covenants for, instead of prematurely= optimizing everything with no data.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > OP_VAULT
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > No demand for vaults. Customized for a specific use case.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > OP_CAT
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > Can be used for various complex scripts including undesirable use= cases (DEX, AMM and Hashrate Escrow). Enables granular transaction introsp= ection through abuse of schnorr signatures and OP_CHECKSIG. Can be used for= interesting use cases but alone does it poorly and inefficiently.
> >
> > People can and will litter the chain with inefficient/ugly Script= s if activated alone. Since it happens to enable generic introspection by a= ccident, and therefore an ugly version of state-carrying UTXOs, it shouldn&= #39;t be enabled without more ergonomic opcodes for those use cases.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > OP_INTERNALKEY
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > There are 3 'No' in the table, I couldn't find anythi= ng relevant in the rationales.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > OP_PAIRCOMMIT
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > Adds unnecessary complexity, redundant if OP_CAT is activated in = future and added for specific use case. LN SYMMETRY is possible without thi= s opcode. It does not compose with anything that involves transaction intro= spection due to its specified tagged hash. Some developers prefer OP_CAT. > >
> > Not convinced it is impossible that there is no way to simulate C= AT with PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than= CAT.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> > OP_CHECKTEMPLATEVERIFY
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> >
> > Limited in scope and not recursive.
> > ```
> >
> > I have tried my best to remain unbiased in writing this summary a= nd approving edits. There are a few things that I want to share and it coul= d be a result of the aggressive marketing:
> >
> > - A spammer had edited the table to remove all evaluations except= in favor of OP_CAT and it was rejected.
> > - [Rationale][6] added by Aaron (sCrypt) does not mention anythin= g about other opcodes and SIGHASH_APO. It is only focused on OP_CAT however= evaluations exist in the table.
> > - I [requested][7] Udev (CatSwap) to add details about evaluation= of other opcodes and SIGHASH_APO.
> > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with inc= orrect signet stats and seems to be rephrased version of another rationale.= Evaluation had 'weak' for OP_CTV before adding the rationale.
> > - An edit with duplicate rationale (in support of OP_CAT) was rej= ected because sharing the link for a rationale submitted by other developer= adds no value in the table.
> >
> > Evaluations without a rationale have some 'No' in differe= nt cells. Although none of them are backed by a rationale so cannot be cons= idered for consensus discussion. The table is still updated regularly so yo= u may see some of them with a rationale in 2025. Any suggestions to help ac= hieve technical consensus are most welcome.
> >
> > What's next?
> >
> > - More rationales in the table
> > - Discuss objections on mailing list (if any)
> > - Workshops
> > - Add a table for economic nodes and their opinion
> > - Build activation client and discuss parameters
> >
> > Finally, I would thank all the developers who added their evaluat= ions in the table and everyone who shared updates on twitter. It was a coor= dinated effort to reach some technical consensus. You can read all the rati= onales in detail to understand different perspectives and reasons to suppor= t a combination of opcodes over others.
> >
> > [1]: https:/= /groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ
> > [2]: https://bitcoinops.org/en/pod= cast/2024/12/17/
> > [3]: https://en.bitcoin.it/wiki/Covena= nts_Uses
> > [4]: https://github.com/= bitcoin/bips/blob/master/bip-0348.md
> > [5]: https://gis= t.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7
> > [6]: https://gi= st.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9
> > [7]: https://gist.github.com/udevswap/= b768d20d62549922b9e72428ef9eb608?permalink_comment_id=3D5359072#gistcomment= -5359072
> > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_supp= ort&diff=3Dprev&oldid=3D70520
> >
> > /dev/fd0
> > floppy disk guy
> >
> > --
> > You received this message because you are subscribed to the Googl= e Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it,= send an email to bitcoindev+unsubscribe@googlegroup= s.com.
> > To view this discussion visit https://groups.google.c= om/d/msgid/bitcoindev/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.= com.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+unsubscribe@googlegroups.com= .
> To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q= 3bMzIH0-QzfFtzC6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com.
--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.=
To view this discussion visit https://groups.= google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV9Gu0n7pLv1d%2BK1HfaFsB3kXg-Lbtppy= ZG0xjAa7DBaA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/CALiT-ZrqiXfOye8JvVgqvswhNHugFXZmYUgKqRijGXk_1kJFDA%40mail.g= mail.com.
--000000000000c1ad61062aaf01c5--