no comfirmations with fee | Bitcointalksearch.org

rollingMyCar

member

Activity: 112

Merit: 10

Quote from: jeffhuys on February 15, 2015, 09:56:43 PM

Quote from: shorena on February 15, 2015, 02:40:07 PM

Quote from: jeffhuys on February 15, 2015, 02:30:07 PM

-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

jeffhuys

sr. member

Activity: 252

Merit: 250

Quote from: shorena on February 15, 2015, 02:40:07 PM

Quote from: jeffhuys on February 15, 2015, 02:30:07 PM

-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.

shorena

copper member

Activity: 1498

Merit: 1499

No I dont escrow anymore.

Quote from: jeffhuys on February 15, 2015, 02:30:07 PM

-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/

jeffhuys

sr. member

Activity: 252

Merit: 250

Quote from: shorena on February 13, 2015, 04:04:39 PM

Quote from: zvs on February 13, 2015, 03: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)

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?

shorena

copper member

Activity: 1498

Merit: 1499

No I dont escrow anymore.

Quote from: rollingMyCar on February 15, 2015, 06:45:57 AM

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

From my node.

Quote from: rollingMyCar on February 15, 2015, 06:45:57 AM

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.

Quote from: rollingMyCar on February 15, 2015, 06:45:57 AM

or do you use a particular SW?

thanx

Only rrdtool the rest comes with linux.

Quote from: rollingMyCar on February 15, 2015, 12:53:07 PM

-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

Quote from: Newar on February 15, 2015, 08:03:10 AM

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

erikalui

legendary

Activity: 2632

Merit: 1094

Quote from: ranochigo on February 15, 2015, 12:14:25 AM

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.

rollingMyCar

member

Activity: 112

Merit: 10

Quote from: Newar on February 15, 2015, 08:03:10 AM

Quote from: rollingMyCar on February 15, 2015, 06:45:57 AM

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!!!

Newar

legendary

Activity: 1358

Merit: 1000

https://gliph.me/hUF

Quote from: rollingMyCar on February 15, 2015, 06:45:57 AM

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

rollingMyCar

member

Activity: 112

Merit: 10

Quote from: shorena on February 13, 2015, 04:04:39 PM

Quote from: zvs on February 13, 2015, 03: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)

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

ranochigo

legendary

Activity: 2954

Merit: 4158

Quote from: erikalui on February 14, 2015, 09:27:07 AM

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.

xingming

sr. member

Activity: 322

Merit: 250

Writing to dispel society's myths.

Quote from: michinzx on February 13, 2015, 02:42:31 PM

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)

erikalui

legendary

Activity: 2632

Merit: 1094

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

shorena

copper member

Activity: 1498

Merit: 1499

No I dont escrow anymore.

Quote from: redsn0w on February 14, 2015, 04:41:30 AM

-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.

Quote from: DannyHamilton on February 14, 2015, 06:23:43 AM

Quote from: shorena on February 14, 2015, 04:37:58 AM

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.

DannyHamilton

legendary

Activity: 3388

Merit: 4615

Quote from: shorena on February 14, 2015, 04:37:58 AM

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.

redsn0w

legendary

Activity: 1778

Merit: 1042

#Free market

Quote from: shorena on February 14, 2015, 04:37:58 AM

Quote from: zvs on February 13, 2015, 10:54:47 PM

-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/

shorena

copper member

Activity: 1498

Merit: 1499

No I dont escrow anymore.

Quote from: zvs on February 13, 2015, 10:54:47 PM

-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

Quote from: shorena on February 13, 2015, 04:04:39 PM

Quote from: zvs on February 13, 2015, 03: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)

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

shorena

copper member

Activity: 1498

Merit: 1499

No I dont escrow anymore.

Quote from: zvs on February 13, 2015, 03: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)

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.

michinzx

sr. member

Activity: 364

Merit: 250

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

rollingMyCar

member

Activity: 112

Merit: 10

Quote from: redsn0w on February 13, 2015, 03:37:55 PM

Quote from: michinzx on February 13, 2015, 03:33:43 PM

Quote from: zvs on February 13, 2015, 03: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)

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!

Topic: no comfirmations with fee (Read 2773 times)