path: root/23/625f5bc4822ef8f7c33bfbf43981a2cba2fd9b

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 <bitcoindev+bncBDN456FOY4IRBYEDZC7AMGQEFWLVKDI@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <Z8eUQCfCWjdivIzn@erisian.com.au> <CAGXD5f3EGyUVBc=bDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q@mail.gmail.com>
 <Z9ED_dez7_UHxjK0@erisian.com.au> <CAGXD5f3zHuwGq+M1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ@mail.gmail.com>
In-Reply-To: <CAGXD5f3zHuwGq+M1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ@mail.gmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Wed, 12 Mar 2025 18:15:31 +0200
X-Gm-Features: AQ5f1JpiGsNgbG7-cAZVhk7XSSj3FZzX1ZkkEdP0Bf5RUnKk75u5fFKrlKWHG9E
Message-ID: <CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w@mail.gmail.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
To: Anthony Towns <aj@erisian.com.au>
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: <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.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 <nadav@shesek.info> wro=
te:

> On Wed, Mar 12, 2025 at 5:48=E2=80=AFAM Anthony Towns <aj@erisian.com.au>=
 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

<div dir=3D"ltr"><div>&gt; One important difference is that for a BMM-like =
bidding system [..]. But for other cases, the difference would be negligibl=
e.</div><div><br></div><div>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&#39;ll ba=
sically also have &#39;losing bids&#39; that waste fees/space and will have=
 to make another tx to prepare a larger fee utxo.</div><div><br></div><div>=
So yes, pretty annoying. :&lt; More than I initially thought.</div><div><br=
></div><div>shesek</div><div><br></div></div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 12=
, 2025 at 12:02=E2=80=AFPM Nadav Ivgi &lt;<a href=3D"mailto:nadav@shesek.in=
fo">nadav@shesek.info</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Mar 12, 2025 at 5:48=E2=80=AFAM Antho=
ny Towns &lt;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@eris=
ian.com.au</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
I think the original COSHV implementation had the hash appear a push *after=
*<br>
the CTV opcode.<br>
<a href=3D"https://github.com/JeremyRubin/bips/blob/op-checkoutputshashveri=
fy/bip-coshv.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github=
.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki</a=
></blockquote><div><br></div><div>Yes you are of course correct. My memory =
failed me, should&#39;ve looked up the BIP :) <br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
With either APO or CTV alone you can do an arbitrarily long chain of commit=
ments,</blockquote><div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">a=
dding CSFS and discarding the CSFS private key allows<br>
you to have a single commitment that can be reused indefinitely.</blockquot=
e>=C2=A0</div><div>With APO alone, you can use one of two constructs:</div>=
<div><br></div><div></div><div>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.</div><div><br></div><div><div>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.</div=
></div><div><br></div><div>Does adding CSFS enable any additional designs?<=
/div><div><br></div><div>I think it&#39;s impossible to get Trustless, Infi=
nite short of having full introspection abilities (CAT/TXHASH/Elements-like=
), right?</div><div><br></div><div><div>With Elements it&#39;s pretty strai=
ghtforward, something like `OP_PUSHCURRENTINPUTINDEX=20
OP_INSPECTINPUTSCRIPTPUBKEY &lt;0&gt; OP_INSPECTOUTPUTSCRIPTPUBKEY=20
OP_ROT OP_EQUALVERIFY OP_EQUAL`</div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">

You could have CTV commit to two inputs, with the second input&#39;s entire=
<br>
value being burnt to fees, but that&#39;s fairly annoying</blockquote><div>=
<br></div><div>Yes, preparing an exact-sized utxo for fees is indeed annoyi=
ng. However it&#39;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&#39;s not ter=
rible either.</div><br><div>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.</div><d=
iv><br></div><div>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.</div><div><br></div><div>[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).</div><div><br></div><div>[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.</div><div><br></div>=
Cheers,</div><div class=3D"gmail_quote">shesek</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w%40mail.g=
mail.com</a>.<br />

--0000000000006015a1063027848e--