Batch tx broadcast RPC

[TheBlueMatt]

Please describe the feature you'd like to see added.

The intent of #31085 wasn't really just to be able to broadcast a "package" of size 1, but that it would be nice if the caller of submitpackage didn't need to sit down and figure out/make sure all their broadcasts match exactly some BIP-defined structure. Ideally I just give Bitcoin Core a pile of transactions and it figures it out - if there's two children and two parents it broadcasts them as two packages, etc. Maybe this is just something we get for "free" with cluster mempool and larger package relay (as long as the transactions are even related to each other, though it'd be kinda nice for Bitcoin Core to figure that out too), but any restrictions in submitpackage ultimately filter down through the ecosystem and imply restrictions on hundreds of internal interfaces (eg the LDK BroadcasterInterface) and APIs (eg Esplora/Electrum implementations will generally just call that method), so it'd be nice to be as generic as possible.

Is your feature related to a problem, if so please describe it.

No response

Describe the solution you'd like

No response

Describe any alternatives you've considered

No response

Please leave any additional context

No response

[TheBlueMatt]

Oh, maybe the most important relaxation would be to remove the topological-sort requirement.

[glozow]

This definitely seems doable. A couple more API questions since you're here:
What would you prefer to happen if a transaction fails? Is it fine if we quit altogether or do you want the node to keep trying with everything else?
We currently just have an error message that's just passed/failed. Would this change work: all passed / some passed / you submitted invalid stuff / maxfeerate or maxburnamount exceeded ?
Are you ok with some requirements, e.g. "your batch contains transactions that conflict with each other?"

[ajtowns]

I'd contend that if you could make a p2p connection, announce INV tx1 tx2 ... and reply to GETDATA requests (or BIP331 messages or whatever we add in future), and get your txs added to the node's mempool and relayed onwards, then you should be able to get the same result with a simple RPC call.

For errors, I think it would be preferable to have a parameter that decides whether the behaviour should be "only accept anything if you can accept everything" or "accept as much as you can and tell me what failed and why, including giving me the txid of any in-mempool conflicts".

For txs that won't relay currently (eg grandparent, parent below mempool minfee, child cpfp's both?), I think this should give an error, rather than doing any special handling that will still only add the txs to this node's mempool.