public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoindev] TRUC and P2A for CTV fee management
@ 2024-12-18  0:25 'stutxo' via Bitcoin Development Mailing List
  2024-12-21  3:07 ` [bitcoindev] " /dev /fd0
  0 siblings, 1 reply; 3+ messages in thread
From: 'stutxo' via Bitcoin Development Mailing List @ 2024-12-18  0:25 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2188 bytes --]

Hi everyone,

I am trying to learn more about op_ctv (or its true name, op_securethebag). 
One thing I keep hearing is that estimating fees are potentially an issue 
when spending CTV transactions. 

jamesob mentioned fees in his simple_ctv_valut 
<https://github.com/jamesob/simple-ctv-vault>

*Because coins may remain vaulted for long periods of time, the unvault 
process is sensitive to changes in the fee market. Because use of OP_CTV 
requires precommiting to a tree of all possible specific outputs and the 
number of inputs, we cannot use RBF to dynamically adjust feerate of 
unvaulting transactions.*
and rustyrussell on nostr also mentioned fees being a problem 
<https://primal.net/e/note1ulw6tr8hrqz092wy02fcyshn3fgt309kc5w95mhl7j0shj7c9zxsu8a2mw>
 
*Optimised sponsors for solving the "but how do I add fees" problem in a 
way that doesn't drive miner centralisation.*

With v3 transactions available in bitcoin 28.0 
<https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/>there 
are a bunch of new techniques that have been enabled that we can use to 
hopefully solve these issues

As long as you have an output for 240 sats paying to a P2A address, such as 
tb1pfees9rn5nz on signet, you or anyone else will be able to bump the fees 
using CPFP on the anchor output. 

I have some examples of these transactions here on signet

CTV spend transaction with zero fees:
https://mempool.space/signet/tx/32f4f4e6165e7f8df9b9a762e11a6ca7f16087713e0e3e42352021e6bf3800e3

P2A CPFP transaction:
https://mempool.space/signet/tx/9a3582f03b0ac39cff8ed024cf8f38e4fc4a1ee2ff216badf041bf4572c0d03b

Code used is here:
https://github.com/stutxo/simple_ctv

Is there anything I am missing here? What are the downsides of this method? 
Is this how most ctv scripts spends would work?

Thanks!
stu

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5565b149-48b7-4823-9363-89cfd70ecf09n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2684 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [bitcoindev] Re: TRUC and P2A for CTV fee management
  2024-12-18  0:25 [bitcoindev] TRUC and P2A for CTV fee management 'stutxo' via Bitcoin Development Mailing List
@ 2024-12-21  3:07 ` /dev /fd0
  2024-12-31  0:57   ` 'stutxo' via Bitcoin Development Mailing List
  0 siblings, 1 reply; 3+ messages in thread
From: /dev /fd0 @ 2024-12-21  3:07 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2934 bytes --]

Hi stu,

Thanks for testing packages and P2A with CHECKTEMPLATEVERIFY on signet. 

This example in the README looks incorrect:

> ### Bumping Fee by Deducting Fee from CTV Output
> For some reason if you still wanted to pay the fee with just the ctv 
ouput you could take it from the output value
> - [bump fee without extra input or child transaction: Parent Transaction 
on Mempool 
Space](https://mempool.space/signet/tx/86896275fb71d4e3b84d1edeeacb90f7c4ccf77ee3a29e66d7effff4bb0682fb)

/dev/fd0
flopppy disk guy

On Wednesday, December 18, 2024 at 5:57:19 AM UTC+5:30 stutxo wrote:

> Hi everyone,
>
> I am trying to learn more about op_ctv (or its true name, 
> op_securethebag). One thing I keep hearing is that estimating fees are 
> potentially an issue when spending CTV transactions. 
>
> jamesob mentioned fees in his simple_ctv_valut 
> <https://github.com/jamesob/simple-ctv-vault>
>
> *Because coins may remain vaulted for long periods of time, the unvault 
> process is sensitive to changes in the fee market. Because use of OP_CTV 
> requires precommiting to a tree of all possible specific outputs and the 
> number of inputs, we cannot use RBF to dynamically adjust feerate of 
> unvaulting transactions.*
> and rustyrussell on nostr also mentioned fees being a problem 
> <https://primal.net/e/note1ulw6tr8hrqz092wy02fcyshn3fgt309kc5w95mhl7j0shj7c9zxsu8a2mw>
>  
> *Optimised sponsors for solving the "but how do I add fees" problem in a 
> way that doesn't drive miner centralisation.*
>
> With v3 transactions available in bitcoin 28.0 
> <https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/>there 
> are a bunch of new techniques that have been enabled that we can use to 
> hopefully solve these issues
>
> As long as you have an output for 240 sats paying to a P2A address, such 
> as tb1pfees9rn5nz on signet, you or anyone else will be able to bump the 
> fees using CPFP on the anchor output. 
>
> I have some examples of these transactions here on signet
>
> CTV spend transaction with zero fees:
>
> https://mempool.space/signet/tx/32f4f4e6165e7f8df9b9a762e11a6ca7f16087713e0e3e42352021e6bf3800e3
>
> P2A CPFP transaction:
>
> https://mempool.space/signet/tx/9a3582f03b0ac39cff8ed024cf8f38e4fc4a1ee2ff216badf041bf4572c0d03b
>
> Code used is here:
> https://github.com/stutxo/simple_ctv
>
> Is there anything I am missing here? What are the downsides of this 
> method? Is this how most ctv scripts spends would work?
>
> Thanks!
> stu
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fff33085-ca24-4553-9fa8-de8d60e8a9bfn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5295 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [bitcoindev] Re: TRUC and P2A for CTV fee management
  2024-12-21  3:07 ` [bitcoindev] " /dev /fd0
