On Thu, Jan 25, 2024 at 05:49:26PM +, jlspc wrote:
> 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.
On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote:
> Hi Peter,
>
> On 2024-01-24 (Wed) at 19:31:07 +, Peter Todd via bitcoin-dev wrote:
> > 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
On Sat, Jan 27, 2024 at 05:50:27PM +, 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
Hi Peter,
On 2024-01-24 (Wed) at 19:31:07 +, Peter Todd via bitcoin-dev wrote:
> 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
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)
Hi Peter
Interesting post. By implicitly committing in advance to the fee paid by the
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
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
