How robust is 1p1c transaction relay in bitcoin core 28.0?
Question
I’m reading the description of PR [28970
Rationale: This is "non-robust 1-parent-1-child package relay" which is immediately useful.
A couple of questions:
What exactly does non-robust mean in this context? What risks do I take on if I just rely on the normal CPFP-based flow? Are there situations where my parent transaction could still fail to confirm?
From the 28.0 release notes, it looks like Bitcoin Core 28.0 will automatically form a 1p1c package when I broadcast transactions via sendrawtransaction. Is that correct, or do I need to use the package relay APIs explicitly?
Answer 1
What exactly does non-robust mean in this context?
Non-robust means "not guaranteed to work, particularly in the presence of adversaries or when volume is really high so we miss things." Also, "package relay" in quotes refers to the fact that there isn't a package relay protocol, just an opportunistic piece of logic that can see when an orphanage transaction happens to be CPFPing a transaction that failed for being low feerate.
Perhaps a good analogy is if you're a restaurant cook that doesn't have a dedicated server. You can opportunistically bring food to tables when you finish cooking them, which is often fine, but you'll fall behind during rush hour. The ticket system also doesn't rate-limit: when you can't hold all the tickets, random ones fall to the ground and you forget those orders. One annoying customer can ruin others' dining experience by ordering 100 diet cokes.
We can hire another person to serve food, which will certainly make the restaurant more efficient (e.g. BIP 331, still WIP) but doesn't solve everything. From 30.0, we'll have a strategy that rate-limits customers to ensure we don't forget anybody's order unless they send huge volumes (see "p2p: improve TxOrphanage denial of service bounds" https://github.com/bitcoin/bitcoin/pull/31829).
Are there situations where my parent transaction could still fail to confirm?
The most important restriction in 28.0 is that cooks can only serve very simple things (1p1c packages). Nothing beyond 1p1c works. If the child has another unconfirmed parent, even if it's already in mempools, the opportunistic logic doesn't work. This has changed as well ("package validation: relax the package-not-child-with-unconfirmed-parents rule" https://github.com/bitcoin/bitcoin/pull/31385).
Bitcoin Core 28.0 will automatically form a 1p1c package when I broadcast transactions via sendrawtransaction
That's correct: once you've submitted the transactions to your mempool, nodes will do everything automatically. If it's a 0-fee parent + child package, sendrawtransaction might complain about the fee, so you might want to use the submitpackage RPC (the multi-transaction equivalent of sendrawtransaction with a very similar API). The RPC accepts single transactions as well, so it might be most convenient to use all the time.