Date: Thu, 25 Jan 2024 12:57:52 +0000
To: Peter Todd <pete@petertodd.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
In-Reply-To: <ZbFle6n0Zu3yUV8o@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org,
 Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's
	Required For Fee Payment
Precedence: list

Hi Peter

Interesting post. By implicitly committing in advance to the fee paid by th=
e spending transaction CTV is certainly nailing its colors to the CPFP mast=
 rather than operating in a RBF world. And in a future high fee environment=
 (ignoring whatever is driving those high fees, monetary or non-monetary us=
e cases) as you state paying for an additional CPFP transaction is suboptim=
al rather than just replacing an existing unconfirmed transaction.=20

I did a cursory search to look for an in depth technical comparison of CPFP=
 and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [=
0]. In that he states his view that:

"If most nodes didn't enforce mandatory BIP125 signalling, RBF would be sup=
erior in all aspects to CPFP from the perspective of the emitter of transac=
tion. CPFP is much less efficient, and not always possible: you need the tr=
ansaction to have a change output and (at least at the time of writing [0])=
 the parent to pass policy checks on its own, for instance if it's below th=
e minimum feerate of most mempools on the network you won't be able to CPFP=
 it at the moment."

I assume that a CTV based LN-Symmetry also has this drawback when compared =
to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry co=
uld change the fees in every channel update based on what the current marke=
t fee rate was at the time of the update. In today's pre LN-Symmetry world =
you are always going to have justice transactions for revoked states that w=
ere constructed when the market fee rate was very different from the presen=
t day's market fee rate.

Thanks
Michael


[0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-=
cpfp-and-bip125-for-fee-bumping

--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F


Learn about Bitcoin: https://www.youtube.com/@portofbitcoin


On Wednesday, 24 January 2024 at 19:31, 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 intende=
d to
> allow multiple parties to share a single UTXO, it is difficult to impossi=
ble 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 inclu=
ding
> it in the CTV-committed transaction; or possibly, via a transaction spons=
or
> soft-fork.
>=20
> This poses a scalability problem: to be genuinely self-sovereign in a pro=
tocol
> with reactive security, such as Lightning, you must be able to get transa=
ctions
> 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 a=
t
> least one UTXO of suitable size to pay for those fees.
>=20
> 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 alternat=
ive is
> to use a third party to pay for the UTXO, eg via a LN payment, but at tha=
t
> point it would be more efficient to pay an out-of-band mining fee. That o=
f
> course is highly undesirable from a mining centralization perspective.(2)
>=20
> 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.
>=20
> 1) https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6=
d7e7605/bip-0119.mediawiki
> 2) https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a=
-danger-to-mining-decentralization
>=20
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev