path: root/49/79b674dd06ff3cbff550fd152a931de75cec6b

Delivery-date: Tue, 04 Mar 2025 17:06:35 -0800
Received: from mail-oi1-f189.google.com ([209.85.167.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDBNTKFG4EDRBEOHT27AMGQE5OHPDPQ@googlegroups.com>)
	id 1tpdDW-0004bG-Nr
	for bitcoindev@gnusha.org; Tue, 04 Mar 2025 17:06:35 -0800
Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-3f6670241c8sf1451068b6e.2
        for <bitcoindev@gnusha.org>; Tue, 04 Mar 2025 17:06:34 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1741136789; cv=pass;
        d=google.com; s=arc-20240605;
        b=PZ/UKAtWNpPDA3c9zE/Wtv4QlGu1kMWvcjncLMA7rMndblFw3kV/vla7puVJdLcVh6
         7N+ZI0jYh3LYpe4SkgW0C92S7Qhnl4muUytJuXEu6+wBcLHFDxhC6TJN6/6nqZppxGOT
         csRWh1bvKDmHqENqRZGutu7aN6kSih1uHXQuOWxoziQpwGHudPKpuQXXd3PYdNmmWjbt
         ruEzmnSXh3xFw9XHWWsns0Gn2Fl+0AEXClPNpexk+X1WNGQIkIHXwizwkNPwiIy8kkE3
         eqwP1VWnVCX8vd9RctKrmQYY6jhho++4UTfEUR6dQEEV7S9XGec1bHKY8TFPE6yXOGqT
         LM9Q==
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:content-disposition:mime-version
         :message-id:subject:to:from:date:sender:dkim-signature;
        bh=A+9400qGY6qUgGZt9HgtQ2jtJxPs4c3jRxJcMi8qDUU=;
        fh=zY9HivQG8H1tfQz6Z1l9jogzukWWzGAKgKhOfXz8v18=;
        b=P/EYd5QtFsf+B1uOx2Fo7diC5UY6vMRbQSqOLFRopnvPTqSSr461qkJj2G1PB7/TMf
         PVhmYLsjkEAXvsxHaCc71seNPDd2COQ1Bz+xghzHPkxjFA/rWJQyqfDs2fxA1CPqyy9s
         lcixUNIiolCzcC47BNuJ889LCCeQW5ZA8bOTTEb6KRK6L3USH148lYKPR1KQfrKYe2eQ
         KVUi0qLsV+Uew+6WoScrzSLeTMlbjKXC+eiOTGEsX+wyF28prVynWeGWpn3/EmyANL9f
         RDzW8sZkC/3dBG7UG9ebkJ50n8xyVAR8ff7WmU7SjSu2ZDeq1inRfPNuWf9GBKyKO/YR
         S1Jg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741136789; x=1741741589; 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:content-disposition:mime-version:message-id
         :subject:to:from:date:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=A+9400qGY6qUgGZt9HgtQ2jtJxPs4c3jRxJcMi8qDUU=;
        b=vnAssRvC8P1qGbdRnslulpq8myyk4NNVqYYs1iiprPVDYdChuCnCOoVp8f8ziQmDvS
         v4zuuUcZB4ZLMsXDI+Nbm21ptEK8q6UaG0cqMaWohK8Sv/baaxC/4Xqmcg/m7tdDDwKZ
         Xi4tfQQdmL9TzZCE1I/SeM3BdKPOysFA3oamstnui6dYydZ1L7HwREHu/EJtk9HHYCvM
         mvGAYECzaipjM+OqbVIfTQ4Fd+yC3RL7Flq+pVGPIR3GJI9zAU5Urk9ToujSZl9NfE/c
         mpRugKZ0OLigmpFQh7DSRduaa8gnEmimPgtrzL2dKbPfiopFhKDzTQ2VhU7btrx02o/I
         B8NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741136789; x=1741741589;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-disposition:mime-version:message-id
         :subject:to:from:date:x-beenthere:x-gm-message-state:sender:from:to
         :cc:subject:date:message-id:reply-to;
        bh=A+9400qGY6qUgGZt9HgtQ2jtJxPs4c3jRxJcMi8qDUU=;
        b=T1yrOi2sL6OPk4YBHA74wUrinP1r9DnvagnX0rN2zLy53abNUQ0REkafa7U0f/HGyy
         bf5zihZHwvt2Vtm4I5hqtLzzw7yZWD+H36DWMzQS4zA9kRfzJsKMJFNMKA7C+SGkFyfI
         m349bzYwTut9HpjYNnuwUSG+se4c+W6jtn2RRw9s5trsYnqPQb4kyFCNAExuPbjY6/t9
         2r7hCVpQa3xw3UQSTwRs3PsUBOXjCUGiZNkrDeZFD6AS63r/amjIy8/SLZqK3vqJhSnT
         epG5PHS2xov4XfMs7KKA3ZYeHwIMiTuxnMAfNwYNFO5+eYrKlk0OZ6hfWQl6eGmMIxGt
         uL4A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXgy9DAamv/VHuxSJd66mCIx2CjnnLEiY7kPa59KiN5VR5aGovE0msf9ZsFPhG0fOtjake7pyllQJtj@gnusha.org
X-Gm-Message-State: AOJu0YwbHNRLRqYYktP/wLnBdvMJdvkNBO2Z7VzOY0/i8nZ1OaULwODy
	ps8J0B7Nh+dAVyylm9joOre1E0zFX09+oFqRHyBe17kc9Fkx/ECQ
X-Google-Smtp-Source: AGHT+IFRavD8l4Eu9fRbegdAv2N2DjU++fdogRokB56oO7kGsSJcoS21/ARviImtT9yJoZhrF9oG8g==
X-Received: by 2002:a05:6808:10c3:b0:3f4:1a7d:959a with SMTP id 5614622812f47-3f68313e0b7mr873770b6e.2.1741136788939;
        Tue, 04 Mar 2025 17:06:28 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVHZgVulc2Dr6dj1eo9uWT9rby6kWKtv6UPp/LTFKghIrQ==
Received: by 2002:a4a:8301:0:b0:600:108d:824b with SMTP id 006d021491bc7-600108d85d5ls1174711eaf.0.-pod-prod-05-us;
 Tue, 04 Mar 2025 17:06:25 -0800 (PST)
X-Received: by 2002:a05:6808:1904:b0:3f6:7b67:573 with SMTP id 5614622812f47-3f68316d19bmr589152b6e.22.1741136785504;
        Tue, 04 Mar 2025 17:06:25 -0800 (PST)
Received: by 2002:a54:4397:0:b0:3f6:6c6a:dc5e with SMTP id 5614622812f47-3f682685fd2msb6e;
        Tue, 4 Mar 2025 16:01:14 -0800 (PST)
X-Received: by 2002:a05:6830:3c0c:b0:727:2fbd:1147 with SMTP id 46e09a7af769-72a1faf1ffbmr624992a34.2.1741132872251;
        Tue, 04 Mar 2025 16:01:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1741132872; cv=none;
        d=google.com; s=arc-20240605;
        b=NGkK5LSrbItd0GFGnsr05jFZr8spUCKTG6Wc/3nuyXGgFMc8ocIv0eFbKbPyJFMzI+
         PJ52AH46QxYWqDLAB/K9O79VTf59K6FrEeQBR9rwkF4i44Obw3Q5lWeAyarkQNg+6EVE
         nXLv6bvkMxchYgt4V5+8HGcUHTFo16OaJ48yLg4uOVpvmbQQCCBsnug26svnbIGUjfQE
         w3DBXrGasS+aqTUozNtUPKW9vgF7oSlFJU4WfsPNNapZhigqmxG1yHRTBnjHHy4RsEth
         rI+7adHaOVHF8AT/+5SgP56WjVJA5HuAGXbm3PCt6MbPa/0sLQMvpKuaAJm7x5sB2ZRJ
         p3fw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-disposition:mime-version:message-id:subject:to:from:date;
        bh=h+/sIzXZEyfBHffX1mXUhzb+ng2U8T5TDRuMyGlBDCQ=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=QfLPFfBSGhQ9T2CrndnMLZF9yKRXdFYD82ARIcOzpwXn4dpkr9AKVFxcj5nB3ZShZH
         mAyruGFH4v9CAcGVOKS6N78ii6pNydZz1FlqPXLUMQVCAF2mydocKGQR9fT5AZJOIDpW
         Sa0G3IDu9eJDqB1Gs1K3zJiuPF2Lg1uiIp/eQqL0+EvfF94myp8XiXU7B70b3BGJbXeu
         y7emeCiyWaajmrU+3/3MzOtvkw/mwcfgS+Skz+9/TjyfjDKWoQOavreVNZD+RkRDCVJb
         QppRZMB5Et7LvBrfLlnKV8QsnG0rFm6kChMFmCvUJSQATngrtDr9xrOoEjnMoymqVx3l
         0JCQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193])
        by gmr-mx.google.com with ESMTPS id 46e09a7af769-728afcf4ed3si715902a34.1.2025.03.04.16.01.11
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 04 Mar 2025 16:01:12 -0800 (PST)
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Received: from aj@azure.erisian.com.au
	by cerulean.erisian.com.au with esmtpsa  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <aj@erisian.com.au>)
	id 1tpcCB-00075o-1h
	for bitcoindev@googlegroups.com;
	Wed, 05 Mar 2025 10:01:09 +1000
