public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jlspc <jlspc@protonmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Date: Thu, 25 Jan 2024 17:49:26 +0000	[thread overview]
Message-ID: <Gr0X5c-3nQcx-VLD3eQ-e0DoOFim5gUKeyOF5ViYPfjE030KB4QJ2tVyA4wfY64Um_zo0fTfjqkTN11-RcvDeiAVhE2_9VYcQ3kSGFD1dug=@protonmail.com> (raw)
In-Reply-To: <ZbFle6n0Zu3yUV8o@petertodd.org>

Hi Peter,

If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible to use CTV to define a transaction with a fixed fee and no anchor outputs, as long as it's racing against a transaction with an FDT.

Regards,
John

(1) https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html




Sent with Proton Mail secure email.

On Wednesday, January 24th, 2024 at 11:31 AM, 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


  parent reply	other threads:[~2024-01-25 17:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24 19:31 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 ` jlspc [this message]
2024-01-30  4:49   ` [bitcoin-dev] " 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='Gr0X5c-3nQcx-VLD3eQ-e0DoOFim5gUKeyOF5ViYPfjE030KB4QJ2tVyA4wfY64Um_zo0fTfjqkTN11-RcvDeiAVhE2_9VYcQ3kSGFD1dug=@protonmail.com' \
    --to=jlspc@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=pete@petertodd$(echo .)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