Topic: ~For a transaction that takes too long~ (Read 184 times)

Yes. You can choose to reduce the amount being sent to one or more of the outputs of your transaction and use that to pay a higher fee instead.

For example, let's say you have a transaction which spends one input of 0.03 BTC, sends 0.02999 BTC to another address and pays 1000 sats in fees. You could replace that with a transaction spending the same 0.03 BTC, but paying 0.02998 BTC and paying 2000 sats in fees.

Sorry to ask, if a transaction has already been broadcasted and I don't have any means to get more sats for RBF, will it be possible for me to use from the broadcasted transaction?

Let's say I sent 0.03BTC using 2 SATs as my transaction fee and all of a sudden the network became congested which resulted in the increased of fee. Can I use from that my already broadcasted 0.03BTC?

The only time I have used RBF was when I had some SATs left in my wallet, and I am just learning for the first time in this thread that it can be done from a different wallet.

Most wallets should give you the option of including an additional input from that wallet, if you want to.

Not at all.

Let's say I have a wallet containing UTXO A on Address A, and UTXO B on Address B. I create a transaction sending UTXO A to a third party to pay for some goods or services. I later want to bump the fee on this transaction, but I don't want the third party to receive any less. So my wallet can create a new transaction which includes UTXO B alongside UTXO A, pays a higher fee, and then sends the rest to a change address.

Now let's say I also have a completely separate wallet which contains UTXO C on Address C. I could also manually create a transaction which includes UTXO A and UTXO C, sends the same amount of coins to the third party, and pays a higher fee. All I need to do then is sign it separately with the first wallet and then with the second wallet, and then broadcast it.

The network, and the RBF mechanism, have no concept of which addresses are in the same wallet and which are in different wallets. You can combine any UTXOs from any wallets in the same transaction.

If one sends this extra input from a different wallet entirely, wouldn't it cause the person to pay too much in fees, because they have to first cover the transaction fees of adding this extra input from a different wallet in order to be able to bump the fee on the original transaction initiated.

That's it, and that's the reason why you have to wait for several confirmations before being able to use your funds after depositing them in most platforms, while it is often much faster if you disable RBF.

Of course, disabling RBF can make your transaction much slower in the case of a punctual congestion, so one should take these factors into account before sending it, because depending on these things you may prefer to send it one way or the other.

BTW, if you try it, do it just for education purpose: taking advantage of the ignorance of others and doing it in bad faith is immoral.

Oh, I have missed that point.

Does wallet do it automatically or there is a need to construct  manually a new  transaction with the same outputs and new input from other address?

To be frank, I didn't have experience with RBF transactions that have   inputs from other address and more likely would never wish for it as in my understanding the appearance of such input would decrease my privacy.


This is arguable point. I prefer to use  UTXOs from the same address when paying each time  for the same service rather than to reveal to them my new addresses.

That's not right. As I said above, if you want to keep the outputs the same and bump the fee then you can include another input from anywhere else. The extra input does not have to be from the same address, or even the same wallet, as your original inputs.

Telling people not to empty their sending address is poor advice since it encourages address reuse, and as I've explained is entirely unnecessary.

In electrum RBF is now enabled by default from version 4.4.0, so any user using newer versions from 4.4.0 will have their transactions flagged as RBF even without opting in, and wouldn't be able to opt out of it. Sooner rather than later quite a lot of wallets are also going to enable RBF by default, making it impossible to opt out except one uses an older version.
Yes and one problem i can see in this is with merchants/services that usually accepts payments of zero confirmation with transactions that are not flagged by RBF.

You have shared a good topic dear op, I often called myself also a newbie because i still didn't used many features of the crypto technology and one of them is RBF, TBH, i did not know this term from the start of my journey i just came to know about it for like 2 or 4 weeks before. When one of my transaction from TW to Binance was taking so long and i have to wait for like more than 1 hour.

I asked one of my friend about it and he said you could only wait now. My transaction was not getting any confirmation, then i started to read about it and find out that if my transaction will not get confirmations then it might reflect back and my assets will be free to use. But i also read that the pending state of Transaction could take a lot of time, like from days to year maybe.

This information was shared in the support section of Trust wallet. and i was like what! is this really a thing like transaction stuck for longer period of time and i do not know that TW didn't have RBF option so all i could do is to wait only.

The point is RBF is the best feature but it is also not good for those who do not wanted to pay higher fee but they have to because their transaction are keep getting delayed and to complete their transaction they have to choose higher fee.

Agreed, but it depends on situation you have.

If you don't have a change and at same time pay to someone who expects the agreed amount, you can not do it.

Such transaction that doesn't have leftover change  would left the only way for you,  namely, to take the amount to cover the increased fee from dedicated output.

So, repeating again

Yes it can. You just decrease the value of the outputs and put those extra sats to the fee instead. Alternatively, you can include an extra input from any other address to give you extra coins to spend on the fee.

It is worth mentioning that RBF can not be applied to transaction that nullifies the sending address because such transaction  would  not left any extra sats in that address to increase the fee.

So, if you are planning to use RBF  then don't empty your sending address.

