hey folks, hope you’re all doing well,
quick question for you all: can you actually change the fees on a transaction that’s already been sent to the mempool?
let’s say I made a transfer with some fees and now the suggested fees have gone up by 10. is there a way for me to bump my transaction fees up by that amount? is it doable?
appreciate any help!
Yes it is possible depending on the wallet you use. This feature is called the bumping of a transaction fee. Replace by fee (RBF) is used when you send a transaction and you find out that the fee was too low to get it confirmed at your specific Time. Using the RBF method will replace your transaction with another one with a higher fee either to the first address you sent the first transaction to or to another address.
This feature is not available on all wallet as such you need a wallet that supports it before you can do that. Example of this wallet is the electrum or BlueWallet
If your transaction has been flagged as RBF, you can replace it with a new one paying higher fee easily.
To be able to do so, you should use a wallet which supports RBF.
It may worth mentioning that there are many nodes that have enabled full RBF and accept the replacement transaction with a higher fee even if the original one has not been flagged as RBF.
You can use any of these wallets:
Bitcoin open source wallets that support replace-by-fee (RBF)
I can recommend: Electrum and Sparrow for desktop. Electrum, Bluewallet and Samourai for mobile.
If you use any of these wallets to make transaction, you can increase the transaction fee in a way the transaction will be replaced by new one with higher fee.
What exactly do you want to achieve? The link you provided is a rust library for Bitcoin.
Are you planning to develop a tool that can manually recreate transactions and change the fees?
Here's another tool to rebuild a transaction if you are planning to change your address or change the transaction fees then this tool below would work. Just make sure you download the page and make a copy of this on the offline machine to sign a transaction and only broadcast the transaction on an online device.
- https://coinb.in/#newTransaction
Open sourced here https://github.com/OutCast3k/coinbin/
It's irrelevant to your question about the link that you provided above, I opened it but it's a list of Rust Bitcoin and not talking about RBF transactions or how it works. Are you sure about this?
They are talking about RBF above or ReplaceByFee.
To understand it better, here's an educational link so that you will understand the whole concept of RBF.
https://bitcoinops.org/en/rbf-in-the-wild/
Please explain this better because I can't make sense of "x fees" and "actual x+10 fees".
In bitcoin, the fee is the excess amount from the inputs and outputs, it's not something that's included in the transaction data.
Also, what they mean by "replace" is an actual replacement of the already-broadcasted transaction, it's not a simple change of values to an existing txn.
In other words, you'll have to create a new transaction that spends a least one of its input and sign it with the necessary privKey.
Read BIP-125 for more information: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
Take note that some nodes do not require that "signaling" and will accept a replacement so you can try it regardless as long as you relay it to a full-rbf node.
In your replacement transaction, you'll have to either reduce the existing output's amount (preferably the change)
or add additional input and set the output(s) and change accordingly.
He means that he paid, let's say, 50 sat/vByte but actually, the recommended fee to get transaction confirmed was 50 + 10 = 60 sat/vByte and that's why he wants to increase fee. He can probably wait till fee goes down and he will be able to pay with original fee but there is so bad situation on mempool, fees are probably only going to rise.
Everything is possible, you can even reverse transaction with proper wallet. You can use RBF as recommended above if possible but if this option is not possible for you, then you can change fee indirectly by using Child Pays For Parent option that allows receiving address to deduct some satoshis from balance and increase fee.
Child-pay-for-parent is not use to change or increase the fee, but it is used to encourage miner to include the parent transaction into a block and get confirmed because the child transaction pays enough fee which is able to get both the parent and the child transaction confirmed at once.
Assuming the mempool high fee rate priority is 50 sat/vbyte
The parent transaction paid 30 sat/vbyte
The child paid 70 sat/vbyte or higher
That is enough to encourage miners to include both parent and child transactions into the next block if the high fee priority is still 50 sat/vbyte or become lower as mempool become less congested.
Looks reasonable enough, but I will still wait for an official response from OP.
Based from his reply about using a library, it seems like OP is asking this for software development reasons rather than practical.
So it's better to tell him how it works more than how to do it with various wallets.
Note that your example will only hold true if both parent and child transaction are the exact same size, which is often not the case.
To work out what fee you need to use for the child transaction, you first have to calculate the size your child transaction will be, add that to the size of your parent transaction, multiply by the final fee rate you want to achieve, subtract the fee the parent has already paid, and then use that fee for your child.
So let's say your parent transaction is 500 vbytes, paying 10 sats/vbyte. Your child transaction will be 200 vbytes, and you want the final fee to be 20 sats/vbyte. So your total transaction size will be 700 vbytes, your total fee will be 700*20 = 14,000 sats, you've already paid 5,000 sats, so your child transaction needs to pay 9,000 sats. This will work out to 45 sats/vbyte for your child.
This obviously becomes more complicated when you start considering multiple unconfirmed parents, bringing in additional inputs to the child transaction, and so forth.