@ 2024-12-31  0:57   ` 'stutxo' via Bitcoin Development Mailing List
  0 siblings, 0 replies; 3+ messages in thread
From: 'stutxo' via Bitcoin Development Mailing List @ 2024-12-31  0:57 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3717 bytes --]

thanks floppy disk guy, 

i updated this example with the correct way a single 1c1p spend with no p2a 
would look like

parent
https://mempool.space/signet/tx/7a3768737ae4e20a556de6f475bfc74a13a8fda2287dbabbf6ffe8d7f5500de2

child
https://mempool.space/signet/tx/3135e52ad30eb788d455549f4f09b55f887cdd2eb1660180b0e12f10af807cf5

Although im not sure how useful this one is, i guess its nice because you 
can still get the parent transaction in to the mempool even with 0 fees 

I also added an example of v3 transactions and p2a to my ctv payment pool 
PoC here https://github.com/stutxo/op_ctv_payment_pool 

On Saturday, December 21, 2024 at 4:42:08 AM UTC /dev /fd0 wrote:

> Hi stu,
>
> Thanks for testing packages and P2A with CHECKTEMPLATEVERIFY on signet. 
>
> This example in the README looks incorrect:
>
> > ### Bumping Fee by Deducting Fee from CTV Output
> > For some reason if you still wanted to pay the fee with just the ctv 
> ouput you could take it from the output value
> > - [bump fee without extra input or child transaction: Parent Transaction 
> on Mempool Space](
> https://mempool.space/signet/tx/86896275fb71d4e3b84d1edeeacb90f7c4ccf77ee3a29e66d7effff4bb0682fb
> )
>
> /dev/fd0
> flopppy disk guy
>
> On Wednesday, December 18, 2024 at 5:57:19 AM UTC+5:30 stutxo wrote:
>
>> Hi everyone,
>>
>> I am trying to learn more about op_ctv (or its true name, 
>> op_securethebag). One thing I keep hearing is that estimating fees are 
>> potentially an issue when spending CTV transactions. 
>>
>> jamesob mentioned fees in his simple_ctv_valut 
>> <https://github.com/jamesob/simple-ctv-vault>
>>
>> *Because coins may remain vaulted for long periods of time, the unvault 
>> process is sensitive to changes in the fee market. Because use of OP_CTV 
>> requires precommiting to a tree of all possible specific outputs and the 
>> number of inputs, we cannot use RBF to dynamically adjust feerate of 
>> unvaulting transactions.*
>> and rustyrussell on nostr also mentioned fees being a problem 
>> <https://primal.net/e/note1ulw6tr8hrqz092wy02fcyshn3fgt309kc5w95mhl7j0shj7c9zxsu8a2mw>
>>  
>> *Optimised sponsors for solving the "but how do I add fees" problem in a 
>> way that doesn't drive miner centralisation.*
>>
>> With v3 transactions available in bitcoin 28.0 
>> <https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/>there 
>> are a bunch of new techniques that have been enabled that we can use to 
>> hopefully solve these issues
>>
>> As long as you have an output for 240 sats paying to a P2A address, such 
>> as tb1pfees9rn5nz on signet, you or anyone else will be able to bump the 
>> fees using CPFP on the anchor output. 
>>
>> I have some examples of these transactions here on signet
>>
>> CTV spend transaction with zero fees:
>>
>> https://mempool.space/signet/tx/32f4f4e6165e7f8df9b9a762e11a6ca7f16087713e0e3e42352021e6bf3800e3
>>
>> P2A CPFP transaction:
>>
>> https://mempool.space/signet/tx/9a3582f03b0ac39cff8ed024cf8f38e4fc4a1ee2ff216badf041bf4572c0d03b
>>
>> Code used is here:
>> https://github.com/stutxo/simple_ctv
>>
>> Is there anything I am missing here? What are the downsides of this 
>> method? Is this how most ctv scripts spends would work?
>>
>> Thanks!
>> stu
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3642acab-e6c2-4c6b-b786-fa41a84cd51en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6609 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-12-31  1:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-12-18  0:25 [bitcoindev] TRUC and P2A for CTV fee management 'stutxo' via Bitcoin Development Mailing List
2024-12-21  3:07 ` [bitcoindev] " /dev /fd0
2024-12-31  0:57   ` 'stutxo' via Bitcoin Development Mailing List

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox