Subo1977
Sr. Member
Offline
Activity: 344
Merit: 250
Flixxo - Watch, Share, Earn!
|
|
May 19, 2013, 09:05:33 PM |
|
Default settings are: mintxfee=0.0001 minrelaytxfee=0.0001
If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm. These settings will get your getblocktemplate latency down: mintxfee=0.0005 minrelaytxfee=0.0005
I think These Settings Must be in satoshis for the latest git
These settings need to be in floats as BTC. ( https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L417). Will edit if someone corrects me. Look at https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L51The Parameter Is In satoshi
|
|
|
|
|
|
|
|
|
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
|
May 19, 2013, 09:12:24 PM |
|
So I'm wondering whether the current long round time is related to the high latency issue. I've clicked on over a dozen of the servers in the list at http://p2pool-nodes.info/ and every single one of them has had a getwork template latency of >10 seconds. I'm currently running a reindex on my bitcoind. It found a heap of orphan transactions and is now re-downloading the blockchain from around height 100,000... I think I'm also going to have to temporarily switch to a different pool, until this catches up. mine is on there and doesn't have one over 10 seconds i mean, the answer has already been posted on here multiple times here: http://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1Tyou fix this by raising your min relay fee Sun May 19 2013 08:12:00 GMT-0500 (Central Daylight Time) 7.89m Sat May 18 2013 15:24:00 GMT-0500 (Central Daylight Time) 0.0150 Fri May 17 2013 22:36:00 GMT-0500 (Central Daylight Time) 0.0124 Fri May 17 2013 05:48:00 GMT-0500 (Central Daylight Time) 7.61m Thu May 16 2013 13:00:00 GMT-0500 (Central Daylight Time) 0.0184 Wed May 15 2013 20:12:00 GMT-0500 (Central Daylight Time) 9.67m Wed May 15 2013 03:24:00 GMT-0500 (Central Daylight Time) 9.19m Tue May 14 2013 10:36:00 GMT-0500 (Central Daylight Time) 0.0336 Mon May 13 2013 17:48:00 GMT-0500 (Central Daylight Time) 0.0317 Mon May 13 2013 01:00:00 GMT-0500 (Central Daylight Time) 8.21m Sun May 12 2013 08:12:00 GMT-0500 (Central Daylight Time) 0.0193 Sat May 11 2013 15:24:00 GMT-0500 (Central Daylight Time) 0.0149 Fri May 10 2013 22:36:00 GMT-0500 (Central Daylight Time) 0.0130 Fri May 10 2013 05:48:00 GMT-0500 (Central Daylight Time) 0.0122 Thu May 09 2013 13:00:00 GMT-0500 (Central Daylight Time) 0.0180 Wed May 08 2013 20:12:00 GMT-0500 (Central Daylight Time) 0.0183 Wed May 08 2013 03:24:00 GMT-0500 (Central Daylight Time) 0.00 Tue May 07 2013 10:36:00 GMT-0500 (Central Daylight Time) 0.0110 Mon May 06 2013 17:48:00 GMT-0500 (Central Daylight Time) 8.49m Mon May 06 2013 01:00:00 GMT-0500 (Central Daylight Time) 6.06m Sun May 05 2013 08:12:00 GMT-0500 (Central Daylight Time) 7.25m Sat May 04 2013 15:24:00 GMT-0500 (Central Daylight Time) 9.19m Fri May 03 2013 22:36:00 GMT-0500 (Central Daylight Time) 5.98m Fri May 03 2013 05:48:00 GMT-0500 (Central Daylight Time) 0.0133 Thu May 02 2013 13:00:00 GMT-0500 (Central Daylight Time) 0.0159 Wed May 01 2013 20:12:00 GMT-0500 (Central Daylight Time) 0.0103 Wed May 01 2013 03:24:00 GMT-0500 (Central Daylight Time) 7.86m btw, again for the nth time raising mintxfee just raises the cost for any transactions that YOU create
|
|
|
|
kano
Legendary
Offline
Activity: 4494
Merit: 1808
Linux since 1997 RedHat 4
|
|
May 19, 2013, 09:52:11 PM |
|
Default settings are: mintxfee=0.0001 minrelaytxfee=0.0001
If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm. ... Wrong ... that many other pools WILL confirm ... usual comments about how people (it seems often) make p2pool bad for bitcoin ... ... and when people do this, the rest of p2pool is supporting them by paying them in their blocks also ...
|
|
|
|
|
daemondazz
|
|
May 19, 2013, 10:36:17 PM |
|
What exactly do you mean by "catches up"? Will everybody need to update their bitcoind etc?
I meant for the re-index to complete and the daemon to then catch up with the network. I've got two servers which both required a reindex, not sure what's up with that. you fix this by raising your min relay fee
And as I've posted, I tried to set minrelaytxfee to 0.0005 and also 5000 and neither made any difference, the latency kept going back up after some period of time, usually less than an hour.
|
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
gyverlb
|
|
May 19, 2013, 11:00:09 PM |
|
Default settings are: mintxfee=0.0001 minrelaytxfee=0.0001
If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm. ... Wrong ... that many other pools WILL confirm ... usual comments about how people (it seems often) make p2pool bad for bitcoin ... ... and when people do this, the rest of p2pool is supporting them by paying them in their blocks also ... Yeah right, looks like other pools are confirming these transactions: http://blockchain.info/fr/unconfirmed-transactionsCurrently that's 21MB worth of transactions which is at least 40 blocks with the default bitcoind settings (~500kB). kano, just go embarass yourself elsewhere.
|
|
|
|
gyverlb
|
|
May 19, 2013, 11:04:37 PM |
|
All values are stored in satoshi in the code (everything is done with integers, floats would have been a nightmare) but the configuration file parsing definitely is designed to parse a float.
|
|
|
|
gyverlb
|
|
May 19, 2013, 11:07:25 PM |
|
btw, again for the nth time
raising mintxfee just raises the cost for any transactions that YOU create
Do you have a link to code/documentation proving this? AFAIK there's paytxfee for that, mintxfee is for what you accept in your blocks when you mine and minrelaytxfee is what you accept to relay to other nodes.
|
|
|
|
gyverlb
|
|
May 19, 2013, 11:10:11 PM |
|
btw, again for the nth time
raising mintxfee just raises the cost for any transactions that YOU create
Do you have a link to code/documentation proving this? AFAIK there's paytxfee for that, mintxfee is for what you accept in your blocks when you mine and minrelaytxfee is what you accept to relay to other nodes. So to avoid too much memory being eaten by the thousands of transactions currently waiting to be confirmed the only way is to raise both minrelaytxfee and mintxfee. If the current situation continues it seems the time when low fees where usable is ending: people will have to compete to be included in a block. Currently there's 40 blocks worth of transation, this is a 6 to 7 hours backlog.
|
|
|
|
daemondazz
|
|
May 20, 2013, 12:04:46 AM |
|
Very useful link there. As a matter of interest, how big is the list of unconfirmed transactions normally?
|
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
kano
Legendary
Offline
Activity: 4494
Merit: 1808
Linux since 1997 RedHat 4
|
|
May 20, 2013, 12:18:09 AM |
|
btw, again for the nth time
raising mintxfee just raises the cost for any transactions that YOU create
Do you have a link to code/documentation proving this? AFAIK there's paytxfee for that, mintxfee is for what you accept in your blocks when you mine and minrelaytxfee is what you accept to relay to other nodes. So to avoid too much memory being eaten by the thousands of transactions currently waiting to be confirmed the only way is to raise both minrelaytxfee and mintxfee. If the current situation continues it seems the time when low fees where usable is ending: people will have to compete to be included in a block. Currently there's 40 blocks worth of transation, this is a 6 to 7 hours backlog. ... so what happens during that 6 to 7 hours ?
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
May 20, 2013, 12:19:35 AM |
|
Default settings are: mintxfee=0.0001 minrelaytxfee=0.0001
If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm. ... Wrong ... that many other pools WILL confirm ... usual comments about how people (it seems often) make p2pool bad for bitcoin ... ... and when people do this, the rest of p2pool is supporting them by paying them in their blocks also ... Yeah right, looks like other pools are confirming these transactions: http://blockchain.info/fr/unconfirmed-transactionsCurrently that's 21MB worth of transactions which is at least 40 blocks with the default bitcoind settings (~500kB). kano, just go embarass yourself elsewhere. This discussion has come up before. I believe some pool ops are limiting transactions, but I know some aren't. At least that's what was stated last time. The future of bitcoin is transactions. I fail to see how limiting transactions can be beneficial to bitcoin, especially as the value of BTC rises. For example, if it was worth $1000 USD, there's no way I'd spend .01 on a transaction ($10). M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
|
May 20, 2013, 12:26:40 AM Last edit: May 20, 2013, 12:54:14 AM by zvs |
|
What exactly do you mean by "catches up"? Will everybody need to update their bitcoind etc?
I meant for the re-index to complete and the daemon to then catch up with the network. I've got two servers which both required a reindex, not sure what's up with that. you fix this by raising your min relay fee
And as I've posted, I tried to set minrelaytxfee to 0.0005 and also 5000 and neither made any difference, the latency kept going back up after some period of time, usually less than an hour. 5000 is too low, it would need to be 50000 if that's the way it works (5000 is 0.00005). I've never modified the fees except via source code. Transactions like this: http://blockchain.info/tx/fe03d93a778f881d11a66c7d13c667701f24ff9b97d7d083d6dd3827aee0d553will go into your queue if you don't raise the relay from 0.0001 (*pre 0.8.2, i think the 0.0000025 would get rejected by 0.8.2). He's done a lot of transactions that comply with the 0.0001 fee, all these will be stored & increase your latency. it's also the reason why ppl complain about how their latency creeps up over time (even before this nonsense). bitcoind getmininginfo will show all the stored tx. if your relay fee is set high enough, all of those get cleared out. i think his coins are also old enough to qualify as priority transactions (which has a default 27000 limit, so your client will also store all of his transactions under 27000 bytes regardless of fee, unless you set blockprioritysize=0). if these are set to default, with this horse person spamming crap, then you will have, well, more 99kb and 20-27kb transactions than you can shake a stick at being stored in memory, bitcoind getmininginfo will show this for bitcoind. i never use bitcoin-qt ed: btw, has anyone ever seen a 'CTxMemPool::accept() : free transaction rejected by rate limiter' in their log? ed2: the unconfirmed transactions i check fairly frequently, very rarely has it been over 500KB in the last 3 months or so... during the times where difficulty was decreasing, it would occasionally be >1MB ed3: it should be pretty apparent what most of the major pools are doing in regard to relay fees, just by looking at the latest blocks and the transactions contained within
|
|
|
|
gyverlb
|
|
May 20, 2013, 12:45:27 AM |
|
Very useful link there. As a matter of interest, how big is the list of unconfirmed transactions normally? I didn't check this value for quite some time. But if the rate of transactions is below the network's capacity (around 500kB every 10 minutes currently, could potentially rise to 1MB every 10 minutes depending on how miners setup their bitcoind), this value should be below 500kB most of the time (assuming blockchain.info only includes valid tx in this number which is probably the case).
|
|
|
|
Amph
Legendary
Offline
Activity: 3206
Merit: 1069
|
|
May 20, 2013, 12:05:19 PM |
|
still no bitcoin from the last time i mined(3 days ago)
|
|
|
|
centove
|
|
May 20, 2013, 12:41:36 PM |
|
FWIW... bitcoind - current git master (8.2.0) default (I changed nothing): bitcoind getmininginfo { "blocks" : 237053, "currentblocksize" : 249858, "currentblocktx" : 732, "difficulty" : 11187257.46136079, "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications", "generate" : false, "genproclimit" : -1, "hashespersec" : 0, "pooledtx" : 1710, "testnet" : false }
Latency climbing up to around 2 seconds.... http://ask.gxsnmp.org/
|
|
|
|
gyverlb
|
|
May 20, 2013, 01:12:25 PM |
|
still no bitcoin from the last time i mined(3 days ago)
If you stopped mining 3 days ago and you are speaking of your p2pool rewards I don't see how it can be news.
|
|
|
|
gyverlb
|
|
May 20, 2013, 01:15:43 PM |
|
FWIW... bitcoind - current git master (8.2.0) default (I changed nothing): bitcoind getmininginfo { "blocks" : 237053, "currentblocksize" : 249858, "currentblocktx" : 732, "difficulty" : 11187257.46136079, "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications", "generate" : false, "genproclimit" : -1, "hashespersec" : 0, "pooledtx" : 1710, "testnet" : false }
Latency climbing up to around 2 seconds.... http://ask.gxsnmp.org/2 seconds is not bad, people have seen 10+ seconds. I have 0.13s with mintxfee and minrelaytxfee set to 0.001 with this result: { "blocks" : 237057, "currentblocksize" : 99814, "currentblocktx" : 345, "difficulty" : 11187257.46136079, "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications", "generate" : false, "genproclimit" : -1, "hashespersec" : 0, "pooledtx" : 1221, "testnet" : false }
I'll set these two to 0.002 next time I have the chance.
|
|
|
|
Amph
Legendary
Offline
Activity: 3206
Merit: 1069
|
|
May 20, 2013, 02:48:12 PM |
|
still no bitcoin from the last time i mined(3 days ago)
If you stopped mining 3 days ago and you are speaking of your p2pool rewards I don't see how it can be news. so those share are lost?
|
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
|
May 20, 2013, 02:51:06 PM |
|
still no bitcoin from the last time i mined(3 days ago)
If you stopped mining 3 days ago and you are speaking of your p2pool rewards I don't see how it can be news. so those share are lost? Yes. PPLNS in P2pool is pyain for last 24hrs of mining. Up to 3 blocks per every share.
|
|
|
|
|