baby pays for guardian – Is it okay to chain a number of unconfirmed transactions?


In precept this may work, however Bitcoin Core by default limits such chains: a transaction is not going to 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 need to 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 must pay sufficient charges to exchange 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 will drop low feerate transactions first. If considered one of your prior transactions will get dropped, the complete chain following it will likely be inadmissible to (default) mempools till we get one thing like package deal relay, or the mempool relaxes to a degree the place the transaction may be rebroadcast.

Methods to work round this are to all the time bump the guardian 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 simply fairly use fee 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 fee (and thus decrease charges per fee), makes UTXO administration a lot simpler, since you want fewer inputs per fee, have much less funds in flight since you solely create a single change output per batch as a substitute of per fee, and may possibly 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 because of the limits on ancestry sizes, fee batching simply will get extra environment friendly with greater quantity.

Secondly, will the chained transactions be mined on the similar block?

Sure, if the kid transaction pays a better feerate than its ancestors, they might possible be picked as a package deal primarily based on the descendant feerate. If later transactions pay the identical or a decrease feerate, a guardian could also be included with out youngsters.

Supply hyperlink

Leave a reply