Received: by email (sSMTP sendmail emulation); Wed, 05 Mar 2025 10:01:04 +1000
Date: Wed, 5 Mar 2025 10:01:04 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] "Recursive covenant" with CTV and CSFS
Message-ID: <Z8eUQCfCWjdivIzn@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
X-Spam_score: 0.0
X-Spam_bar: /
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
 permitted sender) smtp.mailfrom=aj@erisian.com.au
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: -0.8 (/)

Hello world,

Some people on twitter are apparently proposing the near-term activation of
CTV and CSFS (BIP 119 and BIP 348 respectively), eg:

 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

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:

 * 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
   its corresponding scriptPubKey K when combined with P as the internal public
   key.
 * Calculate the CTV hash corresponding to a payment of some specific value 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 forwards
   an amount V straight back to K.

Here's a demonstration on mutinynet:

 https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58

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)

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.

Personally, I think BIP 119's motivation remains very misguided:

 - 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]

so, at least personally, I think almost any update to BIP 119's motivation
section would be an improvement...

[0] https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
[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/

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)

[5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(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 keys
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)

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.

(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)

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:

   (= (bip342_txmsg 3) 0x.....)

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.

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 "(= (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.

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].

[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/p2pk.simf
[10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf

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.

Cheers,
aj

-- 
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/Z8eUQCfCWjdivIzn%40erisian.com.au.