From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 05 Mar 2025 10:16:09 -0800 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tptHs-00056w-Is for bitcoindev@gnusha.org; Wed, 05 Mar 2025 10:16:09 -0800 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-5fcc968a757sf5457666eaf.2 for ; Wed, 05 Mar 2025 10:16:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1741198563; cv=pass; d=google.com; s=arc-20240605; b=coewMRv9mqZEp8Mm5G1LJa1X/rFqlPZjn4rnr12tJ1N26OZR9OV7oWgP51y0Zt4abo sA8yNsDCUQKrmtC345OBwSmLif4okPQ7SzFTNgfLFmkDX8V/S5XIy6wD85I3qMpKhRKF ybzE44aZ4i1Y7Uxt+yM1q1paktBUdlyBXZEDS51S1HmOeWtdptj9fnE/zeXaAPiBARrE fw6tImx87yLHyPUR5Mr/S7HRdc3Q7V/mwrFCJdavl2zLrkj3BwatucB7P6REfgF+xBXA 2B0iwZm0h85BtpJHgYQfLVuHHAdPa1SY0aioruKp4KR+fJ0h/6LylNNQ1W0EZsPQyWzM G/2g== 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=fs2XiVNnHYAkD3DO9+aoO+E7shltdmvc8ZIY6rs9JHw=; fh=c/L4u6GyTRNHu92I7Ii29gK2EO4PfLYJ1XZT/1plHi0=; b=RpEwlRBZ0EjYPpA08RQyG//cyynZFqLWDuVYcA1u1HzpQLlsGOdNKbFTHO3lDp7pti D/UdlMVn+aOeJOg/L8DiUbVmoXNs/uFpk1py51J2+1p4ytbj8Z23DuLMoln+SJ4Abbt4 OM0jGt8MQFUP/IgrQ94Q74hI98c+3WUZvCyVBJk9gr0pd3eqmISijfkQJeMniNIYizp8 Xnlg+U42N/zL/0SJQAhPTwv/Y6TCJOuvs2noDCJEJPFywkxJVUhIixwoo0Ie1nzAi0R3 GuuukfcCBUQMWFsEzwmLsBc7byWcOJmpshK0ERdNQAr9Osdg2JIH2Pc8AsL15m1CIPVP YmIw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Vx5rN+ct; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741198563; x=1741803363; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=fs2XiVNnHYAkD3DO9+aoO+E7shltdmvc8ZIY6rs9JHw=; b=rGjF8gKflswp9eLIbprxx4A74SRw2JWot8A9dD1vrKwCGKkaYhGyVmRtf7lLjR0KF6 pL8LDS8rdUy34bhZ6yB8C/gmKQRBHAb7y2ig1fKZLmKEHJ6RJ5wzMbielfzG00vGTErG 4NmNKUdzbELN887AuNO4wZKi1vY5uH7Z3zxY34mG/zRp+ZslAD92PCFfPmOK+BIgoPYy uwI4AE+kOMaINZwqdaJAn96q4X44h1Cx9PXENyBMMfXw0cxt21IXMlXVPnc5yOvkrlsu dzML2hn4LzOstbc5fvAkZ4YiEJHyrStTyT9SsNZJExnrurJGEONXew6KK/ohEfRe9QsV NFlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741198563; x=1741803363; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fs2XiVNnHYAkD3DO9+aoO+E7shltdmvc8ZIY6rs9JHw=; b=YaUYeW5rQWIXNCMTuDLjlS62vVdQTVu0tHFyLj6ombQWjJKpQkKZcbh/ZPfh2mALfJ ac64g8A6tmpF4m0lEvnIDmNiLwfsWYXFtdUv7mz9+2iaFB4jIRaDH7TXUK9a5/FWuwrZ ti6SsqQEfdcct3Y+hsjCQ4qMv1/UGUffanrWcKnitgWli46tb4WhcJLcprocLTGZRt1I o2I8/HE4IaHJcTLa0cbPKhL8WzxCqWrB9p9aeNbysTUH1+vJw9laVMhXRaanjDMOctli /71zn+W889ZO65vi8PLJl9jDs+anvRO/rLffcLSJp31YyFZBMGR5K4nHhyXOLUxdrGsc hSiw== X-Forwarded-Encrypted: i=2; AJvYcCU3jewnt+DkbH8hF6IOQ2/UJk7ZBDvp7ttVTaoWWSUC55MvchoO/Hx+bWyOb6VQmVTwK1Wy1XCMNm1b@gnusha.org X-Gm-Message-State: AOJu0YzAX68fk2wtjc8C6OnPfEJ5TMDg122SuScjX7B5BhT74sfm+V6m Fdj5MubqZIzG/BAJjJCh/FG01+eUyYFDuOqwLXTCKCwNl20WOa6Y X-Google-Smtp-Source: AGHT+IHcYa8wvEOa+DNSnv4Lw4W3Xz0bcLO7mV842UVMDdG2allfBDFOUYoOFIHdQGJ6aw6j/LA4Ag== X-Received: by 2002:a05:6820:1b1a:b0:5fd:896:f222 with SMTP id 006d021491bc7-6003351b16bmr1933630eaf.4.1741198562872; Wed, 05 Mar 2025 10:16:02 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVEDkEX8kzLbzfMNwD3cw/05yMRR5Q0kbCgnM7FF5i9Qjg== Received: by 2002:a05:6820:229c:b0:600:108d:824b with SMTP id 006d021491bc7-6003e89de89ls76913eaf.0.-pod-prod-05-us; Wed, 05 Mar 2025 10:15:55 -0800 (PST) X-Received: by 2002:a05:6808:14d1:b0:3f6:7ed5:8fef with SMTP id 5614622812f47-3f683083823mr1996272b6e.0.1741198554947; Wed, 05 Mar 2025 10:15:54 -0800 (PST) Received: by 2002:ab3:4007:0:b0:290:3887:2fe with SMTP id a1c4a302cd1d6-292ff104906msc7a; Wed, 5 Mar 2025 09:53:08 -0800 (PST) X-Received: by 2002:a2e:a549:0:b0:30b:d05a:c103 with SMTP id 38308e7fff4ca-30bd7ae88f2mr13528811fa.29.1741197186874; Wed, 05 Mar 2025 09:53:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1741197186; cv=none; d=google.com; s=arc-20240605; b=DNBtAwwireTQt3ldw0cZtrYzZZ0QjxYc2/xn+Kq2VNMaK8P62WHKvLm1EddtYO16hc +93+mOl75u5VI8vfqryXpJPVmoR4emYzoiTsQ5H0DJU+TGfexj1a0mynHEmsPiA0+nwj Q3wjYybMc22PbmaCUXWsrfdY1vIG5Zavl98390fYKBi2MbFQn/hj6ogDKCI5kPgMbwIM aekaRqP5lBsJdSaacsQd64J3gglIA1d5TkpzgfQ1UML3r3kFEqvtTCUCIXaoaIPt3gEH ptualVToT+METktrtCPjHlpeltNs/WORnMhHIxp6SxbHV06Q/KxcfShunNNFIJj+1IRr Ce0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=1XpDrrvZ62/9p4PJ0N3kiY15Ym2eK6EobsruTV2e0C8=; fh=ZhIePvtzD2qBgm9PadABf9spV2moFvlPRwwE8o08T1o=; b=Podbhpjhwvs7LCeZQdKRCPj2ufog/7e2E3SNG36ihSvS4MAy+8yl0aNUDQhXCZI4oT E/JltVH5xg9T6HSh+xqmvxeVF7valcEXHR80bgsLN27pM49vPf6LYLnkBMiB85LcRjC3 oKqDzEo3wBIBivycqEA16KZNXTPWflygH1zCR9A5pnkjdO07m0HIbPKf8uwpxJGp0eEC wGtu92H/G9GZdW+KEn8U3A2v+IEY8S083faNI5x4v987d+aimy4cssBir8LIq2VAeVBN K5s6gVbR/rcqeFQBIunEOfEMWHW+Y//9MqBNe1bagYug/+PC4WudAM0XUw6ug0MA0ltL lu8A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Vx5rN+ct; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch. [185.70.40.132]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-30b94a8951bsi3064301fa.3.2025.03.05.09.53.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 09:53:06 -0800 (PST) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.132 as permitted sender) client-ip=185.70.40.132; Date: Wed, 05 Mar 2025 17:53:00 +0000 To: Anthony Towns From: "'moonsettler' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS Message-ID: In-Reply-To: References: Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 683227486ea25539271317dd2e7f041799bf329e MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Vx5rN+ct; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler 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: -1.0 (-) Hi AJ, I don't even think about this "recursion" as an issue in itself anymore. Th= e way CSFS enables "recursion" with deleted key covenants basically is usef= ul for some things not so much for others. Useful for vaults, possibly some= what useful for spacechains, pretty useless for tokens. It's not even a really a meaningful distinction as you noted in general. What's more interesting is "do these set of changes allow for 'native' fung= ible tokens you can _identify_ and interact with in script in a way that is= enforced by consensus"? Can you build AMMs for them? For a lot of proposal= s currently discussed we actually know how to do that. Anything fully gener= ic will trivially unlock this capability. The two primitives involved are state carrying (amounts) and quining (aka r= ecursion). These are the truly significant thresholds for changes that can = possibly alter the nature of bitcoin and how people use it. Only one of the= m is not enough. Beyond these there remains the issue of novel trust minimi= zed two way pegs to other chains like Ethereum which would also be in high = demand, in fact probably prioritized in funding over all other things we ar= e discussing in relation to covenants. After all these years I'm confident that for LNhance (CTV+CSFS+IKEY+PC) the= answer is NO. BR, moonsettler On Wednesday, March 5th, 2025 at 1:01 AM, Anthony Towns = wrote: > Hello world, >=20 > Some people on twitter are apparently proposing the near-term activation = of > CTV and CSFS (BIP 119 and BIP 348 respectively), eg: >=20 > https://x.com/JeremyRubin/status/1895676912401252588 > https://x.com/lopp/status/1895837290209161358 > https://x.com/stevenroose3/status/1895881757288996914 > https://x.com/reardencode/status/1871343039123452340 > https://x.com/sethforprivacy/status/1895814836535378055 >=20 > Since BIP 119's motivation is entirely concerned with its concept of > covenants and avoiding what it calls recursive covenants, I think it > is interesting to note that the combination of CSFS and CTV trivially > enables the construction of a "recursive covenant" as BIP 119 uses those > terms. One approach is as follows: >=20 > * Make a throwaway BIP340 private key X with 32-bit public key P. > * Calculate the tapscript "OP_OVER

