baby pays for mother or father – Is it okay to chain a number of unconfirmed transactions?
In precept this can work, however Bitcoin Core by default limits such chains: a transaction won’t enter a Bitcoin Core node’s mempool if it has greater than 25 ancestors, or greater than 25 descendants.
There are downsides to lengthy transaction chains within the face of swinging feerates. Firstly, if the feerates rise, you can’t merely bump a single extra pressing transaction—you’d should bump it and all of its ancestors. Secondly, transaction chaining is considerably incompatible with RBF—bumping any of the prior transactions breaks all of the later transactions as a result of their inputs stop to exist and you need to pay sufficient charges to switch the charges of all of the descendant transactions to get admitted to the mempool. Thirdly, if a node’s mempool runs out of area, it’s going to drop low feerate transactions first. If one among your prior transactions will get dropped, the whole chain following will probably be inadmissible to (default) mempools till we get one thing like package deal relay, or the mempool relaxes to a stage the place the transaction may be rebroadcast.
Methods to work round this are to all the time bump the mother or father transactions to the focused feerate of follow-up transactions (which isn’t trivial to calculate and should result in overpayment within the case of two youngsters to the identical ancestors), or to all the time have precisely one output from which you chain.
Within the case that you’ve got sufficient transaction quantity to warrant transaction chaining, I’d advocate that you just quite use cost batching: delay withdrawals (or different funds) by a couple of minutes, however then do a number of in a single transaction. Cost batching has a a lot smaller blockweight footprint per cost (and thus decrease charges per cost), makes UTXO administration a lot simpler, since you want fewer inputs per cost, have much less funds in flight since you solely create a single change output per batch as an alternative of per cost, and might perhaps forgo utilizing unconfirmed inputs altogether, which lets you use RBF and CPFP to bump transactions once they get delayed even whenever you begin them off with a lot decrease feerates.
Moreover, whereas chaining of transactions would begin to break down as a result of limits on ancestry sizes, cost batching simply will get extra environment friendly with larger quantity.
Secondly, will the chained transactions be mined on the identical block?
Sure, if the kid transaction pays the next feerate than its ancestors, they might seemingly be picked as a package deal primarily based on the descendant feerate. If later transactions pay the identical or a decrease feerate, a mother or father could also be included with out youngsters.