<p>I would recommend thinking about the feerate you are trying to calculate rather as a specific amount of fees plus a feerate:
The parent transaction is short a specific count of satoshis to have the desired feerate. It’s exactly that <code>bump_fee</code> in satoshis that the child has to pay more, in order to prioritize the parent to the desired feerate. Then the child itself has to pay the feerate that you are trying to bump the parent to, too.</p>
<pre><code>c_fee = (p_vsize × target_feerate) - p_fee + c_vsize × target_feerate
c_fee = bump_fee + c_vsize × target_feerate
</code></pre>
<p>Perhaps you can leverage your wallet software by constructing a raw transaction that uses the parent’s output as a preset input and sends the whole amountg to yourself at <code>target_feerate</code>. If you had that, you would only need to decrement the output to yourself by the <code>bump_fee</code>.</p>
<p>If you are trying to do this with Bitcoin Core, you could try my branch from pull request <a href="https://github.com/bitcoin/bitcoin/pull/26152" rel="nofollow noreferrer">#26152</a>, which aims to resolve exactly this issue.</p>

CC BY-SA 4.0
2023-03-21T22:28:40.107Z
Ah, very good. Thank you for your response. I guess where i am confused is where you would find the virtual size of the child (c_vsize) when the child hasnt been created yet. ill have to take a second and look at your pull request. i like the "Bump unconfirmed parent txs to target feerate" and "node interface to get bumped fees" that is essentially what i am trying to do is calculate target feerate (or fee in sats obviously can convert) of unconfirmed parent txs.
Joe T
CC BY-SA 4.0
2023-03-21T22:36:09.333Z
You could calculate the vsize of the child if you know how many inputs and outputs it's going to use in advance, but that's often not obvious.
Murch
CC BY-SA 4.0
2023-03-21T16:03:55.970Z
2023-03-21T16:03:55.970Z
Murch
<p>so i know x = (sat/vB_effective * (vB_parent + vB_child) - current_parent_fee) / vB_child where x is the child fee (in sats/vbyte) that would need to get bumped. so this is figured off the child fee. What i would like to know is how to calculate how much to bump the change output to get the desired parent fee in sats/vbyte.</p>

<fee-estimation><child-pays-for-parent><bumpfee>
Is there a formula to know how much to bump your change input to get a desired sat/vbyte for P2TR transactions?
Joe T
# Is there a formula to know how much to bump your change input to get a desired sat/vbyte for P2TR transactions?

(Asked by: username_0 on 2023-03-21)

so i know x = (sat/vB\_effective \* (vB\_parent + vB\_child) - current\_parent\_fee) / vB\_child where x is the child fee (in sats/vbyte) that would need to get bumped. so this is figured off the child fee. What i would like to know is how to calculate how much to bump the change output to get the desired parent fee in sats/vbyte.

**Tags:** fee-estimation, child-pays-for-parent, bumpfee


---

## 1 answers

### Answer by username_1 on 2023-03-21. Score: 0 | Accepted answer

I would recommend thinking about the feerate you are trying to calculate rather as a specific amount of fees plus a feerate:
The parent transaction is short a specific count of satoshis to have the desired feerate. It’s exactly that `bump_fee` in satoshis that the child has to pay more, in order to prioritize the parent to the desired feerate. Then the child itself has to pay the feerate that you are trying to bump the parent to, too.

```
c_fee = (p_vsize × target_feerate) - p_fee + c_vsize × target_feerate
c_fee = bump_fee + c_vsize × target_feerate

```

Perhaps you can leverage your wallet software by constructing a raw transaction that uses the parent’s output as a preset input and sends the whole amountg to yourself at `target_feerate`. If you had that, you would only need to decrement the output to yourself by the `bump_fee`.

If you are trying to do this with Bitcoin Core, you could try my branch from pull request [#26152](https://github.com/bitcoin/bitcoin/pull/26152), which aims to resolve exactly this issue.

> **Comments:**
> **username_0**: Ah, very good. Thank you for your response. I guess where i am confused is where you would find the virtual size of the child (c_vsize) when the child hasnt been created yet. ill have to take a second and look at your pull request. i like the "Bump unconfirmed parent txs to target feerate" and "node interface to get bumped fees" that is essentially what i am trying to do is calculate target feerate (or fee in sats obviously can convert) of unconfirmed parent txs.  
> **username_1**: You could calculate the vsize of the child if you know how many inputs and outputs it's going to use in advance, but that's often not obvious.  

---

