path: root/8f/6067cb69a43bb3a41d6e3826a90d3d07a5d7bf

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 <bitcoindev+bncBAABBW5JUK7AMGQE6JWEGZI@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <aj@erisian.com.au>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Message-ID: <A1uNlgzWNUB3L_ITCAGDB85UhNdcF4GX6zZhkaEFHPmLmQivzXnY7stFGtG8iR_8cmVCxiWklqO9VEN6SqDyO6fMEuN3gJDnDEOIN-60sDE=@protonmail.com>
In-Reply-To: <Z8eUQCfCWjdivIzn@erisian.com.au>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
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 <moonsettler@protonmail.com>
Reply-To: moonsettler <moonsettler@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <aj@erisian.com.au>=
 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 <P> 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 "<H> <S>" 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.