From: Peter Todd <pete@petertodd.org>
To: alicexbt <alicexbt@protonmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Date: Tue, 30 Jan 2024 04:41:30 +0000 [thread overview]
Message-ID: <Zbh9+oNDuPEapFwQ@petertodd.org> (raw)
In-Reply-To: <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]
On Sat, Jan 27, 2024 at 05:50:27PM +0000, alicexbt wrote:
> Hi Peter,
>
> In addition to the various methods shared by Brandon, users also have the option of using multiple templates, each with different fee rates. While this introduces some trade-offs, it remains a possibility that some users might prefer.
I mentioned this possibility in the email that you are replying to. It is
difficult to impossible to implement in many (but not all!) CTV-using
constructions because you get an exponential "blow-up" of possible fee
variants.
> OP_IF
> //Template-A
> OP_PUSHBYTES_32 HASH1 OP_CHECKTEMPLATEVERIFY
> OP_ELSE
> //Template-B
> OP_PUSHBYTES_32 HASH2 OP_CHECKTEMPLATEVERIFY
> OP_ENDIF
Note that with taproot, it is more efficient to do this via taproot leafs than
with IF statements.
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> On Wednesday, January 24th, 2024 at 7:31 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the
> > transaction that can spend an output. Namely, # of inputs, # of outputs,
> > outputs hash, etc. In practice, in many if not most CTV use-cases intended to
> > allow multiple parties to share a single UTXO, it is difficult to impossible to
> > allow for sufficient CTV variants to cover all possible fee-rates. It is
> > expected that CTV would be usually used with anchor outputs to pay fees; by
> > creating an input of the correct size in a separate transaction and including
> > it in the CTV-committed transaction; or possibly, via a transaction sponsor
> > soft-fork.
> >
> > This poses a scalability problem: to be genuinely self-sovereign in a protocol
> > with reactive security, such as Lightning, you must be able to get transactions
> > mined within certain deadlines. To do that, you must pay fees. All of the
> > intended exogenous fee-payment mechanisms for CTV require users to have at
> > least one UTXO of suitable size to pay for those fees.
> >
> > This requirement for all users to have a UTXO to pay fees negates the
> > efficiency of CTV-using UTXO sharing schemes, as in an effort to share a UTXO,
> > CTV requires each user to have an extra UTXO. The only realistic alternative is
> > to use a third party to pay for the UTXO, eg via a LN payment, but at that
> > point it would be more efficient to pay an out-of-band mining fee. That of
> > course is highly undesirable from a mining centralization perspective.(2)
> >
> > Recommendations: CTV in its current form be abandoned as design foot-gun. Other
> > convenant schemes should be designed to work well with replace-by-fee, to avoid
> > requirements for extra UTXOs, and to maximize on-chain efficiency.
> >
> > 1) https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki
> > 2) https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-01-30 4:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 19:31 [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Peter Todd
2024-01-25 12:57 ` Michael Folkson
2024-01-30 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2024-01-30 4:38 ` Peter Todd
2024-01-30 5:07 ` ZmnSCPxj
2024-01-30 5:17 ` ZmnSCPxj
2024-01-30 5:55 ` Anthony Towns
2024-01-30 8:40 ` Peter Todd
2024-01-25 17:49 ` [bitcoin-dev] " jlspc
2024-01-30 4:49 ` Peter Todd
2024-02-20 23:13 ` [bitcoindev] " 'jlspc' via Bitcoin Development Mailing List
2024-01-27 6:28 ` Brandon Black
2024-01-30 4:46 ` Peter Todd
[not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
2024-01-30 4:41 ` Peter Todd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zbh9+oNDuPEapFwQ@petertodd.org \
--to=pete@petertodd.org \
--cc=alicexbt@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox