Is mempool related to my Bitcoin Core application?
YesWhat is the command to check it?
getmempoolinfoWill do that during the week.
Issue is solved.
Thank you.
Topic: Unconfirmed Transaction - DELAY - SOLVED - (Read 3204 times)
Will do that during the week.
Issue is solved.
Thank you.
Is mempool related to my Bitcoin Core application?
YesWhat is the command to check it?
getmempoolinfo 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.
[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?
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.
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.
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 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.
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.
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.
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 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.
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.
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'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
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.
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.
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.
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.
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.
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.
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...https://blockchain.info/tx/24e04b9b5913cd6aed0db212db18c35e2115e05e0124a2ba4d1e273f81719fcb
I needed to ask my client to send me BTC0.19600 to me back again.
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.
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.
https://blockchain.info/tx/24e04b9b5913cd6aed0db212db18c35e2115e05e0124a2ba4d1e273f81719fcb
I needed to ask my client to send me BTC0.19600 to me back again.
This thread can now be closed.
If you edit your first post, under Additional Options, there is a "lock" button.
I have solved by running this command:
Thank you all guys.
This thread can now be closed.
Code:
./bitcoin-qt -zapwallettxes
Thank you all guys.
This thread can now be closed.
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.
There is a "delete-all-TX" (-zapwallettxes) but that does not delete the TX from people who have already received it.
By received you mean confirmed?
There is a "delete-all-TX" (-zapwallettxes) but that does not delete the TX from people who have already received it.
By received you mean confirmed?
Jump to: