Bitcoin Forum

Good afternoon,
yesterday I sent a transaction with this transaction fee configuration:
https://i.imgur.com/Dbawbuj.png

"(Smart fee not initialized yet. This usually takes a few blocks...)"

I thought it was the fastest way to send a transaction but the transaction after 24 hours hasn't confirmed yet.

This morning I've checked again my Bitcoin Wallet at it says:
https://i.imgur.com/in3WoaN.png

"Estimated to begin confirmation within 1 block."


What has it changed?!?


I've downloaded Bitcoin Core 0.11.0 on Monday and since then I've sent with fixed transaction fee of BTC0.00050 but yesterday I send BTC0.20000 and decided to use the "Smart fee" feature of the Bitcoin Core Wallet.
Transaction: https://blockchain.info/tx/24e04b9b5913cd6aed0db212db18c35e2115e05e0124a2ba4d1e273f81719fcb
Transaction fee: BTC0.00000373
Estimated Confirmation Time: Within 6 Blocks (Medium Priority)

When I sent the transaction the low transaction fee I thought was a new feature of the Bitcoin Core 0.11.0 I was wrong, the transaction fee was not initialised.

Is there something I can do to resend the unconfirmed transaction or is there something I can do to not make this thing ever happens again?


Thank you for the reply you will or you will not gave me.


Thanks.

You need to wait for smart fee to initialize. It even told you so. Smart fee looks at fees from recent transactions and blocks so it needs to see those transactions and blocks before it can create a good estimate for a fee. Next time, you can either leave Bitcoin Core open or wait for smart fee to initialize before sending any Bitcoin.

To fix this, if you have change from that transaction, you can try a CPFP transaction. This is another transaction that spends the outputs of the first transaction but has a higher fee so that the fee covers both transaction's fees. You can ask this user https://bitcointalk.org/index.php?action=profile;u=538273, brianddk, for help doing this.

It needs a while to analyze the blocks. You can avoid this if you let it be for a while before you create a TX. When the "Smart fee not initialized yet" warning is gone the estimate should be accurate.

There is no reasonable way to speed this up.  You could try to create a double spend, but I doubt it would improve the situation. Keep the client open so your TX gets rebroadcasted and it will confirm eventually.

Edit: CPFP might actually improve the situation, Im not up to speed how common this is among miners.

I've used Bitcoin Core 0.11.0 since 07/26/1015 and it only initialized Smart Fee yesterday?

Seems strange that it took 4 days to initialize smart fee.

I have it open 4/6 hours a day in those 4 days.


I'm looking into it.


Thanks.

It probably only started initializing when you selected the option to use smart fee. Otherwise it would just be a waste of resources.

There is a way of forcing a transaction broadcast without having to wait the 30 minutes Bitcoin Core period?

I've posted the same question here:
https://bitcointalk.org/index.php?topic=1126665
and here:
https://bitcointalk.org/index.php?topic=1122324

Help -> Debug window -> console -> enter gettransaction TXID and confirm with enter -> copy the long hex code -> sendrawtransaction  HEX_CODE and confirm w/ enter

You might however be annoying to other nodes and end up on their blocklist is you do this too often.

Sure... I can sweep the TX with a CPFP.... Which is the address you were sending to?

This is the help of the ssendrawtransaction command:

Is it possible to re-send the transaction with higher fees?

If yes, how is it possible to re-send the transaction with higher fees?

I don't want to rebroadcast without knowing if that can be done or now, I don't want to put useless noise on the network.


Give me a minute I will try to re-send the transaction with higher fees to see if that solve the problem.

I will give you the TX if that didn't work.

Thank you for the help by then.

If you want to redo the transaction with higher fees, you need to shutdown your wallet app, or all your wallet apps if you have imported your keys on multiple apps.

Once the effected wallets are off, you need to do a bit of wallet surgery to purge the TX from the TX database of your wallet.

Then wait 2-3 days checking all the block explorers for your transaction to get ejected from the pool.

Then boot up your wallet, craft your transaction and resend.

This (wait... wait... wait... resend) is what most people do.

Good information in the "READ THIS FIRST" thread: https://bitcointalk.org/index.php?topic=232979.0

yes, but it is going to take longer than either waiting for a confirmation or asking brianddk to help you with CPFP. You could try doing RBF which is Replace By Fee, but very few nodes and miners implement that. Much less than CPFP. With CPFP, you will need to wait for Eligius to mine a block with your transaction. I don't know of any miner that does RBF yet. You could also do the standard delete transaction from wallet and wait a few days but that will take a few days.

I saw this thread. Thank You.

The fact that the (allowhighfees) parameter, in the
command is new in Bitcoin Core 0.11.0 make me thinking that now is possible to re-send transactions with higher fees without doing all the things you suggested to do.

Instead doing all the thing you suggested me to do I prefer to wait... wait... wait... until the transaction gets confirmed and ask the receiver to send the money back to me.


Normal people don't do all the stuffs that you asked me to do.

I'll try to stay normal for the time being.

There is not a "delete transaction" command in the Bitcoin Core Wallet.

There is a "delete-all-TX" (-zapwallettxes) but that does not delete the TX from people who have already received it.

