š
Original date posted:2015-07-10
š Original message:I think the biggest problem with merging CPFP right now is that at least in
its current implementation it is not efficient enough in certain
situations,.
On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier <
justus at openbitcoinprivacyproject.org> wrote:
> On 07/10/2015 11:31 AM, Jeff Garzik wrote:
> > This is a good explanation but it does not address reachability. TX_a,
> the
> > first tx sent out on the network, presumably has insufficient fee to get
> > mined - which also means it did not necessarily even reach all miners.
> >
> > Simply sending out TX_b with added fee does not guarantee that nodes
> > suddenly have TX_a, which they may have ignored/dropped before.
>
> I'm not sure why that's actually a problem.
>
> CPFP is initiated by the recipient of the parent transaction, and so if
> the recipient is creating this transaction in the first place they must
> have a copy of the parent transaction which can/should broadcast at the
> same time.
>
> If the child reaches a CPFP miner, then presumably the parents made it
> as well (any path between the sender and the miner that doesn't relay
> the parent should reject the child as trying to spend non-existent
> coins), so both of the transactions can be mined at the same time.
>
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus at openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
>
> _______________________________________________
> 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/4b36fab9/attachment.html>;
Alex Morcos [ARCHIVE] /
npub10zā¦3xfzw
2023-06-07 15:41:53
in reply to nevent1qā¦2pyg
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwPublished at
2023-06-07 15:41:53Event JSON
{
"id": "8a1d2a31d8f6c729b4aba7dca1f87df98b55d1c02dc99bcbd4d98926a968829e",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686152513,
"kind": 1,
"tags": [
[
"e",
"bfd4714bb94a189208ff2ce68134800f654e20d12d58c5096abb21e63eaebf75",
"",
"root"
],
[
"e",
"63bb7be76ac0195a6fead92b690ed6419f81ef8e5267002f9e711226d84ca03f",
"",
"reply"
],
[
"p",
"bbe41ddf98a712e588455717ec8f3f0893c530699af0a98cbe86c0af0138b25d"
]
],
"content": "š
Original date posted:2015-07-10\nš Original message:I think the biggest problem with merging CPFP right now is that at least in\nits current implementation it is not efficient enough in certain\nsituations,.\n\nOn Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier \u003c\njustus at openbitcoinprivacyproject.org\u003e wrote:\n\n\u003e On 07/10/2015 11:31 AM, Jeff Garzik wrote:\n\u003e \u003e This is a good explanation but it does not address reachability. TX_a,\n\u003e the\n\u003e \u003e first tx sent out on the network, presumably has insufficient fee to get\n\u003e \u003e mined - which also means it did not necessarily even reach all miners.\n\u003e \u003e\n\u003e \u003e Simply sending out TX_b with added fee does not guarantee that nodes\n\u003e \u003e suddenly have TX_a, which they may have ignored/dropped before.\n\u003e\n\u003e I'm not sure why that's actually a problem.\n\u003e\n\u003e CPFP is initiated by the recipient of the parent transaction, and so if\n\u003e the recipient is creating this transaction in the first place they must\n\u003e have a copy of the parent transaction which can/should broadcast at the\n\u003e same time.\n\u003e\n\u003e If the child reaches a CPFP miner, then presumably the parents made it\n\u003e as well (any path between the sender and the miner that doesn't relay\n\u003e the parent should reject the child as trying to spend non-existent\n\u003e coins), so both of the transactions can be mined at the same time.\n\u003e\n\u003e --\n\u003e Justus Ranvier\n\u003e Open Bitcoin Privacy Project\n\u003e http://www.openbitcoinprivacyproject.org/\n\u003e justus at openbitcoinprivacyproject.org\n\u003e E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623\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/4b36fab9/attachment.html\u003e",
"sig": "65857ca6c2767b36f98c805e392f21cacafd18412083dc5eb2f2a17b0b437d685bee0efb0eea24a3b5895821f5e3c3e048482f87788f7426a4568c0959ce83d1"
}