Author

Topic: no comfirmations with fee (Read 2801 times)

member
Activity: 112
Merit: 10
February 16, 2015, 04:52:14 AM
#30
-snip-
Can I ask you where you found that graphic?

I let it generate by my node[1], I dont save old graphics though, so this one specific is only on imgur now.


[1] http://213.165.91.169/

Ah, cool! Thank you.

YESSSSSSSSSSSSSSS!!!

great stats page!!!

thank you shorena

sr. member
Activity: 252
Merit: 250
February 15, 2015, 08:56:43 PM
#29
-snip-
Can I ask you where you found that graphic?

I let it generate by my node[1], I dont save old graphics though, so this one specific is only on imgur now.


[1] http://213.165.91.169/

Ah, cool! Thank you.
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
February 15, 2015, 01:40:07 PM
#28
-snip-
Can I ask you where you found that graphic?

I let it generate by my node[1], I dont save old graphics though, so this one specific is only on imgur now.


[1] http://213.165.91.169/
sr. member
Activity: 252
Merit: 250
February 15, 2015, 01:30:07 PM
#27
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.



Edit: the worste Ive seen lately was at the end of january with ~12k transactions unconfirmed.

Can I ask you where you found that graphic?
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
February 15, 2015, 12:51:58 PM
#26
-snip-
hi shorena.
i'm interested to understand ho do you get this kind of data/chart?

From my node.

can you explan plz?
do you need to run a node to ger this kind of data???

Not sure. You could probably try to query an API for this, but I have never tried it.

or do you use a particular SW?

thanx

Only rrdtool the rest comes with linux.


-snip-

thank you Newar..
the tutorial it is for linux..
nothing for winzoz?

thanks!!!

I am not entirely sure. You could do the same requests to bitcoind on windows, but I dont know if there is something like grep, rrdtool etc. for Windows. There probably are, but I wouldnt know any. I have to admit I get confused by the Windows shell when its not accepting "ls" Wink


PS: thanks Smiley

-snip-
Yes, it's a full node. To get you started: http://213.165.91.169/whatdo.txt
legendary
Activity: 2632
Merit: 1094
February 15, 2015, 11:56:47 AM
#25
It happens with every wallet if fees aren't high enough. Transactions will drop out of mempool if the transaction is in it for a period of time waiting for confirmation. Provided that the client don't rebroadcast it, it will drop out of mempool. If client does rebroadcast it, it will confirm eventually. If you don't mind waiting for longer time and just want to have a free transaction, use a client that rebroadcast automatically or rebroadcast it yourself manually.

That is why I keep waiting for atleast one confirmation and then verify the payment I receive else it can just get cancelled. I wonder if only one confirmation is suffice or not.
member
Activity: 112
Merit: 10
February 15, 2015, 11:53:07 AM
#24
hi shorena.
i'm interested to understand ho do you get this kind of data/chart?

can you explan plz?

do you need to run a node to ger this kind of data???

or do you use a particular SW?

thanx

Yes, it's a full node. To get you started: http://213.165.91.169/whatdo.txt

thank you Newar..
the tutorial it is for linux..
nothing for winzoz?

thanks!!!
legendary
Activity: 1358
Merit: 1001
https://gliph.me/hUF
February 15, 2015, 07:03:10 AM
#23
hi shorena.
i'm interested to understand ho do you get this kind of data/chart?

can you explan plz?

do you need to run a node to ger this kind of data???

or do you use a particular SW?

thanx

Yes, it's a full node. To get you started: http://213.165.91.169/whatdo.txt
member
Activity: 112
Merit: 10
February 15, 2015, 05:45:57 AM
#22
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.



Edit: the worste Ive seen lately was at the end of january with ~12k transactions unconfirmed.

hi shorena.
i'm interested to understand ho do you get this kind of data/chart?

can you explan plz?

do you need to run a node to ger this kind of data???

or do you use a particular SW?

