Topic: Confused about fee (Read 260 times)

I was planning to bump the fee but luckily the mempool isn't that busy anymore. My tx has been confirmed today morning with that 1sat/byte. It has been a learning lesson for me that I didn't consolidate the input when I should. Thank all of you.

The size of the current mempool has fallen from 67 MB to 26 MB in the last 24 hours, and we are currently confirming transactions with fees of 2 sat/vbyte and higher. There are still 8 MB of transactions at 2 sat/vbyte, but give it another 24 hours, and provided there is no big price swing which floods the mempool with transactions again, then I would expect Pffrt's 1 sat/vbyte transactions to confirm.

In this case, i'd probably just get the raw, signed transaction and keep rebroadcasting it every 3 or 4 days. There's always a probability you'll get lucky sooner or later, or there's also the probability the feerate will drop eventually. If you're ever concerned that the average fee will rise even more, you can always just bump the fee.

1. No hurry to be honest unless I see BTC to $15k  However, that's the reason for my consolidation of inputs.
2. Yes it was rbf. I will wait till the fee decrease or replace fee only if btc hit above $15k.
3. Yes.
However, I was not in hurry and this thread was to learn thwwhat possibility can be done.Thank you.

I hate to break it to you, but a CPFP will be more expensive then bumping the fee from an opt-in RBF transaction.
Paying a mining pool will be even more expensive.
Waiting untill it gets dropped from the mempool and double spending afterwards might be more expensive or cheaper, depending on the average feerate in ~2 weeks.

The cheapest option will be to keep rebroadcasting the 1 sat/byte tx and wait untill the average feerate from the tx's in the mempool goes down. This can be in 1 day, 1 week, 1 month, 1 year???

The next cheapest option will either be bumping the fee or waiting 2 weeks and double spending (depending on wether the feerate rises or drops in 2 weeks)
An even more expensive option will probably be CPFP, because the total fee you'll have payed in the end is the fee of the stuck transaction + the fee of the child transaction, which is equal to the fee of a transaction with a size of (stuck tx + child tx) minus the fee you've already payed.

Everything depends on the evolution of the optimal feerange, so you either have to wait it out and hope for the best, or if you want this fixed right now your cheapest option is bumping the fee.


It's clear to me you value your privacy, so you don't have to share the txid with us, however, could you answer this questions:

• How long are you prepared to wait
• Was the tx opt-in rbf
• Do you mind "gambling" on the probability of the fee decreasing in the near future

Sure thing, I can understand that. Some very quick back-of-the-napkin math:

A 14-input 1-output transaction will be sitting somewhere around 8,400 weight units if they are all legacy addresses, or 4,000 weight units if they are all native segwit, and somewhere between the two if nested segwit or a mix (assuming none of the inputs are multi-sig or some other script which would be much larger).

Your new transaction I will assume is 1-input 2-output (the payment and the change), and so will be sitting somewhere around 900 weight units if all legacy, 560 weight units if all native segwit, or somewhere in between.

This gives you a total size of between 4,560 and 9,300 weight units (very roughly), so between 1,140 and 2,325 vbytes.

Given the current fee of 120 sat/vbyte to get within 0.1 MB of the tip, that means your new transaction would need a fee of between 136,800 and 279,000 sats.

Thanks o_e_l_e_o, I can't share the details due to privacy reason. As I said, I had 14 input which I combined to one.

I don't want to bump the fee because I don't want to use higher fee for all the 14 inputs which will turn into a bug amount which I don't want to pay. That's why I combined all of them into one input now.

o_e_l_e_o is 100% correct about a CPFP, you do have other options tough:

• It's a transaction consolidating your unspent outputs, so you have the private key to re-spend those 14 unspent outputs AND you have the private key for the address that was funded by the stuck transaction. If there isn't a case of urgency, you can always wait untill the transaction drops from the mempool of most nodes, then double-spend those 14 unspent outputs. This can take up to 2 weeks, and the odds are that by then the average fee is even higher
• You can do a rbf, in case the tx was opt-in rbf
• You can pay a big mining pool to include your transaction into the next block they solve (viaBTC is known to do this)
• o_e_l_e_o has already explained CPFP
• You can also get the raw tx and keep rebroadcasting it... Sooner or later the average fee will decrease and if you kept rebroadcasting the tx every couple of days, sooner or later it'll end up in a block

There is a financial difference between the options, aswell as a difference in wait time untill confirmation, aswell as a technical difficulty difference.

Follow the advice above and you should be good. If you're unsure whether the fee would be enough to complete the transaction, then do not select 'final' before broadcasting it to the network when bumping it, that way you can adjust it later if it remains stuck.

Yes, they will all be confirmed.

This is what is known as a child-pays-for-parent (CPFP) transaction. Currently, a fee of around 120 sat/vbyte will put you within 0.1 MB of the tip of mempool, meaning your new transaction would be highly likely to be confirmed in the next block, but you will need to bump it higher to cover all your previous unconfirmed transactions too. 200 sat/vbyte might be enough, but if you want to share the details of your unconfirmed transactions then we can give a more accurate figure. What you need to do is add up the weight of all the unconfirmed transactions and the new transaction, multiply that total weight by your chosen fee, and use that total fee for your new transaction.

When your new transaction confirms, all the previous unconfirmed ones will too.

I know that but I'm confused if I use the current fee for my unconfirmed tx (it was around 14 inputs which I made 1 input with 1 sat/per byte, still unconfirmed), will the previous tx be confirmed too? For your info, I had to use a lot of fees for the 14 inputs in total if I were to use the current fee. That's why I sent with 1sat/oer byte and combined all the input into one.

https://bitcoinfees.earn.com/

The fastest transaction fee to be accepted in first block is currently 88 satoshis/byte

I was too lazy to consolidate some of my inputs when the fee was too low, around 1sat/byte but now I nees to consolidate. I used 1 sat/byte which isn't going to be confirmed soon. Now I want to send the consolidated input (which I used 1sat/byte and unconfirmed still). Will it be confirmed if I use 100 or 200 sat per byte? Since my input now will be 1, total fee will also be lower. Will it be confirmed or I need to use more higher fee for confirming the previous tx as well.