From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 06 Mar 2025 13:27:19 -0800 Received: from mail-yw1-f190.google.com ([209.85.128.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tqIkO-0003U2-Nw for bitcoindev@gnusha.org; Thu, 06 Mar 2025 13:27:19 -0800 Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-6fd779c17efsf30984767b3.0 for ; Thu, 06 Mar 2025 13:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741296431; x=1741901231; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=ybfBOz4FG6gub+wMRQoagWo2hmG9jFCHQCTGCnHflEo=; b=B0/iVkGCra3hQXLNNmDPPIBRbFkUsf5xzwvbT2S06o2f49cS/Vl8QZ4nLOJzXVnKiu Fihsy31iFLnxwidf5vbbdxzsLA/fWDs/XA6q0il93CVz63x4gAvyGNpnrHFApZfOFUYq 8k34kReFd285fjVj0apazxnhq5GhrypMkegsuX7QOpVDuk8uIBvjJwIxV4w3otCAwVEV ZhILj8Q36IBjXMdYeZt1o8r/eu8OQu1WKzXvedo0cKh19zlue72qWhrO557+VLbkhMAT HS3Jhi+qcmxKj7s0PRUtUjPa/PQbh9vT0fLpS0DDstAGEPvF+FzLJ6cph0prxUSb5Q6X CeNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741296431; x=1741901231; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=ybfBOz4FG6gub+wMRQoagWo2hmG9jFCHQCTGCnHflEo=; b=N+WK3n6wH6vJw1WHNjYvBWTvZSD626TGtXx5lP4uUUekBjdSEr+YykWqoxZmIBkQFX s8oS90GYbHQGck2pjNqErrrOc0OC5bDSpjaae2kJaLBt/skAHJ+DKTcU1Sf+ITJS2Hji JjSjubIpP6OwH9WDnA6z0pP5CjEdqE1ePRy1uZzl4nbhlBQeWk1oHsVbJsX3rBwc96Y2 DYWCc0w0sX7S141NJ6LA8TfCIMoSaMwexnENO3HYIKdFXb7+dYVxeNn6Lp9akgNaUPBG xQKG9qwOkFqXAV9QYmiM+y5uykzkgpsrPvXEknZKyxgqSpyNHdaB+QedOzkwx9DLHNqR 6SCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741296431; x=1741901231; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=ybfBOz4FG6gub+wMRQoagWo2hmG9jFCHQCTGCnHflEo=; b=LP42tqtsq4VVOnyEdfESTjW9RmgViesiwTWwhrxA44GSDSlcql9i3sLIB6ME6JF6oR rneXRuO3/4w8mGybF5O6QREcu3WhCSj4qiMh8depg/q/8HCb5nFPeEmR2Vrips4Mbex+ KlnL9OWDHqHGLf81T8iqkdMdj5Np4TXTNr8eJSbeFGEacID/3durQg/nA3XbzkgDyHGb dR46LdCYhjW8NA2kM6FG+AfHWj+5KVoxJeKf1diFAQ9QmO1irAPrpoNTpim3RILFCf+r B5FpiktKrdHxj8YooFLlTIo4lOX6KujRRCGDkwHXLw2Rw5eEbFUAELZEV+Ir/f/fzlE5 c7pA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCX5qFW3UUQ3JqFggvpMqKBYaw18zO7QrETL4waZ95dgtIOG7oJyBmmIL+xzOD0GkD78kcycq+Avxvlh@gnusha.org X-Gm-Message-State: AOJu0YxsM/4xehlkpOYTH8TiVOBIWfvquiJJKuKGZkSg86qcqHCHB0r3 nzB/BD8TSvUW66J6fxOK0Zx1L0jNkCaT2LMKWIWZDfEnFnQt2nUe X-Google-Smtp-Source: AGHT+IG8fbwmGusBfgvuF7FnQxKBTqcKROeKtEYpCXuDbY26RHWOz1b4qrSIK3j2D/VLpWq7xvj49A== X-Received: by 2002:a05:6902:2101:b0:e60:e14a:df7b with SMTP id 3f1490d57ef6-e634793fc80mr6949396276.12.1741296430853; Thu, 06 Mar 2025 13:27:10 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFh9XyrQ/kbtPYulwY+Nnww5Vr1WYih2EIAo2px/t+xSg== Received: by 2002:a25:264b:0:b0:e5b:3877:6d59 with SMTP id 3f1490d57ef6-e6347ead2c9ls1550066276.0.-pod-prod-05-us; Thu, 06 Mar 2025 13:27:08 -0800 (PST) X-Received: by 2002:a05:690c:6382:b0:6fb:ab27:5748 with SMTP id 00721157ae682-6febf3aea3bmr15032627b3.33.1741296428078; Thu, 06 Mar 2025 13:27:08 -0800 (PST) Received: by 2002:a05:690c:c92:b0:6fe:b496:fc0e with SMTP id 00721157ae682-6feb4970ec6ms7b3; Thu, 6 Mar 2025 13:26:25 -0800 (PST) X-Received: by 2002:a05:690c:6088:b0:6f5:2793:2897 with SMTP id 00721157ae682-6febf37b72bmr16291757b3.30.1741296383533; Thu, 06 Mar 2025 13:26:23 -0800 (PST) Date: Thu, 6 Mar 2025 13:26:23 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn@googlegroups.com> In-Reply-To: References: <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com> <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com> Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_40072_1428590326.1741296383124" X-Original-Sender: antoine.riard@gmail.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 (/) ------=_Part_40072_1428590326.1741296383124 Content-Type: multipart/alternative; boundary="----=_Part_40073_468764918.1741296383124" ------=_Part_40073_468764918.1741296383124 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, > After that, one can build a script:=20 OP_CSFS> OR < =20 SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker= =20 can > make the funding UTXO amount available as a "anyone-can-spend" and force= =20 a re- > commitment to the same tx-withholding script. Correcting myself, after more thinking I believe to get a non-forgeable=20 "proof-of -target-UTXO-mining" there should be a merkle branch proof of the txid back= =20 to the mined block. Otherwise, any participant in the target UTXO /=20 transaction (e.g a LN channel) can confirm the target transaction to execute the contracting= =20 protocol according to its semantics _and_ generate the "proof-of-target-UTXO-mining"= =20 to claim the "anyone-can-spend" bribing output. So to do a merkle branch proof, script would have to be of the rough form= =20 e.g: < ,= =20 or any equivalent opcode primitive allowing to get concatenation in the script= . For the design of a TxWithhold, all that you wish is a proof-of-existence= =20 of a block B + transaction T (in the mathematical sense). That way if a timelock= =20 is reached after X blocks, and no proof-of-existence as been brought until=20 then, this logically implies that B + T do not exist. Or at least have not been= =20 published, which for the purpose of the chain being the publication space and=20 anti-double-spend oracle of UTXO spends is the same. I don't believe with OP_CHECKSIGFROMSTACK alone you can build such=20 proof-of-target-UTXO -mining, though I'm not sure of such statement. All cov primitives=20 proposals are coming without formal analysis of the limits of the expressivity extensions, there= =20 has been progress since OP_EVAL, though it's always tooling on a subset of current= =20 Bitcoin Script not extension. At the very least, and in reference to what is described in naumenkogs's=20 original TxWithhold article, the introduction of OP_CSFS let you have m-of-n oracles= =20 doing attestations in the script that a block has been confirmed, eventually with= =20 a tx. This is already a powerful building block for TxWithhold. At first thought,= =20 I don't see how you can have the equivalent with OP_CHECKTEMPLATEVERIFY, by design= =20 the scope is reduced. On the distinction between execution risks with crypto-economic incentives= =20 risks brought by some on this thread, this is unclear what is meant exactly. Of= =20 course with execution risks, it might more think affecting full-node security (e.g= =20 a DoS vector, reason a lot of opcodes were disabled back in ~2010), though it=20 could be just a risk of misuage of the primitive by use-cases toolchain (e.g=20 generating=20 a consensus-invalid tx due to misuse of the timelock flags) or an attack=20 driven by crypto-ecnomic incentives (e.g selfish-mining or block-withholding=20 attack at the miner-level). Though even for a simple DoS, one can evaluate the CPU /= =20 bandwidth cost in quantitative terms to gauge if it's a serious risk, there is an=20 area of uncertainty, or it's not a risk. When we we talk about security risks, one has to see things that it's more= =20 a continuum, where an attacker vector can be used as a building block for more=20 sophisticated attacks. In the original bitcoin paper, crypto-incentives themselves are=20 weighted to evaluate the soundness of the system in section 6. and in section 11. Best, Antoine OTS hash: 2c3e2e41ed67484f5d58138413cfca7f0aba5d7b4d448f2895a1b70b2886e9d8 Le jeudi 6 mars 2025 =C3=A0 19:03:48 UTC, moonsettler a =C3=A9crit : > Hi All, > > > I am less persuaded that consensus risk is particularly high for very= =20 > narrowly scoped changes > Agreed. > > Some people out there seem to conflate execution risks with=20 > crypto-economic incentives risks. > Better designed script systems obviously reduce execution risks and=20 > unintended consensus failure risks and make maintenance easier. > They also quiet easily blow the lid off other types of risks by nature of= =20 > being better and more capable. > > Paradoxically the more expressive bitcoin script becomes over time, the= =20 > less likely that a script system overhaul comes with a nasty surprise. > > BR, > moonsettler > > > On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders =20 > wrote: > > > > Of course it depends on the specifics, but rewriting a clean=20 > interpreter that we can actually reason about does not strike me as a=20 > necessarily riskier approach than "just changing a few lines of code" in = an=20 > interpreter that hardly anyone knows how it really behaves in all cases. > >=20 > > It's certainly something to consider when weighing further off Bitcoin= =20 > Script updates: From here is something like "Great Script Restoration" ev= er=20 > the right choice vs a from scratch overhaul? I am less persuaded that=20 > consensus risk is particularly high for very narrowly scoped changes,=20 > ignoring the "fixed" costs of changing consensus, maintenance burden, MEV= il=20 > risks, etc. The risk-reward ratio may be suboptimal of course. > > Greg > > On Wednesday, March 5, 2025 at 11:39:27=E2=80=AFAM UTC-5 Antoine Poinso= t wrote: > >=20 > > > Hi, > > >=20 > > >=20 > > > Just picking on one thing Laolu said: > > >=20 > > > > The current Overton Window appears to be focused on a small (LoC=20 > wise) package to enable a greater degree of permissionless innovation on= =20 > Bitcoin > > >=20 > > >=20 > > > For what it's worth i'm not sure this is the correct focus. Bitcoin= =20 > Script is so notoriously unpredictable and hard to reason about that most= =20 > of what matters is outside of the lines of code changed. Of course it=20 > depends on the specifics, but rewriting a clean interpreter that we can= =20 > actually reason about does not strike me as a necessarily riskier approac= h=20 > than "just changing a few lines of code" in an interpreter that hardly=20 > anyone knows how it really behaves in all cases. > > >=20 > > > Antoine > > >=20 > > > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun < > lao...@gmail.com> wrote: > > >=20 > > > > Hi AJ, > > > >=20 > > > > First a standard disclaimer: the contents of this email shouldn't b= e > > > > interpreted as an endorsement of one covenants proposal over anothe= r. > > > >=20 > > > > > Since BIP 119's motivation is entirely concerned with its concept= =20 > of > > > > > covenants and avoiding what it calls recursive covenants > > > >=20 > > > > If we look at the motivation section of BIP 119, we find this=20 > sentence: > > > >=20 > > > > > This BIP introduces a simple covenant called a *template* which= =20 > enables a > > > > > limited set of highly valuable use cases without significant risk= .=20 > BIP-119 > > > > > templates allow for non-recursive fully-enumerated covenants with= =20 > no > > > > > dynamic state. > > > >=20 > > > > You appear to have latched onto the "non-recursive" aspect, ignorin= g=20 > the > > > > subsequent qualifiers of "fully-enumerated" and "with no dynamic=20 > state". > > > >=20 > > > > The example that you've come up with to "directly undermine" the=20 > claimed > > > > motivations of BIP 119 is still fully enumerated (the sole state is= =20 > declared > > > > up front), and doesn't contain dynamic state (I can't spend the=20 > contract on > > > > chain and do something like swap in another hash H, or signature S)= . > > > >=20 > > > > > I found it pretty inconvenient, which I don't think is a good=20 > indication > > > > > of ecosystem readiness wrt deployment. (For me, the two component= s=20 > that > > > > > are annoying is doing complicated taproot script path spends, and > > > > > calculating CTV hashes) > > > >=20 > > > > What language/libraries did you use to produce the spend? In my own > > > > development tooling of choice, producing complicated taproot script= =20 > path > > > > spends is pretty straight forward, so perhaps the inconvenience you= =20 > ran into > > > > says more about your dev tooling than the ecosystem readiness. > > > >=20 > > > > It's also worth pointing out that your example relies on private ke= y > > > > deletion, which if deemed acceptable, can be used to emulate CTV as= =20 > is today > > > > (though you can't create a self-referential loop that way afaict). > > > >=20 > > > > > For me, the bllsh/simplicity approach makes more sense as a desig= n > > > > > approach for the long term > > > >=20 > > > > Simplicity certainly has some brilliant devs working on it, but=20 > after all > > > > these years it still seems to be struggling to exit research mode= =20 > with some > > > > "killer apps" on Liquid. > > > >=20 > > > > bllsh on the other hand is a very new (and cool!) project that has = no > > > > development uptake beyond its creator. Given its nascent state, it= =20 > seems > > > > rather premature to promote it as a long term solution. > > > >=20 > > > > Both of them are effectively a complete rewrite of Script, so=20 > compared to > > > > some of the existing covenant proposals on the table (many of which= =20 > have a > > > > small core code footprint in the interpreter), they represent a=20 > radically > > > > expanded scope (ecosystem changes, wallets, consensus code) and=20 > therefore > > > > additional risks. The current Overton Window appears to be focused= =20 > on a > > > > small (LoC wise) package to enable a greater degree of permissionle= ss > > > > innovation on Bitcoin, while leaving the research landscape open fo= r=20 > more > > > > dramatic overhauls (bllsh/Simplicity) in the future. > > > >=20 > > > > -- Laolu > > > >=20 > > > >=20 > > > > On Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns =20 > wrote: > > > >=20 > > > > > Hello world, > > > > >=20 > > > > > Some people on twitter are apparently proposing the near-term=20 > 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= =20 > of > > > > > covenants and avoiding what it calls recursive covenants, I think= =20 > it > > > > > is interesting to note that the combination of CSFS and CTV=20 > trivially > > > > > enables the construction of a "recursive covenant" as BIP 119 use= s=20 > 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",= =20 > and > > > > > its corresponding scriptPubKey K when combined with P as the=20 > internal public > > > > > key. > > > > > * Calculate the CTV hash corresponding to a payment of some=20 > specific value V > > > > > to K; call this hash H > > > > > * Calculate the BIP 340 signature for message H with private key= =20 > X, call it S. > > > > > * Discard the private key X > > > > > * Funds sent to K can only be spent by the witness data " "= =20 > that forwards > > > > > an amount V straight back to K. > > > > >=20 > > > > > Here's a demonstration on mutinynet: > > > > >=20 > > > > >=20 > https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmy= jejrmqqx525gsk5nr58 > > > > >=20 > > > > > I'd encourage people to try implementing that themselves with the= ir > > > > > preferred tooling; personally, I found it pretty inconvenient,=20 > which I > > > > > don't think is a good indication of ecosystem readiness wrt=20 > deployment. > > > > > (For me, the two components that are annoying is doing complicate= d > > > > > taproot script path spends, and calculating CTV hashes) > > > > >=20 > > > > > I don't believe the existence of a construction like this poses a= ny > > > > > problems in practice, however if there is going to be a push to= =20 > activate > > > > > BIP 119 in parallel with features that directly undermine its=20 > claimed > > > > > motivation, then it would presumably be sensible to at least upda= te > > > > > the BIP text to describe a motivation that would actually be=20 > 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=20 > 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= =20 > has > > > > > been able to be provided [2,3] > > > > > - the opposition to unbounded recursion seems to me to either=20 > mostly > > > > > or entirely be misplaced fear of things that are already possible= =20 > 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= =20 > motivation > > > > > section would be an improvement... > > > > >=20 > > > > > [0]=20 > https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/ > > > > > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/ > > > > > [2]=20 > https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.= amazonses.com/ > > > > > [3] https://x.com/Ethan_Heilman/status/1194624166093369345 > > > > > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au= / > > > > >=20 > > > > > Beyond being a toy example of a conflict with BIP 119's motivatio= n > > > > > section, I think the above script could be useful in the context= =20 > of the > > > > > "blind-merged-mining" component of spacechains [5]. For example, = if > > > > > the commitment was to two outputs, one the recursive step and the= =20 > other > > > > > being a 0sat ephemeral anchor, then the spend of the ephemeral=20 > anchor > > > > > would allow for both providing fees conveniently and for encoding= =20 > the > > > > > spacechain block's commitment; competing spacechain miners would= =20 > then > > > > > just be rbf'ing that spend with the parent spacechain update=20 > remaining > > > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV= =20 > would > > > > > need to be used to ensure the "one spacechain update per bitcoin= =20 > block" > > > > > rule. (I believe mutinynet doesn't support ephemeral anchors=20 > however, so > > > > > I don't think there's anywhere this can be tested) > > > > >=20 > > > > > [5]=20 > https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file= -bmm-svg > > > > >=20 > > > > > (For a spacechain, miners would want to be confident that the=20 > private key > > > > > has been discarded. This confidence could be enhanced by creating= =20 > X as a > > > > > musig2 key by a federation, in which case provided any of the=20 > private keys > > > > > used in generating X were correctly discarded, then everything is= =20 > fine, > > > > > but that's still a trust assumption. Simple introspection opcodes= =20 > would > > > > > work far better for this use case, both removing the trust=20 > assumption > > > > > and reducing the onchain data required) > > > > >=20 > > > > > If you're providing CTV and CSFS anyway, I don't see why you=20 > wouldn't > > > > > provide the same or similar functionality via a SIGHASH flag so= =20 > that you > > > > > can avoid specifying the hash directly when you're signing it=20 > anyway, > > > > > giving an ANYPREVOUT/NOINPUT-like feature directly. > > > > >=20 > > > > > (Likewise, I don't see why you'd want to activate CAT on mainnet= =20 > without > > > > > also at least re-enabling SUBSTR, and potentially also the=20 > redundant > > > > > LEFT and RIGHT operations) > > > > >=20 > > > > > For comparison, bllsh [6,7] takes the approach of providing > > > > > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify"=20 > (same but > > > > > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. = A=20 > 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=20 > SIGHASH_SINGLE, > > > > > then evaluate whether the result is exactly equal to this constan= t" > > > > > providing one of the standard sighashes worked for your use case,= =20 > or > > > > > replacing the bip342_txmsg opcode with a custom calculation of th= e=20 > tx > > > > > hash, along the lines of the example reimplementation of=20 > bip342_txmsg > > > > > for SIGHASH_ALL [8] in the probably more likely case that it=20 > 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=20 > pretty > > > > > straightforward conversion from the test-tx example. > > > > >=20 > > > > > If bllsh were live today (eg on either signet or mainnet), and it= =20 > were > > > > > desired to softfork in a more optimised implementation of either= =20 > CTV or > > > > > ANYPREVOUT to replace people coding their own implementation in= =20 > bllsh > > > > > directly, both would simply involve replacing calls to=20 > "bip342_txmsg" > > > > > with calls to a new hash calculation opcode. For CTV behaviour,= =20 > usage > > > > > would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO=20 > behaviour, > > > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)".= =20 > That > > > > > is, the underlying "I want to hash a message in such-and-such a= =20 > 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= =20 > way; > > > > > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like=20 > behaviour > > > > > [9], or "jet::eq_256" comparing a tx hash and a constant for=20 > 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]=20 > https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.= simf > > > > > [10]=20 > https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.s= imf > > > > >=20 > > > > > For me, the bllsh/simplicity approach makes more sense as a desig= n > > > > > approach for the long term, and the ongoing lack of examples of= =20 > killer > > > > > apps demonstrating big wins from limited slices of new=20 > functionality > > > > > leaves me completely unexcited about rushing something in the=20 > short term. > > > > > Having a flood of use cases that don't work out when looked into= =20 > 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 Googl= e=20 > Groups "Bitcoin Development Mailing List" group. > > > > > To unsubscribe from this group and stop receiving emails from it,= =20 > send an email to bitcoindev+...@googlegroups.com. > > > > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.c= om.au > . > > > >=20 > > > > -- > > > > You received this message because you are subscribed to the Google= =20 > Groups "Bitcoin Development Mailing List" group. > > > > To unsubscribe from this group and stop receiving emails from it,= =20 > send an email to bitcoindev+...@googlegroups.com. > > >=20 > > > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQ= jG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com > . > >=20 > > -- > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a664= 9e610ce5n%40googlegroups.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/= 7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn%40googlegroups.com. ------=_Part_40073_468764918.1741296383124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all,

> After that, one can build a script: <proof-of-ta= rget-UTXO-mining=3Dcommitment_tx"
> OP_CSFS> OR <<bounty_t= imelock> <OP_CHECKLOCKTIMEVERIFY> <recursive_bounty_sig |
= > SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold at= tacker can
> make the funding UTXO amount available as a "anyone-ca= n-spend" and force a re-
> commitment to the same tx-withholding sc= ript.

Correcting myself, after more thinking I believe to get a = non-forgeable "proof-of
-target-UTXO-mining" there should be a merkle = branch proof of the txid back to
the mined block. Otherwise, any parti= cipant in the target UTXO / transaction (e.g
a LN channel) can confirm= the target transaction to execute the contracting protocol
according = to its semantics _and_ generate the "proof-of-target-UTXO-mining" to
c= laim the "anyone-can-spend" bribing output.

So to do a merkle br= anch proof, script would have to be of the rough form e.g:
< <le= af_node_ab> <OP_SHA256> <OP_CAT> <leaf_node_cd> <OP= _SHA256> <OP_CAT>, or
any equivalent opcode primitive allowin= g to get concatenation in the script.

For the design of a TxWith= hold, all that you wish is a proof-of-existence of a
block B + transac= tion T (in the mathematical sense). That way if a timelock is
reached = after X blocks, and no proof-of-existence as been brought until then,
= this logically implies that B + T do not exist. Or at least have not been p= ublished,
which for the purpose of the chain being the publication spa= ce and anti-double-spend
oracle of UTXO spends is the same.

I don't believe with OP_CHECKSIGFROMSTACK alone you can build such proof-o= f-target-UTXO
-mining, though I'm not sure of such statement. All cov = primitives proposals are coming
without formal analysis of the limits = of the expressivity extensions, there has been
progress since OP_EVAL,= though it's always tooling on a subset of current Bitcoin
Script not = extension.

At the very least, and in reference to what is descri= bed in naumenkogs's original
TxWithhold article, the introduction of O= P_CSFS let you have m-of-n oracles doing
attestations in the script th= at a block has been confirmed, eventually with a tx.
This is already a= powerful building block for TxWithhold. At first thought, I don't
see= how you can have the equivalent with OP_CHECKTEMPLATEVERIFY, by design the= scope
is reduced.

On the distinction between execution ris= ks with crypto-economic incentives risks
brought by some on this threa= d, this is unclear what is meant exactly. Of course
with execution ris= ks, it might more think affecting full-node security (e.g a DoS
vector= , reason a lot of opcodes were disabled back in ~2010), though it could be<= br />just a risk of misuage of the primitive by use-cases toolchain (e.g ge= nerating
a consensus-invalid tx due to misuse of the timelock flags) = or an attack driven
by crypto-ecnomic incentives (e.g selfish-mining o= r block-withholding attack at
the miner-level). Though even for a simp= le DoS, one can evaluate the CPU / bandwidth
cost in quantitative term= s to gauge if it's a serious risk, there is an area of
uncertainty, or= it's not a risk.

When we we talk about security risks, one has = to see things that it's more a continuum,
where an attacker vector can= be used as a building block for more sophisticated
attacks. In the or= iginal bitcoin paper, crypto-incentives themselves are weighted
to eva= luate the soundness of the system in section 6. and in section 11.
Best,
Antoine
OTS hash: 2c3e2e41ed67484f5d58138413cfca7f0aba5d= 7b4d448f2895a1b70b2886e9d8

Le jeudi 6 mars 2025 =C3=A0 19:03:48 UTC, mo= onsettler a =C3=A9crit=C2=A0:
Hi All,

> I am less persuaded that consensus risk is particularly high for v= ery narrowly scoped changes
Agreed.

Some people out there seem to conflate execution risks with crypto-econ= omic incentives risks.
Better designed script systems obviously reduce execution risks and uni= ntended consensus failure risks and make maintenance easier.
They also quiet easily blow the lid off other types of risks by nature = of being better and more capable.

Paradoxically the more expressive bitcoin script becomes over time, the= less likely that a script system overhaul comes with a nasty surprise.

BR,
moonsettler


On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders <gsand...@gmail.com> wrote:

> > Of course it depends on the specifics, but rewriting a clean = interpreter that we can actually reason about does not strike me as a neces= sarily riskier approach than "just changing a few lines of code" = in an interpreter that hardly anyone knows how it really behaves in all cas= es.
>=20
> It's certainly something to consider when weighing further off= Bitcoin Script updates: From here is something like "Great Script Res= toration" ever the right choice vs a from scratch overhaul? I am less = persuaded that consensus risk is particularly high for very narrowly scoped= changes, ignoring the "fixed" costs of changing consensus, maint= enance burden, MEVil risks, etc. The risk-reward ratio may be suboptimal of= course.
> Greg
> On Wednesday, March 5, 2025 at 11:39:27=E2=80=AFAM UTC-5 Antoine P= oinsot wrote:
>=20
> > Hi,
> >=20
> >=20
> > Just picking on one thing Laolu said:
> >=20
> > > The current Overton Window appears to be focused on a sm= all (LoC wise) package to enable a greater degree of permissionless innovat= ion on Bitcoin
> >=20
> >=20
> > For what it's worth i'm not sure this is the correct = focus. Bitcoin Script is so notoriously unpredictable and hard to reason ab= out that most of what matters is outside of the lines of code changed. Of c= ourse it depends on the specifics, but rewriting a clean interpreter that w= e can actually reason about does not strike me as a necessarily riskier app= roach than "just changing a few lines of code" in an interpreter = that hardly anyone knows how it really behaves in all cases.
> >=20
> > Antoine
> >=20
> > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun = <lao...@gmail.com> wro= te:
> >=20
> > > Hi AJ,
> > >=20
> > > First a standard disclaimer: the contents of this email = shouldn't be
> > > interpreted as an endorsement of one covenants proposal = over another.
> > >=20
> > > > Since BIP 119's motivation is entirely concerne= d with its concept of
> > > > covenants and avoiding what it calls recursive cove= nants
> > >=20
> > > If we look at the motivation section of BIP 119, we find= this sentence:
> > >=20
> > > > This BIP introduces a simple covenant called a *tem= plate* which enables a
> > > > limited set of highly valuable use cases without si= gnificant risk. BIP-119
> > > > templates allow for non-recursive fully-enumerated = covenants with no
> > > > dynamic state.
> > >=20
> > > You appear to have latched onto the "non-recursive&= quot; aspect, ignoring the
> > > subsequent qualifiers of "fully-enumerated" an= d "with no dynamic state".
> > >=20
> > > The example that you've come up with to "direct= ly undermine" the claimed
> > > motivations of BIP 119 is still fully enumerated (the so= le state is declared
> > > up front), and doesn't contain dynamic state (I can&= #39;t spend the contract on
> > > chain and do something like swap in another hash H, or s= ignature S).
> > >=20
> > > > I found it pretty inconvenient, which I don't t= hink is a good indication
> > > > of ecosystem readiness wrt deployment. (For me, the= two components that
> > > > are annoying is doing complicated taproot script pa= th spends, and
> > > > calculating CTV hashes)
> > >=20
> > > What language/libraries did you use to produce the spend= ? In my own
> > > development tooling of choice, producing complicated tap= root script path
> > > spends is pretty straight forward, so perhaps the inconv= enience you ran into
> > > says more about your dev tooling than the ecosystem read= iness.
> > >=20
> > > It's also worth pointing out that your example relie= s on private key
> > > deletion, which if deemed acceptable, can be used to emu= late CTV as is today
> > > (though you can't create a self-referential loop tha= t way afaict).
> > >=20
> > > > For me, the bllsh/simplicity approach makes more se= nse as a design
> > > > approach for the long term
> > >=20
> > > Simplicity certainly has some brilliant devs working on = it, but after all
> > > these years it still seems to be struggling to exit rese= arch mode with some
> > > "killer apps" on Liquid.
> > >=20
> > > bllsh on the other hand is a very new (and cool!) projec= t that has no
> > > development uptake beyond its creator. Given its nascent= state, it seems
> > > rather premature to promote it as a long term solution.
> > >=20
> > > Both of them are effectively a complete rewrite of Scrip= t, so compared to
> > > some of the existing covenant proposals on the table (ma= ny of which have a
> > > small core code footprint in the interpreter), they repr= esent a radically
> > > expanded scope (ecosystem changes, wallets, consensus co= de) and therefore
> > > additional risks. The current Overton Window appears to = be focused on a
> > > small (LoC wise) package to enable a greater degree of p= ermissionless
> > > innovation on Bitcoin, while leaving the research landsc= ape open for more
> > > dramatic overhauls (bllsh/Simplicity) in the future.
> > >=20
> > > -- Laolu
> > >=20
> > >=20
> > > On Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns <= ;a...@erisian.com.au> wro= te:
> > >=20
> > > > 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/189567691240= 1252588
> > > > https://x.com/lopp/status/1895837290209161358
> > > > https://x.com/stevenroose3/status/18958817= 57288996914
> > > > https://x.com/reardencode/status/187134303912= 3452340
> > > > https://x.com/sethforprivacy/status/189= 5814836535378055
> > > >=20
> > > > Since BIP 119's motivation is entirely concerne= d with its concept of
> > > > covenants and avoiding what it calls recursive cove= nants, I think it
> > > > is interesting to note that the combination of CSFS= and CTV trivially
> > > > enables the construction of a "recursive coven= ant" 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> O= P_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 wit= h 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.
> > > >=20
> > > > Here's a demonstration on mutinynet:
> > > >=20
> > > > https://mutinynet.com/address/tb1p0p5027= shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
> > > >=20
> > > > I'd encourage people to try implementing that t= hemselves with their
> > > > preferred tooling; personally, I found it pretty in= convenient, which I
> > > > don't think is a good indication of ecosystem r= eadiness wrt deployment.
> > > > (For me, the two components that are annoying is do= ing complicated
> > > > taproot script path spends, and calculating CTV has= hes)
> > > >=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 und= ermine its claimed
> > > > motivation, then it would presumably be sensible to= at least update
> > > > the BIP text to describe a motivation that would ac= tually be achieved by
> > > > deployment.
> > > >=20
> > > > Personally, I think BIP 119's motivation remain= s very misguided:
> > > >=20
> > > > - the things it describes are, in general, not &quo= t;covenants" [0]
> > > > - the thing it avoids is not "recursion" = but unbounded recursion
> > > > - avoiding unbounded recursion is not very interest= ing when arbitrarily
> > > > large recursion is still possible [1]
> > > > - despite claiming that "covenants have histor= ically been widely
> > > > considering to be unfit for Bitcoin", no evide= nce 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 al= ready possible in
> > > > bitcoin and easily avoided by people who want to av= oid it, eg [4]
> > > >=20
> > > > so, at least personally, I think almost any update = to BIP 119's motivation
> > > > section would be an improvement...
> > > >=20
> > > > [0] https://gnusha.org/= pi/bitcoindev/20220719044...@erisian.com.au/
> > > > [1] https://gnusha.org/pi/bit= coindev/87k0dwr...@rustcorp.com.au/
> > > > [2] https://gnusha.org/pi/bitcoindev/0100017ee647= 2e02-037d355d-4c16...@email.amazonses.com/
> > > > [3] https://x.com/Ethan_Heilman/status/11= 94624166093369345
> > > > [4] https://gnusha.org/pi= /bitcoindev/2022021715...@erisian.com.au/
> > > >=20
> > > > Beyond being a toy example of a conflict with BIP 1= 19's motivation
> > > > section, I think the above script could be useful i= n the context of the
> > > > "blind-merged-mining" component of spacec= hains [5]. For example, if
> > > > the commitment was to two outputs, one the recursiv= e step and the other
> > > > being a 0sat ephemeral anchor, then the spend of th= e ephemeral anchor
> > > > would allow for both providing fees conveniently an= d for encoding the
> > > > spacechain block's commitment; competing spacec= hain miners would then
> > > > just be rbf'ing that spend with the parent spac= echain update remaining
> > > > unchanged. The "nLockTime" and "sequ= ences_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 ephe= meral anchors however, so
> > > > I don't think there's anywhere this can be = tested)
> > > >=20
> > > > [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d= 8b34906b16a5#file-bmm-svg
> > > >=20
> > > > (For a spacechain, miners would want to be confiden= t that the private key
> > > > has been discarded. This confidence could be enhanc= ed 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 int= rospection opcodes would
> > > > work far better for this use case, both removing th= e trust assumption
> > > > and reducing the onchain data required)
> > > >=20
> > > > If you're providing CTV and CSFS anyway, I don&= #39;t see why you wouldn't
> > > > provide the same or similar functionality via a SIG= HASH 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 ac= tivate CAT on mainnet without
> > > > also at least re-enabling SUBSTR, and potentially a= lso the redundant
> > > > LEFT and RIGHT operations)
> > > >=20
> > > > For comparison, bllsh [6,7] takes the approach of p= roviding
> > > > "bip340_verify" (directly equivalent to C= SFS), "ecdsa_verify" (same but
> > > > for ECDSA rather than schnorr), "bip342_txmsg&= quot; and "tx" opcodes. A CTV
> > > > equivalent would then either involve simplying writ= ing:
> > > >=20
> > > > (=3D (bip342_txmsg 3) 0x.....)
> > > >=20
> > > > meaining "calculate the message hash of the cu= rrent tx for SIGHASH_SINGLE,
> > > > then evaluate whether the result is exactly equal t= o this constant"
> > > > providing one of the standard sighashes worked for = your use case, or
> > > > replacing the bip342_txmsg opcode with a custom cal= culation of the tx
> > > > hash, along the lines of the example reimplementati= on of bip342_txmsg
> > > > for SIGHASH_ALL [8] in the probably more likely cas= e that it didn't. If
> > > > someone wants to write up the BIP 119 hashing formu= la 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 ma= innet), and it were
> > > > desired to softfork in a more optimised implementat= ion of either CTV or
> > > > ANYPREVOUT to replace people coding their own imple= mentation in bllsh
> > > > directly, both would simply involve replacing calls= to "bip342_txmsg"
> > > > with calls to a new hash calculation opcode. For CT= V behaviour, usage
> > > > would look like "(=3D (bipXXX_txmsg) 0x...)&qu= ot; as above; for APO behaviour,
> > > > usage would look like "(bip340_verify KEY (bip= XXX_txmsg) SIG)". That
> > > > is, the underlying "I want to hash a message i= n 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 m= uch the same way;
> > > > with "jet::bip_0340_verify" taking a tx h= ash for SIGHASH-like behaviour
> > > > [9], or "jet::eq_256" comparing a tx hash= and a constant for CTV-like
> > > > behaviour [10].
> > > >=20
> > > > [6] http= s://github.com/ajtowns/bllsh/
> > > > [7] https://delvingbitcoin.org/t/de= buggable-lisp-scripts/1224
> > > > [8] https://github.com/ajto= wns/bllsh/blob/master/examples/test-tx
> > > > [9] https://github.com/BlockstreamResearch/simfony/blob/master/example= s/p2pk.simf
> > > > [10] https://github.com/BlockstreamResearch/simfony/blob/master/examples= /ctv.simf
> > > >=20
> > > > For me, the bllsh/simplicity approach makes more se= nse 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 someth= ing 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 subscribe= d to the Google Groups "Bitcoin Development Mailing List" group.
> > > > To unsubscribe from this group and stop receiving e= mails from it, send an email to = bitcoindev+...@googlegroups.com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bi= tcoindev/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 email to bitco= indev+...@googlegroups.com.
> >=20
> > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/C= AO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%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 email to bitcoindev+...@= googlegroups.com.
> To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a6649e610ce= 5n%40googlegroups.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/msgid/bitcoind= ev/7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn%40googlegroups.com.
------=_Part_40073_468764918.1741296383124-- ------=_Part_40072_1428590326.1741296383124--