thanx
legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
February 14, 2015, 11:14:25 PM
#21
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
It happens with every wallet if fees aren't high enough. Transactions will drop out of mempool if the transaction is in it for a period of time waiting for confirmation. Provided that the client don't rebroadcast it, it will drop out of mempool. If client does rebroadcast it, it will confirm eventually. If you don't mind waiting for longer time and just want to have a free transaction, use a client that rebroadcast automatically or rebroadcast it yourself manually.
sr. member
Activity: 322
Merit: 250
Writing to dispel society's myths.
February 14, 2015, 11:44:41 AM
#20
https://blockchain.info/tx-index/7503a37f79e115cbc9ec6f77aa5a5fd7ae69e7900096df1954f580723de20b46

I sent this transaction a while ago and the transaction is still not confirmed after several blocks were mined. The transaction did have the usual 10k satoshi fee, so I dont know whats wrong here :/ Any help would be appreciated, thanks.

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)
legendary
Activity: 2632
Merit: 1094
February 14, 2015, 08:27:07 AM
#19
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
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
February 14, 2015, 08:02:22 AM
#18
-snip-
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/

Yes, I like the feature, but I doubt it will have impact on the masses as its only affecting bitcoin core/qt for now.

Judging from the source though the default setting is still to sort by priority first.

This appears to only occur if until the size of the high priority transactions reach a limit set in the configuration:

https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L120-L123
https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L222


If -blockprioritysize is not set (or is set less than or equal to 0), then the transactions will all be sorted by fee and priority will be ignored for fee paying transactions.

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.
legendary
Activity: 3472
Merit: 4801
February 14, 2015, 05:23:43 AM
#17
Judging from the source though the default setting is still to sort by priority first.

This appears to only occur if until the size of the high priority transactions reach a limit set in the configuration:

https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L120-L123
https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L222


If -blockprioritysize is not set (or is set less than or equal to 0), then the transactions will all be sorted by fee and priority will be ignored for fee paying transactions.
legendary
Activity: 1778
Merit: 1043
#Free market
February 14, 2015, 03:41:30 AM
#16
-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

In 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/
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
February 14, 2015, 03:37:58 AM
#15
-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
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
February 13, 2015, 09:54:47 PM
#14
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.



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
copper member
Activity: 1498
Merit: 1528
No I dont escrow anymore.
February 13, 2015, 03:04:39 PM
#13
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.



Edit: the worste Ive seen lately was at the end of january with ~12k transactions unconfirmed.
sr. member
Activity: 364
Merit: 250
February 13, 2015, 02:58:18 PM
#12
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
member
Activity: 112
Merit: 10
February 13, 2015, 02:55:14 PM
#11
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.00011 fee!
legendary
Activity: 1778
Merit: 1043
#Free market
February 13, 2015, 02:37:55 PM
#10
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.
sr. member
Activity: 364
Merit: 250
February 13, 2015, 02:33:43 PM
#9
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
legendary
Activity: 1568
Merit: 1031
February 13, 2015, 02:33:09 PM
#8

And here you go , it got confirmed Cheesy I told you just to be patient mate .
Good luck
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
February 13, 2015, 02:24:15 PM
#7
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)
sr. member
Activity: 364
Merit: 250
February 13, 2015, 01:56:49 PM
#6
member
Activity: 84
Merit: 10
works at NaSCasino.com
February 13, 2015, 01:53:39 PM
#5
sent from desktop wallet?
sr. member
Activity: 364
Merit: 250
February 13, 2015, 01:47:17 PM
#4
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
member
Activity: 84
Merit: 10
works at NaSCasino.com
February 13, 2015, 01:45:32 PM
#3
yeah, it happens, just keep an eye on it. just unlucky
legendary
Activity: 1568
Merit: 1031
February 13, 2015, 01:43:36 PM
#2
How much since you made this transaction ? It's High Priority , so it should get confirmed soon . just be patient mate
sr. member
Activity: 364
Merit: 250
February 13, 2015, 01:42:31 PM
#1
https://blockchain.info/tx-index/7503a37f79e115cbc9ec6f77aa5a5fd7ae69e7900096df1954f580723de20b46

I sent this transaction a while ago and the transaction is still not confirmed after several blocks were mined. The transaction did have the usual 10k satoshi fee, so I dont know whats wrong here :/ Any help would be appreciated, thanks.
Jump to: