📅 Original date posted:2015-07-10 📝 Original message:CPFP is interesting, but ...

Jeff Garzik [ARCHIVE] /

npub1kf0…3f58

2023-06-07 15:41:51

in reply to nevent1q…rx27

📅 Original date posted:2015-07-10
📝 Original message:CPFP is interesting, but it does not fully cover the case it is trying to
address: If TX_a goes out without sufficient fee, sending out a new TX_b
will not help TX_a suddenly reach nodes/miners that ignored TX_a.

On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me at ricmoo.com> wrote:

> Hey guys,
>
> With all the recent congestion and discussion regarding FSS-RBF, I was
> wondering if there good reasons not to have CPFP as a default policy? Or is
> it?
>
> I was also wondering, with CPFP, should the transaction fee be based on
> total transactions size, or the sum of each transaction’s required fee? For
> example, a third transaction C whose unconfirmed utxo from transaction B
> has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed),
> with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001
> btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for
> the 3 transactions it is going to commit.
>
> I tried to test it out a few days ago, sending 0.0008 btc without any fee,
> then that utxo into another transaction w/ 0.0001 btc. It still hasn’t
> confirmed, which could be any of: a) CPFP doesn’t have enough hash power,
> b) the amounts are too small, c) the coins are too new, d) the fee should
> have actually been 0.0002 btc, e) the congestion is just too great; or some
> combination.
>
> Just curious as whatnot…
>
> Thanks,
> RicMoo
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo at geneticmistakes.com
> www: http://GeneticMistakes.com
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/5fb1e521/attachment.html>;

Author Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 15:41:51

Kind type

1 Short Text Note

Event JSON

{ "id": "f0f84152e5fefa664551d40de094c7c156c2e31c458896885e4186facd055eb2", "pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11", "created_at": 1686152511, "kind": 1, "tags": [ [ "e", "bfd4714bb94a189208ff2ce68134800f654e20d12d58c5096abb21e63eaebf75", "", "root" ], [ "e", "89e97d305b040216e57d91228619b526622bef09984a883bc95789699e900ac4", "", "reply" ], [ "p", "1981fc26b3575cfe0cdafd51e1cac49a0eda39ffb00379f4981e2e4bc5aeb2c5" ] ], "content": "📅 Original date posted:2015-07-10\n📝 Original message:CPFP is interesting, but it does not fully cover the case it is trying to\naddress: If TX_a goes out without sufficient fee, sending out a new TX_b\nwill not help TX_a suddenly reach nodes/miners that ignored TX_a.\n\n\nOn Fri, Jul 10, 2015 at 12:09 PM, Richard Moore \u003cme at ricmoo.com\u003e wrote:\n\n\u003e Hey guys,\n\u003e\n\u003e With all the recent congestion and discussion regarding FSS-RBF, I was\n\u003e wondering if there good reasons not to have CPFP as a default policy? Or is\n\u003e it?\n\u003e\n\u003e I was also wondering, with CPFP, should the transaction fee be based on\n\u003e total transactions size, or the sum of each transaction’s required fee? For\n\u003e example, a third transaction C whose unconfirmed utxo from transaction B\n\u003e has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed),\n\u003e with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001\n\u003e btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for\n\u003e the 3 transactions it is going to commit.\n\u003e\n\u003e I tried to test it out a few days ago, sending 0.0008 btc without any fee,\n\u003e then that utxo into another transaction w/ 0.0001 btc. It still hasn’t\n\u003e confirmed, which could be any of: a) CPFP doesn’t have enough hash power,\n\u003e b) the amounts are too small, c) the coins are too new, d) the fee should\n\u003e have actually been 0.0002 btc, e) the congestion is just too great; or some\n\u003e combination.\n\u003e\n\u003e Just curious as whatnot…\n\u003e\n\u003e Thanks,\n\u003e RicMoo\n\u003e\n\u003e .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸\u003e\u003c(((º\u003e\n\u003e\n\u003e Richard Moore ~ Founder\n\u003e Genetic Mistakes Software inc.\n\u003e phone: (778) 882-6125\n\u003e email: ricmoo at geneticmistakes.com\n\u003e www: http://GeneticMistakes.com\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/5fb1e521/attachment.html\u003e", "sig": "3d1ba5e3501b31e77ec36ee27af7e7c8aa3f10c2d97414cf285646ac5254f05fb3cba8f2bbe04e281bb11036ead6be5495d763293973b595aca66c312fa093fa" }