OP_CSFS OP_VERIFY OP_CTV", and >=20 > its corresponding scriptPubKey K when combined with P as the internal pub= lic > key. > * Calculate the CTV hash corresponding to a payment of some specific valu= e V > to K; call this hash H > * Calculate the BIP 340 signature for message H with private key X, call = it S. > * Discard the private key X > * Funds sent to K can only be spent by the witness data " " that fo= rwards >=20 > an amount V straight back to K. >=20 > Here's a demonstration on mutinynet: >=20 > https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmy= jejrmqqx525gsk5nr58 >=20 > I'd encourage people to try implementing that themselves with their > preferred tooling; personally, I found it pretty inconvenient, which I > don't think is a good indication of ecosystem readiness wrt deployment. > (For me, the two components that are annoying is doing complicated > taproot script path spends, and calculating CTV hashes) >=20 > I don't believe the existence of a construction like this poses any > problems in practice, however if there is going to be a push to activate > BIP 119 in parallel with features that directly undermine its claimed > motivation, then it would presumably be sensible to at least update > the BIP text to describe a motivation that would actually be achieved by > deployment. >=20 > Personally, I think BIP 119's motivation remains very misguided: >=20 > - the things it describes are, in general, not "covenants" [0] > - the thing it avoids is not "recursion" but unbounded recursion > - avoiding unbounded recursion is not very interesting when arbitrarily > large recursion is still possible [1] > - despite claiming that "covenants have historically been widely > considering to be unfit for Bitcoin", no evidence for this claim has > been able to be provided [2,3] > - the opposition to unbounded recursion seems to me to either mostly > or entirely be misplaced fear of things that are already possible in > bitcoin and easily avoided by people who want to avoid it, eg [4] >=20 > so, at least personally, I think almost any update to BIP 119's motivatio= n > section would be an improvement... >=20 > [0] https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.a= u/ > [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/ > [2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-= 81d2-4a82b580ba99-000000@email.amazonses.com/ > [3] https://x.com/Ethan_Heilman/status/1194624166093369345 > [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au= / >=20 > Beyond being a toy example of a conflict with BIP 119's motivation > section, I think the above script could be useful in the context of the > "blind-merged-mining" component of spacechains [5]. For example, if > the commitment was to two outputs, one the recursive step and the other > being a 0sat ephemeral anchor, then the spend of the ephemeral anchor > would allow for both providing fees conveniently and for encoding the > spacechain block's commitment; competing spacechain miners would then > just be rbf'ing that spend with the parent spacechain update remaining > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would > need to be used to ensure the "one spacechain update per bitcoin block" > rule. (I believe mutinynet doesn't support ephemeral anchors however, so > I don't think there's anywhere this can be tested) >=20 > [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#= file-bmm-svg >=20 > (For a spacechain, miners would want to be confident that the private key > has been discarded. This confidence could be enhanced by creating X as a > musig2 key by a federation, in which case provided any of the private key= s > used in generating X were correctly discarded, then everything is fine, > but that's still a trust assumption. Simple introspection opcodes would > work far better for this use case, both removing the trust assumption > and reducing the onchain data required) >=20 > If you're providing CTV and CSFS anyway, I don't see why you wouldn't > provide the same or similar functionality via a SIGHASH flag so that you > can avoid specifying the hash directly when you're signing it anyway, > giving an ANYPREVOUT/NOINPUT-like feature directly. >=20 > (Likewise, I don't see why you'd want to activate CAT on mainnet without > also at least re-enabling SUBSTR, and potentially also the redundant > LEFT and RIGHT operations) >=20 > For comparison, bllsh [6,7] takes the approach of providing > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV > equivalent would then either involve simplying writing: >=20 > (=3D (bip342_txmsg 3) 0x.....) >=20 > meaining "calculate the message hash of the current tx for SIGHASH_SINGLE= , > then evaluate whether the result is exactly equal to this constant" > providing one of the standard sighashes worked for your use case, or > replacing the bip342_txmsg opcode with a custom calculation of the tx > hash, along the lines of the example reimplementation of bip342_txmsg > for SIGHASH_ALL [8] in the probably more likely case that it didn't. If > someone wants to write up the BIP 119 hashing formula in bllsh, I'd > be happy to include that as an example; I think it should be a pretty > straightforward conversion from the test-tx example. >=20 > If bllsh were live today (eg on either signet or mainnet), and it were > desired to softfork in a more optimised implementation of either CTV or > ANYPREVOUT to replace people coding their own implementation in bllsh > directly, both would simply involve replacing calls to "bip342_txmsg" > with calls to a new hash calculation opcode. For CTV behaviour, usage > would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO behaviour, > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That > is, the underlying "I want to hash a message in such-and-such a way" > looks the same, and how it's used is the wallet author's decision, > not a matter of how the consensus code is written. >=20 > I believe simplicity/simfony can be thought of in much the same way; > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour > [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like > behaviour [10]. >=20 > [6] https://github.com/ajtowns/bllsh/ > [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224 > [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx > [9] https://github.com/BlockstreamResearch/simfony/blob/master/examples/p= 2pk.simf > [10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/= ctv.simf >=20 > For me, the bllsh/simplicity approach makes more sense as a design > approach for the long term, and the ongoing lack of examples of killer > apps demonstrating big wins from limited slices of new functionality > leaves me completely unexcited about rushing something in the short term. > Having a flood of use cases that don't work out when looked into isn't > a good replacement for a single compelling use case that does. >=20 > Cheers, > aj >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/Z8eUQCfCWjdivIzn%40erisian.com.au. --=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/= A1uNlgzWNUB3L_ITCAGDB85UhNdcF4GX6zZhkaEFHPmLmQivzXnY7stFGtG8iR_8cmVCxiWklqO= 9VEN6SqDyO6fMEuN3gJDnDEOIN-60sDE%3D%40protonmail.com.