Delivery-date: Wed, 12 Mar 2025 14:51:37 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tsTzE-0007Eh-P6 for bitcoindev@gnusha.org; Wed, 12 Mar 2025 14:51:37 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-2c1c3cdb3e6sf148692fac.2 for ; Wed, 12 Mar 2025 14:51:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1741816291; cv=pass; d=google.com; s=arc-20240605; b=iTw0manzNEYS09Sn/XW+TAl1bqdv756arcAH1InXNrecfAkuJolwlTfccNEBfqMgLL 0G6iTd8rrMQDeZ5hDWkxubbOgdGqP4jHf6CUDfmcUp9EBriybK4pHYeMURPc3suqUx+Q T25P8fB4lDTUnNX3EM5enBe5pfTiiBQKtRXZttrTc1HdPEF5kshNOK6/53irdumrfDbW gUYRwvKYIEz97L/ZNcPCkVcuqFn2CF3TN+XLYl2ywOrPQM3eoSABO3ikJefTT+dErvtV epWNr89SwOLysxFUgFU7u61IVZZvYySG/OUwAtMP1kOvSFbLf+iq29gZMk/cnmwHQLcL 31dg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=njil7KvbUof+u9MsjiMdmmKhEem+xDEadddITUimGK8=; fh=ZjeKnKJ1HSuyEBBj9EeVuPgy+jjp6JeFylAA1VUKlzE=; b=EZfHFXmPh8lcMOTflac/+6/B5A1IO+N/fV5Dzf83JTU/B3R2iOYSvFrNTsgOICHyoV e6bDqsIInbb2sqG1BqxBZvocWUklvSK0X57J91zdlfxPg/DqVbfuABiehVlobPLLsaEZ eCwUe334P+glR38VKRyWNI6pd4wvql8wMJINB8g718pJRdSkaqtTaitrJkLiPyG3jzKx EGssgddvEYh+sYhjmNLINyfAIFytFPT2HLtn12rBYpPdWWreUyBcNqOy8GL8Lz6IdEV+ ECxy5ZrclXcTMTfuswRxNmjbF3Bj+tvamZvT6IHMJkOBqKP7jUgcA78hWYnBD0XjUsNS XFlg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@shesek.info header.s=google header.b="YlEUz1l/"; spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=nadav@shesek.info; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741816291; x=1742421091; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=njil7KvbUof+u9MsjiMdmmKhEem+xDEadddITUimGK8=; b=tqoYJ+MjcDIs06hRMDvRNG06REDpfzrdiiwKuLLGjFGC1lUX3/pcHuSn1fU+R69+Wp kMcJP1daQoy0zy2rLA+UYOkTuWLqCUZTvZ1SvQILqq05LmOGc0IyaK56gaBYTSvUSXZS UVUWaeJX5Bcpn9vpoDNrtwRdO2vyJPMQZzl2L3KFi0wMsVWiUl6AfV2eBxg2exb6RKsZ xNd1mtXf/LqV6Nya4HqPWk916dG1QoDvnJJeMZ8cbbaJxkerdl89t4WBhPqEfzIs8RPo IiWgZDtwtURd5p7ZAkmBk1qzGNjalrWOcdiRXQzRrLiHktQhEKH7/BXCiMqselDGHZ5Y FwSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741816291; x=1742421091; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=njil7KvbUof+u9MsjiMdmmKhEem+xDEadddITUimGK8=; b=KFd4FKd+JT7oa/6j5KLe6pRMGBMeC2mKoqY+J7r+IdGSfuFQme1cshX1mPEqS9WKru LuPTg1EeFxyQZ13gj4yB56Pv0leJE18hv7BxMUYXILAn7kNRlV2tduuVLCzwNHMbAHvw 0OOqXs58k9dI7e/Y1an1KKSD17mVW6/YeQ4R7rftzCC7W1ZgFPj4NxIK1ZowkQk8Bkzt Kw7Y5VNhNJVuu7XkMEGKvyyNo/SsKgN5K+dhwRh2H3bOQyvP6So/mXfY4dypx9QfMgz9 a/ja21/53M8GvbJKMeE5tjj8UmhaQ8vCDtZSScd6lH6d8ymXry1pPa93O7FqzfFCZIhu p/9w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVFPDOskle5CIvaqHb/ZeDvmW2FT1O4a5ChNjojmH/IaS6CYNvbIkfE7xymVmGj7pRzbe1cwgq5uugZ@gnusha.org X-Gm-Message-State: AOJu0YyZu7Smf56tksR6Iefq6PhDV4+e3RC2d1jOV7rKglGAPMwTgFXU YCeZ+tNR3wzIWmgoV5q7tsH8g8ILCG0mdbweMsfb9Z8DKXPvJbRq X-Google-Smtp-Source: AGHT+IFrkislOXaf2vwDi9N5DAvRDBd1Fqio6fSNwAQKYz+M1OB9a9wSfBAgGVlqgBRwuV+9z7+IOQ== X-Received: by 2002:a05:6820:209:b0:5fe:9edb:eafe with SMTP id 006d021491bc7-6004ab23460mr9930673eaf.5.1741816290607; Wed, 12 Mar 2025 14:51:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVHkTHbVvJPuvwUwz++TPNZKzwPoXQSun+zDUMgkhHrjfg== Received: by 2002:a4a:eac4:0:b0:5fc:fe35:8d1b with SMTP id 006d021491bc7-601d8912360ls59615eaf.1.-pod-prod-04-us; Wed, 12 Mar 2025 14:51:27 -0700 (PDT) X-Received: by 2002:a05:6808:3996:b0:3f8:effc:938 with SMTP id 5614622812f47-3f8effc0cecmr8254161b6e.34.1741816287739; Wed, 12 Mar 2025 14:51:27 -0700 (PDT) Received: by 2002:a05:6808:f09:b0:3fa:da36:efcd with SMTP id 5614622812f47-3fb4fd22b30msb6e; Wed, 12 Mar 2025 09:15:44 -0700 (PDT) X-Received: by 2002:a05:6602:4143:b0:85b:4941:3fe2 with SMTP id ca18e2360f4ac-85b494177d8mr1574757739f.7.1741796143717; Wed, 12 Mar 2025 09:15:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1741796143; cv=none; d=google.com; s=arc-20240605; b=Ni0BsG2Z9TnfNwkXDBnrxSSkPqBVd+2Tdqxo6z5EQqskB+cD/jDGrUqy/STiOxfOew znDf6ruk4jFqrxPJkoWM1+Sc36a8IZyYnCrZ+EjBIkLf9FyDFDSE7ha0PtQiUW25X4QM FwfmSutqF02gvoIMV++7V3SwjUMud62SSEfiBe6TRgpztAxAggFnmjJiYFjOlrZ2NPRD pBv3Jz0JI+pNyhOQCTOxbLJIAfpWw5/mAWlqW9bmKZGJ3V0PGesiO4zIuRBnAczA58zW CHRIeF3UdQ9B2YJ8yzp5rMGw3ZEOm2A3knAY8OWzqeQiAMICZr390d+yNHGy3rFLndkZ /yAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=x8NCDoa9sYtxEMDnxh0JSUgpJlqSI7sb4wfrMlNoxMg=; fh=ZhIePvtzD2qBgm9PadABf9spV2moFvlPRwwE8o08T1o=; b=LJ5VbgxOTF5gkGSkWjHamvHmyLkMdkk/Pxcz4KsXBw9TZqH1tgChsmeOSAp3Oa8+6j CdQXqkyQR3Vy+075DDSryboePT90hWkmcghpZ/h1PEVvXcTYK9hYk8Al/saN2O9yCBBH WS9cstlRfFonNV84Z+nnSGQpc2WnJfQqY8gMX+q3KRh2i3uYSVgxbn2saBjjsYLR5V6o nN09vaHfXPFez1eNI9ZU0B45ewl0R1XnD0XjiNPJUUYb7NdPGK9Lu9xZGSgFk4y6edyJ kuQwxCSJD2NWymctO6oYCOKbPR05Rt54Q+ZznyzTLjMeIgp719OkafqiNqpg9jt0Ik6S cuEw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@shesek.info header.s=google header.b="YlEUz1l/"; spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=nadav@shesek.info; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com. [2607:f8b0:4864:20::1135]) by gmr-mx.google.com with ESMTPS id ca18e2360f4ac-85b43192bcesi32031139f.3.2025.03.12.09.15.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Mar 2025 09:15:43 -0700 (PDT) Received-SPF: pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::1135 as permitted sender) client-ip=2607:f8b0:4864:20::1135; Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6febbd3b75cso57271357b3.0 for ; Wed, 12 Mar 2025 09:15:43 -0700 (PDT) X-Gm-Gg: ASbGncvy8uiPiCJDaEbvhb2McvuXkkIY2ARu/P9fW0cXNqKvDDovSlphLgHiXDQn5dU V2TBnG+REQK4cMiI8RD+n2TMJcNqlqJIjOuZUxTlR6lbaEHiCmqTNEgjD6yh0tOyCMkItd+JAD5 QHtB8TiU5LMoR3mMkft5/xPQe89MWuM2mt5hMUHMijt2JLGhRN2MxMiJHMtuXu X-Received: by 2002:a05:690c:7106:b0:6fb:91a9:94d9 with SMTP id 00721157ae682-6febf2ab277mr332649747b3.2.1741796143002; Wed, 12 Mar 2025 09:15:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nadav Ivgi Date: Wed, 12 Mar 2025 18:15:31 +0200 X-Gm-Features: AQ5f1JpiGsNgbG7-cAZVhk7XSSj3FZzX1ZkkEdP0Bf5RUnKk75u5fFKrlKWHG9E Message-ID: Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS To: Anthony Towns Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000006015a1063027848e" X-Original-Sender: nadav@shesek.info X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@shesek.info header.s=google header.b="YlEUz1l/"; spf=pass (google.com: domain of nadav@shesek.info designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=nadav@shesek.info; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) --0000000000006015a1063027848e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > One important difference is that for a BMM-like bidding system [..]. But for other cases, the difference would be negligible. Actually, thinking about this some more, this could be an issue even without multiple bidders - the tx preparing the fee utxo might pay sufficient fees to get itself confirmed, yet not provide enough fees for the main transaction to confirm too. In this case you'll basically also have 'losing bids' that waste fees/space and will have to make another tx to prepare a larger fee utxo. So yes, pretty annoying. :< More than I initially thought. shesek On Wed, Mar 12, 2025 at 12:02=E2=80=AFPM Nadav Ivgi wro= te: > On Wed, Mar 12, 2025 at 5:48=E2=80=AFAM Anthony Towns = wrote: > >> I think the original COSHV implementation had the hash appear a push >> *after* >> the CTV opcode. >> >> https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-c= oshv.mediawiki > > > Yes you are of course correct. My memory failed me, should've looked up > the BIP :) > > With either APO or CTV alone you can do an arbitrarily long chain of >> commitments, > > adding CSFS and discarding the CSFS private key allows >> you to have a single commitment that can be reused indefinitely. > > > With APO alone, you can use one of two constructs: > > 1. Trustless, Finite - using a chain of pre-computed transactions where > the signature for the next transaction is committed to in the scriptPubKe= y. > This has similar properties to what you can get with CTV alone. > > 2. Trusted, Infinite - using a simple non-committed signature spending > back to the same address. This has similar properties to your CTV+CSFS > construct. > > Does adding CSFS enable any additional designs? > > I think it's impossible to get Trustless, Infinite short of having full > introspection abilities (CAT/TXHASH/Elements-like), right? > > With Elements it's pretty straightforward, something like > `OP_PUSHCURRENTINPUTINDEX OP_INSPECTINPUTSCRIPTPUBKEY <0> > OP_INSPECTOUTPUTSCRIPTPUBKEY OP_ROT OP_EQUALVERIFY OP_EQUAL` > > You could have CTV commit to two inputs, with the second input's entire >> value being burnt to fees, but that's fairly annoying > > > Yes, preparing an exact-sized utxo for fees is indeed annoying. However > it's not much different from CPFP - an extra tx with the same overall > number of inputs/outputs, only around 46vB less efficient[0] (assuming yo= u > need change[1]). So at least for some use-cases it's not terrible either. > > One important difference is that for a BMM-like bidding system, losing > bids would still pay tx fees (and take up chain space) for creating the f= ee > utxo, unlike with CPFP where only the winning bid pays fees. But for othe= r > cases, the difference would be negligible. > > Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) tha= t > you mentioned, where no extra transaction is needed at all. > > [0] Assuming you need to use N coins for fees and that change is needed, > with an exact-sized fee utxo you have a N-in, 2-out tx to prepare the fee > utxo, then a 2-in, 1-out for the main tx - for a total of N+2 inputs and = 3 > outputs. With CPFP, its 1-in, 2-out for the main tx, then a N+1-in, 1-out > tx for the CPFP fee bump - also for a total of N+2 inputs and 3 outputs. > However, with CPFP you could use Pay-to-Anchor (while the fee utxo has to > be key-encumbered), saving 65WU for one input plus 30vB/120WU for one > output, making it more efficient by a total of 185WU/46vB (assuming the f= ee > utxo uses key-path P2TR). > > [1] If you happen to have an existing utxo to pay fees with, the 2-input > CTV template would be as efficient as it gets, on par with APO|SINGLE. Th= is > can be extended to combos of multiple utxos, by adding more CTV tapleaves > for different numbers of inputs (at a slight cost of larger control > blocks). With large wallets it could be plausible to find such combos. > > Cheers, > shesek > --=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/= CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w%40mail.gmail.com. --0000000000006015a1063027848e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> One important difference is that for a BMM-like = bidding system [..]. But for other cases, the difference would be negligibl= e.