Nevertheless, if it happens that  sending address has no UTXOs to cover increased fee, then there is other opt to push stuck transaction. This is CPFP (child pays for parent). This will be valid option if the stuck transaction has a change output which can be used to create a new (child) transaction with a higher fee. The fee of child transaction should cover both itself and parent transaction.

Hello ranochigo
Yes sure, thanks for pointing out... that's why I add the "disclaimer" ..and yes it should be used in a certain circumstances as a kind of "last resort".
If the tx has been broadcasted without a RBF wallet, it's a quick/easy/working solution... maybe not the cheapest option but it doesn't requires any specific knowledge

Technically speaking, every RBF transaction is a double spend, since it includes at least one of the same inputs. Those inputs are being spent in a second transaction which conflicts with the first, and it is therefore a double spend. It just so happens that many (or maybe even most) RBF transactions happen to double spend to the same addresses as the original.

It will make a difference to the order in which transactions are chosen by miners to be included in blocks, but it will make no difference whatsoever to the total number of unconfirmed transactions.

invariably we are broadcasting a new transaction different from the first one with a higher fee. A new version of the unconfirmed transaction replaces the unconfirmed version with a higher fee hope its correct

If the transaction is completely different spending any one of the inputs in an address not present in the original transaction won't it be an attempt to double spend?. And using RBF to cancel a transaction sending it back to myself is what I haven't explored I will try that next.

This will mean giving users much more options and won't it be more problematic? and might even arise to many unconfirmed transactions especially incases where the transaction creators cannot afford to replace their transaction by fee

Generally, CPFP isn't recommended for a few reasons.

Firstly, CPFP isn't a recognized standard that miners have to adopt. It is purely voluntary, unlike RBF where most of the nodes and miners will see the RBF flag and act accordingly. Thus, it is a method that is a hit or a miss, if a miner happens to adopt CPFP, then you'll get your transaction included and if they don't, then you have to wait a lot longer.

Secondly, the amount of fees that should be set is quite ambiguous, unlike RBF where you have the liberty of creating another transaction with a higher fee (and thereby superseding the first transaction), the miners can potentially require a higher fee for your CPFP transaction, after considering the total increase in the size.

Lastly, it is non-reversible as well. There is no way of removing your child transaction, even if the network fees were to dip and your first transaction happens to be confirmed without the need for CPFP. As such, I would consider CPFP as a last resort, if you don't have opt-in RBF for some reason or you cannot change your first transaction due to merchant limitations.

in some cases (transaction that have a change) it is also possible to use another solution to "accelerate" a transaction...without having to modify this first transaction already broadcasted.

this solution requires to spend "the change" (output coming back of the first transaction) in a new transaction by setting a higher fee.
in this way, by processing this second transaction, the first is also included in a block... and it is a solution that also works with wallets that have not implemented RBF (but of course as mentioned above you need some "change" from first transaction...)

This is incorrect for two reasons.

First of all, a transaction cannot be the same except for a higher fee. If the fee is higher, then either you need to include an additional input or you need to reduce one or more of the outputs. Something else must change in order to free up funds to contribute more to the fee.

Secondly, the transaction can in fact be completely different. You can make a replacement transaction spending any one of the inputs of the original transaction to any address you like (including an address not present in the original transaction), and you will replace the original transaction. This is why you can use RBF to "cancel" a transaction, which actually replaces the transaction with a new one sending the coins back to yourself instead of to the original recipient(s).

It's also worth pointing out that full RBF is gradually replacing opt-in RBF, and so soon every transaction will be able to be RBFed, even if not opted in.

You can include;
• Bitcoin core
• Blue wallet
• Sparrow wallet
• Samourai wallet

You should also include that you need to enable RBF when creating the transaction to be able to bump the fee up at a later time.

Many newbie might not have come across RBF or even if they have they might not know what it really mean or its contribution to making transaction that seem to delay get confirmed faster. I know this might have been discussed severally but pardon me. I am trying to see if I can come up with a much simpler definition that will help we the novices take advantage of the extra functionalities of most wallets to process unconfirmed transaction faster.

RBF: This is an acronym for Replace By Fee and as the name implies it means paying higher fees to make an unconfirmed transaction competitive. In real sense everyone is after the benefit so a higher fee will attract more  attention because miners will receive higher fees upon selecting the transaction.

It can also be said to be a process of replacing one version of an unconfirmed transaction with another version but this time paying a higher fee. RBF was first introduced in BIP125 and Bitcoin core 0.12.0 saw its first implementation. By implementation I mean usage..

There are variations in the RBF rules due to the different software nodes available but the most popular and widely used is BIP125 opt-in RBF as implemented in Bitcoin Core 0.12.0. This very version of RBF gives the opportunity for transaction creators to decide if they are willing to allow their transaction get replaced with a version that pays a higher-fee.

Just imagine creating a transaction and it stays unconfirmed for long because there are other other transactions that are willing to pay higher fees. It might make that transaction stay even longer than expected, except the transaction time does not really matter.

But what if the time the creator have is short, another broadcast will be done. This new transaction is just the same as the previous one the only difference will be the the inclusion of a higher fees. This will make the transaction more competitive for block space because miners will receive  more for selecting that transaction.

Wallets :
The following wallets allows easy use of RBF

• Electrum
• Blockstream Green