From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 30 Dec 2024 17:05:50 -0800 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tSQhh-0002EU-QR for bitcoindev@gnusha.org; Mon, 30 Dec 2024 17:05:50 -0800 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e35e0e88973sf20535641276.0 for ; Mon, 30 Dec 2024 17:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1735607143; x=1736211943; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=5audkOedlEGtuPQ3NOeYS7C2hMxVQ5EzrOjz0pAUxgs=; b=Qcf6CwkYx1ggTvNvGo6a1THBgq5sDxJQwjltMZPtCc8Gv/M1I5Yik5jVzkT/8wtN5B QRtFP7kjJzjmTiP1Yfc85aql9M4OBEbrueBJZtu/pvIFQXpn+vTao4VvfeTM0bvme0DZ 3ukukZf1PiIvRy2zHcaXWrRRMQazyczeUr4SZCKoqp+cg8DlncdXSWHoIQQvs90NgT9c rW+8EmLQdSgrp4LYxByDxnc8eaCF7tHdBv4dJtpTsOdn+rq+I+VCBcjLej5sBU736m4f oxmpUYyePWKgQXdMAw5Kpamb4IKU3GIcSXhtJMoKS4hQpRmpyxYTgfbeO+fQGpErKUFN L5Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735607143; x=1736211943; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5audkOedlEGtuPQ3NOeYS7C2hMxVQ5EzrOjz0pAUxgs=; b=cA+DWtg5UruTVxwDOXWeTQ0C0LMPoUZsG6ig/B1YG8OPK3aKg1pYYy9SP6s5+lEPDI Don1QTK6vBVu7Ypx+/MpNGKS7ybwZvnPrgGgl/F/4XtV9o1YakoUXo8u4EXmNKWNm0SZ VCkImaTXtpluqS1GP5slBppAe2vFvZ9cN8u1YDidqTz775CSORqDQYdr7QE45V6pC3BH DDBKAXbRjgazWaRK9tp6dD1QRDtRSx8/dc13JQQvG/VcJ15BUYVM7DDKhrxHaNcpmibq FbVurKcbfskGMOPjDumTU/DTvDHAdK3Uh+qeGrps839ZczdG9ZN/m+2EkH7L45WjmPKa I4Cg== X-Forwarded-Encrypted: i=1; AJvYcCVBI1WOB55ocdPL2dBdI59y6AQQJeSlvEKYrxrG6n1JRsindn+isRrJARzSTialhj/0HzIdzxM0Xxl3@gnusha.org X-Gm-Message-State: AOJu0Yzic/Yq8N69mr9Ckgm5lYCkHqfDnliy4rEieYBUQnnSSVcy2HFo iYwSEdytcHWTU7tzi/XAkpvmcZ3UWy5OF+FqY3K2/BUZaYg2uusj X-Google-Smtp-Source: AGHT+IFnhGCmkoAZJ++I8F2h76HCg/lUgbU1NSoyRZ6weErsySq8BQvxSeon1hD5TQ1xs5N/4DkRWQ== X-Received: by 2002:a25:2e41:0:b0:e38:9227:bf06 with SMTP id 3f1490d57ef6-e5376537618mr29639101276.2.1735607142892; Mon, 30 Dec 2024 17:05:42 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:ad4f:0:b0:e30:e1d9:fe2c with SMTP id 3f1490d57ef6-e5375fdb221ls1274494276.1.-pod-prod-03-us; Mon, 30 Dec 2024 17:05:39 -0800 (PST) X-Received: by 2002:a05:690c:6911:b0:6ef:6ba2:e823 with SMTP id 00721157ae682-6f3f8115d16mr238964967b3.11.1735607139399; Mon, 30 Dec 2024 17:05:39 -0800 (PST) Received: by 2002:a81:ad03:0:b0:6ef:892f:89f3 with SMTP id 00721157ae682-6f3f57ea50dms7b3; Mon, 30 Dec 2024 16:57:17 -0800 (PST) X-Received: by 2002:a05:690c:c93:b0:6ef:6f24:d0bc with SMTP id 00721157ae682-6f3f820176fmr235162507b3.27.1735606636221; Mon, 30 Dec 2024 16:57:16 -0800 (PST) Date: Mon, 30 Dec 2024 16:57:15 -0800 (PST) From: "'stutxo' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <3642acab-e6c2-4c6b-b786-fa41a84cd51en@googlegroups.com> In-Reply-To: References: <5565b149-48b7-4823-9363-89cfd70ecf09n@googlegroups.com> Subject: [bitcoindev] Re: TRUC and P2A for CTV fee management MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_649892_782734403.1735606635960" X-Original-Sender: stu@zebedee.io X-Original-From: stutxo Reply-To: stutxo Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) ------=_Part_649892_782734403.1735606635960 Content-Type: multipart/alternative; boundary="----=_Part_649893_966063723.1735606635960" ------=_Part_649893_966063723.1735606635960 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks floppy disk guy,=20 i updated this example with the correct way a single 1c1p spend with no p2a= =20 would look like parent https://mempool.space/signet/tx/7a3768737ae4e20a556de6f475bfc74a13a8fda2287= dbabbf6ffe8d7f5500de2 child https://mempool.space/signet/tx/3135e52ad30eb788d455549f4f09b55f887cdd2eb16= 60180b0e12f10af807cf5 Although im not sure how useful this one is, i guess its nice because you= =20 can still get the parent transaction in to the mempool even with 0 fees=20 I also added an example of v3 transactions and p2a to my ctv payment pool= =20 PoC here https://github.com/stutxo/op_ctv_payment_pool=20 On Saturday, December 21, 2024 at 4:42:08=E2=80=AFAM UTC /dev /fd0 wrote: > Hi stu, > > Thanks for testing packages and P2A with CHECKTEMPLATEVERIFY on signet.= =20 > > 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=20 > ouput you could take it from the output value > > - [bump fee without extra input or child transaction: Parent Transactio= n=20 > on Mempool Space]( > https://mempool.space/signet/tx/86896275fb71d4e3b84d1edeeacb90f7c4ccf77ee= 3a29e66d7effff4bb0682fb > ) > > /dev/fd0 > flopppy disk guy > > On Wednesday, December 18, 2024 at 5:57:19=E2=80=AFAM UTC+5:30 stutxo wro= te: > >> Hi everyone, >> >> I am trying to learn more about op_ctv (or its true name,=20 >> op_securethebag). One thing I keep hearing is that estimating fees are= =20 >> potentially an issue when spending CTV transactions.=20 >> >> jamesob mentioned fees in his simple_ctv_valut=20 >> >> >> *Because coins may remain vaulted for long periods of time, the unvault= =20 >> process is sensitive to changes in the fee market. Because use of OP_CTV= =20 >> requires precommiting to a tree of all possible specific outputs and the= =20 >> number of inputs, we cannot use RBF to dynamically adjust feerate of=20 >> unvaulting transactions.* >> and rustyrussell on nostr also mentioned fees being a problem=20 >> >> =20 >> *Optimised sponsors for solving the "but how do I add fees" problem in a= =20 >> way that doesn't drive miner centralisation.* >> >> With v3 transactions available in bitcoin 28.0=20 >> the= re=20 >> are a bunch of new techniques that have been enabled that we can use to= =20 >> hopefully solve these issues >> >> As long as you have an output for 240 sats paying to a P2A address, such= =20 >> as tb1pfees9rn5nz on signet, you or anyone else will be able to bump the= =20 >> fees using CPFP on the anchor output.=20 >> >> I have some examples of these transactions here on signet >> >> CTV spend transaction with zero fees: >> >> https://mempool.space/signet/tx/32f4f4e6165e7f8df9b9a762e11a6ca7f1608771= 3e0e3e42352021e6bf3800e3 >> >> P2A CPFP transaction: >> >> https://mempool.space/signet/tx/9a3582f03b0ac39cff8ed024cf8f38e4fc4a1ee2= ff216badf041bf4572c0d03b >> >> Code used is here: >> https://github.com/stutxo/simple_ctv >> >> Is there anything I am missing here? What are the downsides of this=20 >> method? Is this how most ctv scripts spends would work? >> >> Thanks! >> stu >> > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 3642acab-e6c2-4c6b-b786-fa41a84cd51en%40googlegroups.com. ------=_Part_649893_966063723.1735606635960 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks floppy disk guy,=C2=A0

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

parent=
https://mempool.space/signet/tx/7a3768737ae4e20a556de6f475bfc74a13a8f= da2287dbabbf6ffe8d7f5500de2

child
https://mempool.space/sig= net/tx/3135e52ad30eb788d455549f4f09b55f887cdd2eb1660180b0e12f10af807cf5

Although im not sure how useful this one is, i guess its nice becau= se you can still get the parent transaction in to the mempool even with 0 f= ees=C2=A0

I also added an example of v3 transactions and p2a to = my ctv payment pool PoC here=C2=A0https://github.com/stutxo/op_ctv_payment_= pool=C2=A0

On Saturday, December 21, 2024 at 4:42:08=E2=80=AFAM UTC /dev = /fd0 wrote:
H= i stu,

Thanks for testing packages and P2A with CHECKTEM= PLATEVERIFY on signet.=C2=A0

This example in the README looks incorr= ect:

> ### 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 e= xtra input or child transaction: Parent Transaction on Mempool Space](https://mempool.space/signet/tx/86896275fb71d4e3b84d1edeeacb9= 0f7c4ccf77ee3a29e66d7effff4bb0682fb)

/dev/fd0
flopppy = disk guy

On Wednesday, December 18, 2024 at 5:57:19=E2=80=AFAM U= TC+5:30 stutxo wrote:
= Hi everyone,

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

ja= mesob=C2=A0mentioned fees in his simple_ctv_valut
Because coins may remain va= ulted 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 o= f all possible specific outputs and the number of inputs, we cannot use RBF= to dynamically adjust feerate of unvaulting transactions.

and r= ustyrussell on nostr also mentioned fees being a problem=C2=A0
Optimi= sed 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 = 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, yo= u or anyone else will be able to bump the fees using CPFP on the anchor out= put.=C2=A0

I have some examples of these transactions here on= signet


Is there anything I am missing h= ere? What are the downsides of this method? Is this how most ctv scripts sp= ends would work?

Thanks!
stu

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/3642acab-e6c2-4c6b-b786-fa41a84cd51en%40googlegroups.com.
------=_Part_649893_966063723.1735606635960-- ------=_Part_649892_782734403.1735606635960--