Unconfirmed Transaction - DELAY - SOLVED -

[brianddk]

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.

[1713551687]

1713551687

[1713551687]

1713551687

[1713551687]

1713551687

[BitNow]

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.

[achow101]

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.

[BitNow]

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.

[achow101]

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.

[BitNow]

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

[brianddk]

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.

[BitNow]

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.

[shorena]

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.

[BitNow]

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.

[brianddk]

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'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.

[BitNow]

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?

[brianddk]

Is mempool related to my Bitcoin Core application?

Yes

What is the command to check it?

getmempoolinfo

[BitNow]

Is mempool related to my Bitcoin Core application?

Yes

What is the command to check it?

getmempoolinfo

Will do that during the week.

Issue is solved.

Thank you.