Does descendant size affect transaction fees?

Question

While calculating the transaction fee miners usually take ancestor size into the account. But does the descendant/output also affect the transaction fee calculation? Is descendant count correlated to transaction fee in any way?

Answer 1

I assume that you are actually asking about the order in which miners include transactions into their block template. Miners will group each transaction with its ancestry. The effective fee rate of such a transaction group is Σ(fees)/Σ(size) over all transactions in the group.

Let's assume there are two transactions waiting, A and B, where B is a child of A via spending an output of A.

A: { size: 200 vB, fee: 4000 satoshi } ⇒ fee rate: 20 sats/vB
B: { size: 100 vB, fee: 500 satoshi } ⇒ fee rate: 5 sats/vB

The mining software now creates two transaction groups: { { A }, { A, B } }, (B cannot be included in a block without A, so it cannot be a group by itself). The effective fee rate of the first (single-element) group { A } is 20 sats/vB. The effective fee rate of the second transaction group { A, B } is 4500/300 = 15 sats/vB. From these groups, the miner picks the group that pays the highest fee rate { A } as long as it has enough room to be added to the block template. After that, it removes all transactions of that group from the transaction candidate set and recalculates the transaction groups. There is now only one group of transactions left: { { B } }. At this point { B } is picked into the block template.

So, in this example, the transaction A queues at an effective fee rate of 20 sats/vB, while B queues at an effective fee rate of 5 sats/vB. As the parent has a higher fee rate than the child, the causal order and fee rate order match, and B has no influence on A's priority or vice versa.

---

If instead B was paying a higher fee rate than A, e.g. in a child-pays-for-parent scenario, the following would happen:

A: { size: 200 vB, fee: 200 satoshi } ⇒ fee rate: 1 sats/vB
B: { size: 100 vB, fee: 2800 satoshi } ⇒ fee rate: 28 sats/vB

The mining software creates two sets again: { { A }, { A, B } }. The effective fee rate of the first set { A } is 1 sat/vB. The effective fee rate of the second transaction set { A, B } is 3000/300 = 10 sats/vB.

Since the transaction group of { A, B } now has a higher priority than { A } by itself, the transaction group is picked into the block template first. In this case, the child transaction's size is relevant for calculating the effective fee rate of { A, B }, so the size of the child transaction does have an effect on the parent transaction's block inclusion priority.

---

If I misunderstood and you meant whether a descendant transaction can influence the fee rate of a parent transaction on creation of the latter, the answer is "No!":
transactions are immutable upon creation (ignoring edge cases like third-party malleability). Since the transaction fee is defined as the difference between the sum of input values and the sum of output values, the transaction fee is set in stone the moment the transaction is created. A transaction's outputs cannot be spent before the transaction is created. Therefore, a transaction cannot have any descendants before it is created. A descendant transaction influencing the creation of its ancestor is therefore a temporal paradox.

Answer 2

While calculating the Transaction fee miners usually take Ancestor size into the account. But does the descendant/Output also effect the transaction fee calculation?

The descendant transaction(s) do not restrict the inclusion of the examined transaction in a block, while the ancestor transaction(s) do. Hence, it would seem rational for the miner to only do extra computation for ancestors (in addition scanning both ancestors and descendants for each transaction means walking through each transaction twice).

Are Descendants Count correlated to Transaction fee in any way?

"Any way" is pretty broad :

• Regarding miner incentive no
• Regarding mempool logic and relay policy yes

Answer 3

No it doesn't. Only the ancestor size is taken into account.