Actually, thinking about this some more, this c= ould be an issue even without multiple bidders - the tx preparing the fee u= txo might pay sufficient fees to get itself confirmed, yet not provide enou= gh fees for the main transaction to confirm too. In this case you'll ba= sically also have 'losing bids' that waste fees/space and will have= to make another tx to prepare a larger fee utxo.

= So yes, pretty annoying. :< More than I initially thought.
shesek


On Wed, Mar 12= , 2025 at 12:02=E2=80=AFPM Nadav Ivgi <nadav@shesek.info> wrote:
=

1. Trustless, Finite - using a chain of pre-= computed transactions where the signature for the next transaction is commi= tted to in the scriptPubKey. This has similar properties to what you can ge= t with CTV alone.

2. Trusted, Infinite - usin= g a simple non-committed signature spending back to the same address. This has similar properties to your CTV+CSFS construct.

Does adding CSFS enable any additional designs?<= /div>

I think it's impossible to get Trustless, Infi= nite short of having full introspection abilities (CAT/TXHASH/Elements-like= ), right?

With Elements it's pretty strai= ghtforward, something like `OP_PUSHCURRENTINPUTINDEX=20 OP_INSPECTINPUTSCRIPTPUBKEY <0> OP_INSPECTOUTPUTSCRIPTPUBKEY=20 OP_ROT OP_EQUALVERIFY OP_EQUAL`

You could have CTV commit to two inputs, with the second input's entire=
value being burnt to fees, but that's fairly annoying
=
Yes, preparing an exact-sized utxo for fees is indeed annoyi= ng. However it's not much different from CPFP - an extra tx with the sa= me overall number of inputs/outputs, only around 46vB less efficient[0] (as= suming you need change[1]). So at least for some use-cases it's not ter= rible either.

One important difference is that for a BMM-like= bidding system, losing bids would still pay tx fees (and take up chain spa= ce) for creating the fee utxo, unlike with CPFP where only the winning bid = pays fees. But for other cases, the difference would be negligible.

Of course, the most WU-optimal construct is APO|SINGLE (i= mplying ACP) that you mentioned, where no extra transaction is needed at al= l.

[0] Assuming you need to use N coins for fees a= nd that change is needed, with an exact-sized fee utxo you have a N-in, 2-o= ut tx to prepare the fee utxo, then a 2-in, 1-out for the main tx - for a t= otal of N+2 inputs and 3 outputs. With CPFP, its 1-in, 2-out for the main t= x, then a N+1-in, 1-out tx for the CPFP fee bump - also for a total of N+2 = inputs and 3 outputs. However, with CPFP you could use Pay-to-Anchor (while= the fee utxo has to be key-encumbered), saving 65WU for one input plus 30v= B/120WU for one output, making it more efficient by a total of 185WU/46vB (= assuming the fee utxo uses key-path P2TR).

[1] If = you happen to have an existing utxo to pay fees with, the 2-input CTV templ= ate would be as efficient as it gets, on par with APO|SINGLE. This can be e= xtended to combos of multiple utxos, by adding more CTV tapleaves for diffe= rent numbers of inputs (at a slight cost of larger control blocks). With la= rge wallets it could be plausible to find such combos.

= Cheers,
shesek

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