This is not a bug... it is designed into the protocol so that a sent transaction cannot be unsent (aka "no-chargeback").

You should read the thread: https://bitcointalk.org/index.php?topic=232979.0 and listen the audio stream I linked at the end of it.

By received you mean confirmed?

No. By received he means the computer actually received the transaction from the p2p network.

You cannot catch the time from when the transaction gets broadcasted to the network to when the transaction receives the destination wallet unconfirmed.

If is less than a sec in most of the times.

I have solved by running this command:

Thank you all guys.

This thread can now be closed.

If you edit your first post, under Additional Options, there is a "lock" button.

After 2 hours transaction gets broadcasted again to the Blockchain without my will.
https://blockchain.info/tx/24e04b9b5913cd6aed0db212db18c35e2115e05e0124a2ba4d1e273f81719fcb

I needed to ask my client to send me BTC0.19600 to me back again.

I PM'd you if you want to rescue with CPFP...

Since you zapped the TX you could go ahead and double spend, but that will still likely take some time before the two competing TX settle down.

I settled with the client: he/she sent me back the money.

One question: how is that possible that the transaction got recreated?

Once deleted it should stay deleted for good: how is it possible that the transaction got recreated from nothing? That's really strange, I want to know that now.

The transaction was not deleted at all. Zapwallettxes deletes the transaction from its local database. However, since that transaction had already been broadcasted, other nodes will have it in their mempools. When you Bitcoin Core node starts up with that flag enabled, it will start receiving and requesting transactions from its peers, and since that transaction includes one of your addresses, it will ask for it as well. It was not recreated nor was it deleted in the first place.

You are right: TX ID is the same
https://blockchain.info/tx/24e04b9b5913cd6aed0db212db18c35e2115e05e0124a2ba4d1e273f81719fcb

After running Bitcoin Core Wallet with zapwallettxes parameter for 8/10 hours the transaction gets removed from the Blockchain: during that time if you clicked on the link above it shows "invalid transaction hash".

So for 8/10 hours the transaction gets deleted form the Blockchain, after that time the pools that remembered it broadcasted it again to the Blockchain.

I think that's what happened.

That could also have been blockchain.info dropping the transaction themselves. To be sure, you should also check other blockchain explorers since bc.i has had some issues recently.

I can't believe it: now the Smart Fee have been initialized but they are again too low!

I've sent with Confirmation within 3 blocks and it send with way low fees:
https://blockchain.info/tx/241045f9628bfb76f5dfae12d0c2c934607fa57fe765e7bfc92f393f3b1beced

What did they do with Bitcoin Core 0.11.0?

With Bitcoin Core 0.11.0
Confirmation within 3 block: 30 minutes NO CONFIRMATIONS.

With Bitcoin Core 0.10.2
Confirmation within 3 block: 9 minutes 1 CONFIRMATION.


There is something wrong with Bitcoin Core 0.11.0

I hear what you are saying.... I love the fact that Qt is using real statistics to calculate the Fees.

It is probably still worth the time and effort to always look at:
http://bitcoinexchangerate.org/fees

before sending a transaction...

Also.. be away that the way Qt computes fees may depend your it's copy of the mempool.  This means if Qt hasn't been running all day, or if it isn't fully synced, that the stats may be off.

Your are not answering my question: did Bitcoin Core 0.11.0 changed something in how Smart Fee is calculated?

Thanks for your answer.

Thank You for the rest: free info is always valuable.

I dont know the answer to your question, but your comparisson above make no sense.
Thats like saying:

Today it took me 30 minutes to get to work
Last week with my old car it only took me 15 minutes.

You share no information about the traffic situation (how many unconfirmed TX, what fees they paid, how was the situation in the block before the TX's) which is the main indicator whether the estimated fee is good or not.

Shouldn't a new release put more features in the system?

Apologies for OT: I didn't want to go out of this "support thread" next time I will give more information. As this issue is now resolved I won't give them now.

Thanks brianddk for help and everyone that gave info.

Thanks.

I'm proposing an answer, but refusing to commit to it based on the sparsity of the information provided.

[Q1] - What block height were you at on 0.10.2 when you started the send transaction dialog?
[Q2] - What was the size of your mempool on 0.10.2 when you started the send transactions dialog?
[Q3] - How many incoming / outgoing connections did you have on 0.10.2 when you started the send transactions dialog?
[Q4] - How long had 0.10.2 been running with active connections when you started the send transactions dialog?
[Q5] - What block height were you at on 0.11.0 when you started the send transaction dialog?
[Q6] - What was the size of your mempool on 0.11.0 when you started the send transactions dialog?
[Q7] - How many incoming / outgoing connections did you have on 0.11.0 when you started the send transactions dialog?
[Q8] - How long had 0.11.0 been running with active connections when you started the send transactions dialog?

The answer could be either that 0.11.0 botched the fee calculations, ...OR... your 0.11.0 client instantiation was making a calculation based off of less network information, or less congestion than your 0.10.2 client instantiation.

Is mempool related to my Bitcoin Core application?

What is the command to check it?

Yes
getmempoolinfo

Will do that during the week.

Issue is solved.

Thank you.