|
Other than the OS, bitcoind is the only thing running on server 2. The bitcoin daemon is acting as a redundant node for my pool's stratum server, so RPC calls to create blocks are coming from the stratum server. Also, I've noticed the outgoing traffic is absolutely absurd - and am likely going to have to shut down this server because of it (over 225G of data in the past couple hours).
|
|
|
|
Sure... why not  Take advantage of the low rental rates on NH! For the next 8 hours and 45 minutes (until Midnight EDT) if you are the block finder, I will send you an extra 1 BTC on top of the already running promotion. |
|
|
|
|
Restarting the bitcoin daemon on server 2 caused exactly the same result as I posted originally: it quickly synchronized up the missing blocks.
This behavior of getting "stuck" for lack of a better term is completely baffling to me.
|
|
|
|
Alright... so it's happening right as of this moment. I have bitcoin daemons running on two servers. On server 1, the daemon is fully synchronized. On server 2, it is a few blocks behind. Server 1 is connected to server 2 and vice-versa via addnode= in the bitcoin.conf file. Every now and then when I run bitcoin-cli getinfo command on server 2, I get the following result: bitcoin-cli getinfo
error: couldn't parse reply from server
When it does successfully execute, I see this: bitcoin-cli getinfo
{
"version": 120000,
"protocolversion": 70012,
"blocks": 406654,
"timeoffset": 0,
"connections": 17,
"proxy": "",
"difficulty": 166851513282.7772,
"testnet": false,
"relayfee": 0.00005000,
"errors": ""
}
Running exactly that same thing on server 1: bitcoin-cli getinfo
{
"version": 120000,
"protocolversion": 70012,
"blocks": 406659,
"timeoffset": 0,
"connections": 53,
"proxy": "",
"difficulty": 166851513282.7772,
"testnet": false,
"relayfee": 0.00005000,
"errors": ""
}
I also notice that on server 2, the bitcoin-cli getinfo command takes a few seconds to respond. This makes absolutely no sense to me. Why would the bitcoin daemon on server 2 be behind that on server 1? |
|
|
|
Had to address something in the stratum server that required a restart. Apparently I hadn't had enough coffee yet and missed something (a few times) so had to bounce the stratum server a few more times than I anticipated. Sorry about the turbulence, folks. Everything's up and running smoothly again. Feel free to move about the cabin  |
|
|
|
The pool is running on OVH in Montreal - so hosted in neither US nor India. I wouldn't put much faith in the info posted in the first post. He largely copied my pool's announcement and changed a few things. OP - Again, congrats on finding the block. I suggest you spend a whole lot of time learning what being a pool operator means, and especially how to maintain and address issues with the software you're using. For example, how are you going to address the problem you have with your round statistics? Here's a hint: 2^31 - 1. Another thing... I'm quite sure your pool vardiff is not running the range you claim in your OP - you simply copied my pool announcement. Might want to actually lookup the ranges and post correct information. Finally I wanted to address this post of yours: the pool is made on the same github code that's why and other pools will be like that to but they will be different in colors and if you think that we have copied the pool then you don't have any knowledge in bitcoin pool
Yeah... except it's not. Whoever you purchased the pool from (see your own site's footer for that information) used an old copy of the MPOS github code and changed at the very least the footer - which by the way is not cool since he didn't actually write the software. Don't go around bashing people about not having knowledge in bitcoin pools. Purchasing a pool solution doesn't make you knowledgable. In fact, it makes you appear quite the opposite since the software you are using is open source and freely available on github. |
|
|
|
|
Wow... you aren't kidding. Great prices indeed!
|
|
|
|
|
NH is easy. You create an order for X hash and pay Y amount for it. The problem is that you can be outbid - as is the case with my order right now. I paid 0.003 per TH for my order. There are now two orders: 5PH at 0.0036 and infinite at 0.0035. Those two orders are consuming almost all of the available hash.
It's a hell of a gamble. That 5PH for 0.0036 costs 0.75BTC an hour to maintain (18 coins a day).
|
|
|
|
|
Looks like my order is on hold since somebody threw up an infinite hash order for 0.0034. Hopefully that runs out soon...
|
|
|
|
I'll play...  Just waiting on a confirm from NH... The more the merrier hope so guys i got 3th pointed not a lot but all i got lol
Every hash counts. And if one of anyone's besides mine happens to solve a block - bonus BTC to the finder! |
|
|
|
|
As p3yot33at3r mentioned, Bitmain's awful fork of cgminer causes loss of hash rate on p2pool. Neither -ck nor kano have provided any official S7 cgminer patches, so you're stuck with using Bitmain's.
While changing the queue value can help, you're still going to lose hash rate if you mine on p2pool with virtually any Bitmain product.
|
|
|
|
Let's crack a block or three |
|
|
|
I'm getting ready to rent some hashing power The price looks good right now, does anybody want to match me? let's find that block!!! Wish I had seen this last night... I would have played . No time like the present, however. As soon as the coin confirms, I'll put up 1PH for the next 16 hours or so. |
|
|
|
|
Congrats on finding your first block. Of course, since you found it, you didn't have to give away the block finder's bonus coin or miners. At least now you'll have enough coin in your wallet to actually pay somebody the bonus and purchase the miners.
By the way... you haven't actually paid anybody yet since the block hasn't matured.
|
|
|
|
For the first time since I launched the pool, I am not the top share contributor. That means a bunch of other people are stepping up and throwing some hash here. I think that is great, and I want to thank every one of you for your contributions to the pool! I'm very hopeful that somebody besides me solves a block here. I want to give away this bonus coin! We are still nicely in the green this round at only 34.4% of expected shares. Overall the pool is in the green since inception (97.77%). My next goal is to not see myself as the top contributor hash rate . |
|
|
|
Also very true! If only I could push many PH maybe someday. You can! Just log into NH and create infinite orders for 0.004 BTC per TH on both NH and WH. Voila! Many PH at your disposal |
|
|
|
|
Thanks for the update shorena. Thankfully I haven't seen that behavior again recently on my nodes, so maybe it was indeed just a bunch of bad nodes I was connected to. If I do encounter it again, I'll certainly ping the nodes to which I am connected to see if they're up to date. I added your node, so next time I restart the coin daemons, they'll connect up to you.
|
|
|
|
|
It's been occurring since the beginning. Bitcoin provides no guarantees that a block will occur every 10 minutes. Sometimes blocks occur seconds after each other. Other times, they don't occur for over an hour.
|
|
|
|
|
How about bounty for an OS X wallet?
|
|
|
|
|
Wow... NH is nuts right now. 9PH of rentals paying ~10% over expected earnings. That'll be either an expensive lesson or a hell of a windfall.
|
|
|
|
|
Show Posts
