|
timeofmind
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 09:14:39 PM |
|
Interesting. Could the transaction have been lost from all (relevent) miners' memory pools? If that was to happen, I guess you'd just have to send the transaction again.... but then how would you know that a miner out there may not write your first transaction sometime in the future? then you'd have inadvertently sent two transactions...
|
BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
|
|
|
TheSwede75 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 09:17:30 PM |
|
Interesting. Could the transaction have been lost from all (relevent) miners' memory pools? If that was to happen, I guess you'd just have to send the transaction again.... but then how would you know that a miner out there may not write your first transaction sometime in the future? then you'd have inadvertently sent two transactions...
Yeah, it just seems.. well, really odd. Not a huge transaction by any means but still a little 'unnerving'.
|
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 09:19:30 PM |
|
You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
ct1aic
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 09:20:47 PM |
|
Greetings. I already saw several times the message " Estimated Confirmation Time Very Soon" and after some time, the verification counter started adding verifications... Perhaps you need to wait some more hours and next time, include a higher fee (0.0005 BTC for instance, instead of the MultiBit default value you added). Summary Size 1559 (bytes) Received Time 2013-05-28 23:51:10 Estimated Confirmation Time Very Soon Relayed by IP 67.166.57.143 (whois)
|
Rui Costa, Portugal - BTC : 1ct1aicGoUVpZeovsw3cCcPJZJHV5JXtW
|
|
|
timeofmind
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 10:27:17 PM |
|
If no miner accepts a transaction, and it eventually gets lost from miners' memory pools, it would be nice to be able to tell definitively that the transaction was declined... otherwise there is no way of knowing when the transaction might be included in the block chain at some future time... and no way of knowing when/if the transaction should be retried.
|
BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
|
|
|
timeofmind
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 10:29:16 PM |
|
If no miner accepts a transaction, and it eventually gets lost from miners' memory pools, it would be nice to be able to tell definitively that the transaction was declined... otherwise there is no way of knowing when the transaction might be included in the block chain at some future time... and no way of knowing when/if the transaction should be retried.
Perhaps a policy in the protocol, if it is not included after a certain number of blocks... just drop it? So that we can be confident that it was dropped if so many blocks go by?
|
BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 10:36:21 PM |
|
All nodes will drop a tx from the memory pool, however your node will continually (on a schedule) rebroadcast the tx to peers (who update their memory pool and relay it to other peers).
So you need to prevent your node from rebroadcasting the tx first. That is tough as the client isn't designed to "undo" tx. You need to manually edit the wallet to remove the offending transaction and then keep your node offline. Eventually all other nodes will drop the transaction and you can respend the coins.
|
|
|
|
tclo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 29, 2013, 11:12:04 PM |
|
I've heard that if you don't add the miner's fee of .0005 or so, then it can take a week or so to confirm a transaction.
|
|
|
|
Abdussamad
Legendary
Offline
Activity: 3654
Merit: 1571
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 07:41:01 PM |
|
You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.
How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.
|
|
|
|
tinus42
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 08:07:59 PM |
|
I have a transaction of 0.000004 from 22 May which still has 0 confirmations. Yes it was from one of those faucets (stopped using them for more than a week). But it still won't get confirmed which is a bit sucky. These transactions should be either accepted after a short period or rejected and returned to sender.
|
|
|
|
grue
Legendary
Offline
Activity: 2058
Merit: 1434
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 08:14:07 PM |
|
Actually, your transaction's priority is the sum of your inputs age multiplied by their value, then divided by the size of the transaction. As you can see in blockchain.info, your transaction contains many dust "inputs". Although many are from the same address, they still add to the size of the transaction. As a result, your transaction will have a small priority value. But if your transaction is small, and your inputs are old, they will get confirmed very quickly, even without a fee. For instance, my 1 input, 2 output transaction (~1.1 BTC value) was confirmed in the next block, without any transaction fees. How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.
but just because it's "standard" doesn't mean it bypasses the fundamental rule of fees: the higher fee per kb, and higher the priority, the more likely it's going to be included in a block. Keep in mind that if 13 cents in fees (0.001 BTC), your transaction will almost certainly be included in the next few blocks.
|
|
|
|
Abdussamad
Legendary
Offline
Activity: 3654
Merit: 1571
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 08:19:59 PM |
|
Actually, your transaction's priority is the sum of your inputs age multiplied by their value, then divided by the size of the transaction. As you can see in blockchain.info, your transaction contains many dust "inputs". Although many are from the same address, they still add to the size of the transaction. As a result, your transaction will have a small priority value. But if your transaction is small, and your inputs are old, they will get confirmed very quickly, even without a fee. For instance, my 1 input, 2 output transaction (~1.1 BTC value) was confirmed in the next block, without any transaction fees. How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee.
but just because it's "standard" doesn't mean it bypasses the fundamental rule of fees: the higher fee per kb, and higher the priority, the more likely it's going to be included in a block. Keep in mind that if 13 cents in fees (0.001 BTC), your transaction will almost certainly be included in the next few blocks. Ok. Always good to learn more! More info about transaction priority in case anyone is interested: https://en.bitcoin.it/wiki/Transaction_fees#Technical_info
|
|
|
|
Mysticsam_3579
Newbie
Offline
Activity: 30
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 09:04:51 PM |
|
It is very easy if the transaction is in blockchain.info then it is just to wait until it got confirmed. Thats it.
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4790
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 10:21:48 PM |
|
You have . . . a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.
How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee. I believe the new "standard" fee is 0.001 BTC per kilobyte or fraction thereof. Your transaction is larger than a kilobyte, therefore the fee should be 0.0002 BTC. I'm not sure how many people have upgraded their nodes to use the new relay rules yet.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 30, 2013, 11:14:26 PM |
|
You have a few very small outputs and a very small fee. It is possible that apart from the fact that it's not in any miner's memory pool, that they also didn't like the low fees.
How do you figure that? 0.45 is not a small amount and the fee of 0.0001 is now the default fee in bitcoin-qt so it is going to be the new "standard" fee. The fee is 0.0001 per KB on low priority txs. Your tx is over 1KB so the min fee would be 0.0002 not sure why your client didn't calculate it correctly.
|
|
|
|
|