From: Peter Todd <pete@petertodd•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Date: Wed, 24 Jan 2024 19:31:07 +0000 [thread overview]
Message-ID: <ZbFle6n0Zu3yUV8o@petertodd.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2024-01-24 19:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 19:31 Peter Todd [this message]
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
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=ZbFle6n0Zu3yUV8o@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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