|
MadGamer
Legendary
Offline
Activity: 1568
Merit: 1031
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 06:43:36 PM |
|
How much since you made this transaction ? It's High Priority , so it should get confirmed soon . just be patient mate
|
|
|
|
steveturk
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
works at NaSCasino.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 06:45:32 PM |
|
yeah, it happens, just keep an eye on it. just unlucky
|
|
|
|
michinzx (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 06:47:17 PM |
|
How much since you made this transaction ? It's High Priority , so it should get confirmed soon . just be patient mate
been about an hour and a half, took over 30 minutes for transaction to be broadcasted to peers too, and 5 blocks mined after i sent the coins
|
|
|
|
steveturk
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 84
Merit: 10
works at NaSCasino.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 06:53:39 PM |
|
sent from desktop wallet?
|
|
|
|
michinzx (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 06:56:49 PM |
|
sent from desktop wallet?
multibit
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 07:24:15 PM |
|
it's confirmed now
there have been a lot of max sized blocks lately, probably the reason it took a while.
Your tx was at 1722pm utc, there was only one block that wasn't full between then and now, that being 343315. If you want faster confirmations, increase fee to 0.00011
(also it was 9xx bytes, so like at the very back of the queue)
|
|
|
|
MadGamer
Legendary
Offline
Activity: 1568
Merit: 1031
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 07:33:09 PM |
|
sent from desktop wallet?
multibit And here you go , it got confirmed ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) I told you just to be patient mate . Good luck
|
|
|
|
michinzx (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 07:33:43 PM |
|
it's confirmed now
there have been a lot of max sized blocks lately, probably the reason it took a while.
Your tx was at 1722pm utc, there was only one block that wasn't full between then and now, that being 343315. If you want faster confirmations, increase fee to 0.00011
(also it was 9xx bytes, so like at the very back of the queue)
ah i see, i didnt know there was a priority for data size as well, I assumed it was a simple FIFO queue for transactions with priority for fees, thanks for the info
|
|
|
|
redsn0w
Legendary
Offline
Activity: 1778
Merit: 1043
#Free market
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 07:37:55 PM |
|
it's confirmed now
there have been a lot of max sized blocks lately, probably the reason it took a while.
Your tx was at 1722pm utc, there was only one block that wasn't full between then and now, that being 343315. If you want faster confirmations, increase fee to 0.00011
(also it was 9xx bytes, so like at the very back of the queue)
ah i see, i didnt know there was a priority for data size as well, I assumed it was a simple FIFO queue for transactions with priority for fees, thanks for the info The fees are correlated with the "size" of the Tx , if you put 0.0001 btc / 900 byte TX and someone send a Tx with (always) 0.0001 btc/ 300-400 byte ; the second has a major probability to be included first in a block.
|
|
|
|
rollingMyCar
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 07:55:14 PM |
|
it's confirmed now
there have been a lot of max sized blocks lately, probably the reason it took a while.
Your tx was at 1722pm utc, there was only one block that wasn't full between then and now, that being 343315. If you want faster confirmations, increase fee to 0.00011
(also it was 9xx bytes, so like at the very back of the queue)
ah i see, i didnt know there was a priority for data size as well, I assumed it was a simple FIFO queue for transactions with priority for fees, thanks for the info The fees are correlated with the "size" of the Tx , if you put 0.0001 btc / 900 byte TX and someone send a Tx with (always) 0.0001 btc/ 300-400 byte ; the second has a major probability to be included first in a block. i confirm this... if you want to be sure your transaction will be mined, you can put 0.0001 1 fee!
|
|
|
|
michinzx (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 07:58:18 PM |
|
I guess I should make the switch back to electrum then, tried multibit and liked it but it seems changing the transaction fee isnt an option on here
|
|
|
|
shorena
Copper Member
Legendary
Offline
Activity: 1498
Merit: 1530
No I dont escrow anymore.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2015, 08:04:39 PM |
|
it's confirmed now
there have been a lot of max sized blocks lately, probably the reason it took a while.
Your tx was at 1722pm utc, there was only one block that wasn't full between then and now, that being 343315. If you want faster confirmations, increase fee to 0.00011
(also it was 9xx bytes, so like at the very back of the queue)
The fee is fine for the size, its just that we currently have a little back log due to the max block size and the high number of transaction queued up. This is usually resolved fast, but it happens more often lately. DnT warned about this. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FrdOkHCh.png&t=665&c=AOX2uTvkzMuFWQ) Edit: the worste Ive seen lately was at the end of january with ~12k transactions unconfirmed.
|
Im not really here, its just your imagination.
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 14, 2015, 02:54:47 AM |
|
it's confirmed now
there have been a lot of max sized blocks lately, probably the reason it took a while.
Your tx was at 1722pm utc, there was only one block that wasn't full between then and now, that being 343315. If you want faster confirmations, increase fee to 0.00011
(also it was 9xx bytes, so like at the very back of the queue)
The fee is fine for the size, its just that we currently have a little back log due to the max block size and the high number of transaction queued up. This is usually resolved fast, but it happens more often lately. DnT warned about this. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FrdOkHCh.png&t=665&c=AOX2uTvkzMuFWQ) Edit: the worste Ive seen lately was at the end of january with ~12k transactions unconfirmed. right, and that's why you should put .00011 or .000101 or so, if you don't want to wait an extra hour
|
|
|
|
shorena
Copper Member
Legendary
Offline
Activity: 1498
Merit: 1530
No I dont escrow anymore.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 14, 2015, 08:37:58 AM |
|
-snip- right, and that's why you should put .00011 or .000101 or so, if you don't want to wait an extra hour
Now I get it. The "I play a little more fee than you" race allready started. Judging from the source[1][2] though the default setting is still to sort by priority first. Since priority is determined by age and size of the inputs the network currently gets either more expensive or slower. I havent actually noticed it while send btc, but the longer I look at the recent graphs the more I see that its now normal to wait a block or two even though you pay a fee. The strange thing is that the blocks are not full even though they could be, even with transactions paying fees. Is this miners afraid of an orphaned block due to slow propagation? [1] https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L229[2] https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L255
|
Im not really here, its just your imagination.
|
|
|
redsn0w
Legendary
Offline
Activity: 1778
Merit: 1043
#Free market
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 14, 2015, 08:41:30 AM |
|
-snip- right, and that's why you should put .00011 or .000101 or so, if you don't want to wait an extra hour
Now I get it. The "I play a little more fee than you" race allready started. Judging from the source[1][2] though the default setting is still to sort by priority first. Since priority is determined by age and size of the inputs the network currently gets either more expensive or slower. I havent actually noticed it while send btc, but the longer I look at the recent graphs the more I see that its now normal to wait a block or two even though you pay a fee. The strange thing is that the blocks are not full even though they could be, even with transactions paying fees. Is this miners afraid of an orphaned block due to slow propagation? [1] https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L229[2] https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L255In the next release of bitcoin core (0.10) it will be added the "floating fees" function : "The wallet code in the next major release of Bitcoin Core (version 0.10) will be much smarter about transaction fees. Instead of using hard-coded rules for what fees to pay, the code observes how long transactions are taking to confirm and then uses that data to estimate the right fee to pay so the transaction confirms quickly– or decides that the transaction has a high enough priority to be sent for free but still confirm quickly. There is a new option that lets you control how quickly you’d like your transactions to confirm: txconfirmtarget. The default value is 1, meaning “I’d like my transactions to be sent with enough fee or priority so they are very likely to be included in the next block.” Set it to 6 and it will take on average six blocks for your transactions to get their first confirmation." It will help a lot the people to set the "correct" fee for each transaction. More info here : - http://blog.bitcoinfoundation.org/floating-fees-for-0-10/
|
|
|
|
|
shorena
Copper Member
Legendary
Offline
Activity: 1498
Merit: 1530
No I dont escrow anymore.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 14, 2015, 01:02:22 PM |
|
Yes, I like the feature, but I doubt it will have impact on the masses as its only affecting bitcoin core/qt for now. Which makes this even more a race to higher fees, at least at times. I doubt that the higher max block size limit will solve this though.
|
Im not really here, its just your imagination.
|
|
|
erikalui
Legendary
Offline
Activity: 2632
Merit: 1094
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 14, 2015, 01:27:07 PM |
|
Blockchain often does the same with my transactions and it takes over an hour to confirm few while one transaction of mine did not get confirmed for 2 days and then the transaction was cancelled. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif)
|
|
|
|
xingming
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 322
Merit: 250
Writing to dispel society's myths.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 14, 2015, 04:44:41 PM |
|
A fee may not be required at all, if the priority of the transaction is high enough. Generally 1 BTC, one day old, is enough age and balance that you can send without a fee. If any of the individual payments are below 0.01 BTC, a minimum fee will always be required. The minimum fee, when required, is 0.0005 BTC per 1000 bytes of total transaction. The contribution of each input and each output to the total size is somewhat consistent, it only varies largely if there are compressed keys (standard for newly generated addresses on a recent client version)
|
|
|
|
|