Although I know the input age makes a big difference mining pools don't necessarily follow the "standard rules" when it comes to tx inclusion (so although pleased I was actually a little surprised that zero fee well aged txs are seemingly always preferred over adequately aged txs with the minimum fee).
To my thinking the pools would always prefer the txs with fees than those with none (and no-one can force them to include a tx).
Topic: High Priority Transaction with Recommended Fee Unconfirmed *22* Blocks (Read 2575 times)
August 17, 2014, 11:18:32 PM
August 17, 2014, 04:58:26 PM
Oddly enough though if I have adequately "aged" UTXOs I can send txs (that involve a large enough BTC amount) with *no fee* and they will appear generally in the very next block!
priority = sum(input_value_in_base_units * input_age)/size_in_bytes (source:https://en.bitcoin.it/wiki/Transaction_fees#Technical_info)Input age (number of confirmations) and number of coins sent have a huge affect on transaction priority. (assuming the pools haven't changed the relevant settings too much.)
August 16, 2014, 07:50:56 AM
Whats the wallet address its being sent from and too
whats the size of the transaction being sent ?
Is it a Big transaction so the miners want a bigger fee cut or something like that
All my sends have been confirmed fast ive sent pretty decent fees everytime though,
in general how many transactions have you sent and received before and recently, also
are you changing addresses or using the same addresses for all the send and receives.
Did you use 0.9.2.1 to send it ?
Well i see you sent it with Blockchain.info so your using a third party wallet right?
you should be talking to them about this first
whats the size of the transaction being sent ?
Is it a Big transaction so the miners want a bigger fee cut or something like that
All my sends have been confirmed fast ive sent pretty decent fees everytime though,
in general how many transactions have you sent and received before and recently, also
are you changing addresses or using the same addresses for all the send and receives.
Did you use 0.9.2.1 to send it ?
Well i see you sent it with Blockchain.info so your using a third party wallet right?
you should be talking to them about this first
August 16, 2014, 07:47:22 AM
If I want confirmation fast, I using 0.0002 BTC fee. So basically use 2x more fee than most other txs, and your transaction is likely included with priority over other txs.
Agreed - I do the same and generally always see my tx appear in the very next block. Times when I have only paid the minimum I've sometimes have had to wait for well over 10 blocks to be mined before it gets included (presumably this very much depends upon who is doing the mining).
Oddly enough though if I have adequately "aged" UTXOs I can send txs (that involve a large enough BTC amount) with *no fee* and they will appear generally in the very next block!
August 16, 2014, 07:40:11 AM
If I want confirmation fast, I using 0.0002 BTC fee. So basically use 2x more fee than most other txs, and your transaction is likely included with priority over other txs. Just my experience
August 16, 2014, 07:35:02 AM
~22 blocks ago with a 0.0001 BTC
clearly, if inputs is old ... you must include more fees.
22 blocks = 220min = ~ 4hours.
update this in 2 days.
August 16, 2014, 07:19:06 AM
August 16, 2014, 06:32:30 AM
Maybe bitcoin server [...]
Ya, maybe bitcoin didn't liked your transaction, he is little kiddo sometimesAnyway time sorts everything
August 16, 2014, 06:06:21 AM
Recently, some user ask/report the long confirmed time with default tx fee 
in bitcointalk.org
Maybe you all should increase tx fee to prevent long confirmation time
No its not, its .0001 per kb and you are below 1 kb.
1511 however is over 1kb and the fee should have been .0002
There is also the age of the input that you spend, but I just assume that neither of you used mature coins. It would have made the TX go through faster anyway.
well, i don't know how to see byte size before set tx fee
maybe someone can help me to see byte size from blockchain.info wallet
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
No. It does look like your TX is 2x as large as 797 bites though, so technically the fee should have been .0002.
With that being said, generally even a fee 1/2 the recommend would generally get confirmed quickly by the miners.
Well, but confirming time is very slow.
If i know the sixe is big, i will set bigger tx fee
There have been ~7 blocks since.
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
and this one, which doesn't spend an unconfirmed input. In fact, the change IS the unconfirmed input for the TX above:
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
Well,
I looked at previous blocks to the ones that these transactions were finally included in, nearly all were at max size.
Discus Fish max is around 900KB, Eligious is 900KB, ghash.io is 750KB (or 350KB), Slush is 750KB, BTCGuild is 500KB, CloudHashing is 250KB (?).
So, this
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
transaction would be trumped by just about every .00001 transaction (1kb or less)
this
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
is in same boat, but not quite as bad.
I usually include .000011 transaction fee for my <1KB transactions.
I just know there are maximum accepted tx size
But who will send bitcoin with very big fee
in bitcointalk.orgMaybe you all should increase tx fee to prevent long confirmation time
-snip-
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
No its not, its .0001 per kb and you are below 1 kb.
-snip-
Maybe yes
Last time i send bitcoin with 8 output and default fee & 1511 bytes, take almost a hour to get 1 confirmation
Maybe bitcoin server too busy to proceed your transaction
Maybe yes
Last time i send bitcoin with 8 output and default fee & 1511 bytes, take almost a hour to get 1 confirmation
Maybe bitcoin server too busy to proceed your transaction
1511 however is over 1kb and the fee should have been .0002
There is also the age of the input that you spend, but I just assume that neither of you used mature coins. It would have made the TX go through faster anyway.
well, i don't know how to see byte size before set tx fee
maybe someone can help me to see byte size from blockchain.info wallet
I know the reason, because size transaction is bigger than usual.
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
With that being said, generally even a fee 1/2 the recommend would generally get confirmed quickly by the miners.
Well, but confirming time is very slow.
If i know the sixe is big, i will set bigger tx fee
maybe because there was no new blocks?
take a look now
take a look now
There have been ~7 blocks since.
Quote
Quote from: Razick on Today at 08:05:08 PM
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
and this one, which doesn't spend an unconfirmed input. In fact, the change IS the unconfirmed input for the TX above:
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
Well,
I looked at previous blocks to the ones that these transactions were finally included in, nearly all were at max size.
Discus Fish max is around 900KB, Eligious is 900KB, ghash.io is 750KB (or 350KB), Slush is 750KB, BTCGuild is 500KB, CloudHashing is 250KB (?).
So, this
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
transaction would be trumped by just about every .00001 transaction (1kb or less)
this
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
is in same boat, but not quite as bad.
I usually include .000011 transaction fee for my <1KB transactions.
I just know there are maximum accepted tx size
But who will send bitcoin with very big fee
August 16, 2014, 05:55:31 AM
maybe because there was no new blocks?
take a look now
take a look now
There have been ~7 blocks since.
Quote
Quote from: Razick on Today at 08:05:08 PM
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
and this one, which doesn't spend an unconfirmed input. In fact, the change IS the unconfirmed input for the TX above:
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
Well,
I looked at previous blocks to the ones that these transactions were finally included in, nearly all were at max size.
Discus Fish max is around 900KB, Eligious is 900KB, ghash.io is 750KB (or 350KB), Slush is 750KB, BTCGuild is 500KB, CloudHashing is 250KB (?).
So, this
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
transaction would be trumped by just about every .00001 transaction (1kb or less)
this
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
is in same boat, but not quite as bad.
I usually include .000011 transaction fee for my <1KB transactions.
August 16, 2014, 05:11:16 AM
I don't know what is the problem but it surely would be seen as something terrible by me, because if transactions don't get confirmed it really clogs everything else in the system and that is never good for Bitcoin.
August 16, 2014, 01:16:24 AM
I know the reason, because size transaction is bigger than usual.
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
With that being said, generally even a fee 1/2 the recommend would generally get confirmed quickly by the miners.
August 16, 2014, 01:13:14 AM
-snip-
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
No its not, its .0001 per kb and you are below 1 kb.
-snip-
Maybe yes
Last time i send bitcoin with 8 output and default fee & 1511 bytes, take almost a hour to get 1 confirmation
Maybe bitcoin server too busy to proceed your transaction
Maybe yes
Last time i send bitcoin with 8 output and default fee & 1511 bytes, take almost a hour to get 1 confirmation
Maybe bitcoin server too busy to proceed your transaction
1511 however is over 1kb and the fee should have been .0002
There is also the age of the input that you spend, but I just assume that neither of you used mature coins. It would have made the TX go through faster anyway.
August 16, 2014, 01:01:44 AM
I know the reason, because size transaction is bigger than usual.
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
Maybe yes
Last time i send bitcoin with 8 output and default fee & 1511 bytes, take almost a hour to get 1 confirmation
Maybe bitcoin server too busy to proceed your transaction
August 16, 2014, 12:28:04 AM
I know the reason, because size transaction is bigger than usual.
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
Is 797 bytes really considered too large for a standard fee? If miners aren't processing that they are just being stingy to the detriment of the network.
August 16, 2014, 12:11:35 AM
I know the reason, because size transaction is bigger than usual.
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
The Output is very much.
So the confirmation is very slow, i think you need to increase the free to make confirmation faster.
I think next time you should set bigger transcation fee
August 15, 2014, 11:37:09 PM
Hmmm, I wonder if something strange is going on... It's been hours since I sent mine at 7:30 CDT and it looks like I'm not the only one having problems. Maybe it's the number of inputs, but 5 doesn't seem like very many.
August 15, 2014, 11:13:41 PM
Hi,
I sent this transaction almost 3 hours ago from my armory wallet to an exchange..
https://blockchain.info/tx/828fe70828f66ddc43951f3e744c7cbfad0505ec5799d4bbe223d649ee1b06e7
Still not 1 confirmation.. wtf
I sent this transaction almost 3 hours ago from my armory wallet to an exchange..
https://blockchain.info/tx/828fe70828f66ddc43951f3e744c7cbfad0505ec5799d4bbe223d649ee1b06e7
Still not 1 confirmation.. wtf
August 15, 2014, 09:35:39 PM
maybe because there was no new blocks?
take a look now
take a look now
There have been ~7 blocks since.
Quote
Quote from: Razick on Today at 08:05:08 PM
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
https://blockchain.info/tx/3999b1a69e65066f3cfa1a95404543c5deb1e62a9398465cc3dbb34d6e521081
and this one, which doesn't spend an unconfirmed input. In fact, the change IS the unconfirmed input for the TX above:
https://blockchain.info/tx/e73590bdb3be8b81267cebc66b42ac07267463b6d1e8b7eb37d362112876de90
August 15, 2014, 09:18:16 PM
Strange, I sent a transaction from Blockchain.info about 4-5 blocks ago with a 0.0001 BTC fee as recommended and it has yet to be confirmed. Blockchain.info says it's high priority and there are only 4 inputs. Any idea why this might happen? Since we're not at the blocksize limit I expected it to confirm in one block.
Transaction ID? Without it, it is rather difficult to tell you anything about what happened.
Lots of possible reasons, but in the end the reason is because the miner (or pool) that solved the blocks decided not to include your transaction. There is nothing in the protocol requiring miners (or pools) to include transactions that they don't want to.
Jump to: