ETHEREUM MICROSOFT PARTNERSHIP CONFIRMED : reason BTC PRICE RISING!!!!
RIP Ethereum |
|
|
|
OK, I'm going to bed. Don't disappoint me tonight, people.  |
|
|
|
No, global hash rate is calculated based upon the current network difficulty and the block solve times. That's why you see crazy spikes up and down in the overall hash rate - it's just an estimate. The global rate has no knowledge of any pools or their hash rate. Even pools only calculate their hash rate based upon submitted shares. They really have no idea what at what rate your miner is hashing. They estimate it based upon share submission.
That's why the difficulty adjusts every 2016 blocks... that was assumed to be a long enough time to get a pretty good overall feeling on how the network is performing and still be relatively resistant to variant spikes.
OK, that makes sense. In which case, bad luck should just be bad luck unless there's something inherent in certain ways some pools do things. |
|
|
|
oo chartbuddy just became a legend.
this is most certainly the work of gentlemen.
About time. |
|
|
|
Bad luck seems to be a problem with many pools atm, I've been reading loads of theories on pool threads as to why. Personally, I think it's just the increased diff - any thoughts anyone?
BTW, I can't remember the last time I found an NMC block - anyone else found one lately?
Isn't the global has rate just calculated by the rates as self-reported by pools? If a pool added a bunch of hash rate and didn't report it, that could explain it. One thing is sure, if some are getting unlucky, someone else is getting lucky. Unless the time between blocks is getting longer (and there's another difficulty adjustment soon and it looks like it's going up, not down). |
|
|
|
|
Total network hashrate is 440.070 PH/s (this is an estimation, I believe)
Antpool has 90.68 PH/s according to their website.
144 blocks per day
So 100% luck would be about 29.7 blocks/day depending on fluctuations.
The hashrates in your list are lower so fewer blocks for 100% luck but again, fluctuations and estimations...
|
|
|
|
Though also in the log with the same error are the private IP of my p2pool node and the private IP of my router.
unlock (manually with rule on a fixed IP) the NAT : p2pool 9333 TCP Not sure what you mean by unlock but I do already have 9333 port forwarded. Been running gangbusters since starting with a fresh install of p2pool FWIW. |
|
|
|
Not recently but I do other stuff on that system that runs with no issue. I'll schedule a disk scan and some time with memtest but I personally don't think that's going to be it. I am trying with a clean install of p2pool to see where that gets me though. |
|
|
|
err is that an internal ip, there reserved.
I'm thinking it should be ok to not hide them.
Sorry, no, I should have specified. That is my external public IP Though also in the log with the same error are the private IP of my p2pool node and the private IP of my router. Looks like p2pool got itself into a state somehow. These are also in the addrs file so that would be why it persists I guess. |
|
|
|
|
More of a clue?
2015-10-22 19:08:36.403770 Peer xx.xx.xx.xx:9333 misbehaving, will drop and ban. Reason: was connected to self
2015-10-22 19:08:36.403893 Bad peer banned: (u'xx.xx.xx.xx', 9333)
Where this is my IP in the logs.
I also see this for other IP addresses so maybe I was somehow connected to myself and other nodes saw it and have banned me? How can this be avoided in future?
|
|
|
|
OK, The issue has now been affecting me since 9am this morning I have tried restarting bitcoind and p2pool both separately and together and the problem persists. I have actually tried copying the p2pool directory and cleaning out the data/bitcoin directory. When I did this, I noticed p2pool was not able to stay connected to peers to download shares. I copied the "addresses" file into the directory again and a few shares are downloading but I am still getting a lot of disconnects. The error is this: 2015-10-22 19:43:23.180634 Lost peer xx.xx.xx.xx:9333 - Connection was aborted locally, using. I am beginning to think that I am getting blocked by p2pool on other hosts. Is there any way to check this? |
|
|
|
|
[Deleted] Want to do some more research before jumping on this one.
|
|
|
|
It still is. There is no necessary contradiction in a modern social democracy. Why do you think the Swedes didn't bail out SAAB or Volvo like the US bailed out GM and Chrysler?
Yup, just like it's perfectly possible to live a pretty good life with a 3lb tapeworm in your gut. The most successful parasites take a long time to kill the host. If the tapeworm provides free health care then Bob's your uncle. "Free" |
|
|
|
It still is. There is no necessary contradiction in a modern social democracy. Why do you think the Swedes didn't bail out SAAB or Volvo like the US bailed out GM and Chrysler?
Yup, just like it's perfectly possible to live a pretty good life with a 3lb tapeworm in your gut. The most successful parasites take a long time to kill the host. |
|
|
|
anybody want to go in with me on this and resell them on Amazon? You need to buy a minimum of 333 and I don't have that kind of coin just lying around. Ok, maybe I do, but I'm not going to spend that much.
That's just for the chips though, right? Then you actually have to turn them into a miner. You also forgot to mention the price. The total for 333 chips comes out to $68,000 according to the article. |
|
|
|
It wouldn't be an effective attack unless there was genuine disagreement to exacerbate. The shrinking number of nodes could be easily fixed by borrowing a trick from our Proof of Stake friends: Take some fraction of the block reward away from the miners and distribute it to full node operators. Small miners already running nodes would be largely unaffected. Pool miners would take a little hit, but that's a good thing, right? Pools are a threat to decentralization, aren't they?
I think this is a good point. I don't necessarily think that node operators should be paid for just running nodes (it's certainly a point for discussion though) but the idea that people would be running them altruistically is just plain nonsense. If you have a reason to run a node, it should be because it has value to you, not because you're a nice guy. Thus you should be willing to invest the money in whatever it takes to run that node. Maybe it supports a service you sell or maybe you just find it valuable to be in control. Bitcoin is built around market incentives and the idea of imposing artificial controls to enable people to run nodes "Just because they should" makes little sense to me. |
|
|
|
I couldn't do this with HDD's. No way. So yeah, SSD's are the way to go - but use quality ones. I'm a huge fan of the HyperX - I run one in my PC too, and my Netbook.  I had good lock with the Sandisk in 125 so I stuck with the make when I went to 250 but stepped up to Ultra II. I like it so far and I've bought a couple more to throw in laptops when I get time to do the imaging... Looking at my server where I also run the bitcoind, it looks like the system partitions would fit on with room to spare so I may go with bitcoind and p2pool on there. That's if I can remember how to get through the nightmare that is setting up a drive to work with UEFI on my motherboard. |
|
|
|
That system is using spinning-disk media.
A HDD? Do people still use them?  I'd ditch that if I were you - they're terrible for Bitcoin wallet, p2pool & mining in general. Only good for servers now. Glad we got to the bottom of this, it was a head banger for me, so I'm sure it was doing your nut in!  Haha, yeah. It's pretty OK for Bitcoind as mostly you're just storing 60GB of history and they are great for long-term storage of bulky data that is not speed sensitive. I do have a 125G SSD that I just upgraded from from my workstation so I may throw that in as the boot disk but I doubt I'd put the blockchain on it. Now, if someone want to tell me it would really benefit to have p2pool use one, I'm willing to listen. |
|
|
|
this flat section is a freeze of bitcoind process (freeze of bitcoin deamon server RPC-JSON). you have this, too ... when sharechain of P2Pool (local files) have a problem ... (remember this : 17500 shares valid v14 but 20650 shares available ...). XT node with maxmempooltx purge system draw this :  No offline section. That would explain things... if the bitcoind process was frozen and you were still mining to that node that actually explains everything. Because bitcoind wasn't fetching new blocks, p2pool was always mining to an old block. You were submitting shares just fine on your node. The rest of the network was rejecting your shares (since they were from old blocks). Then when things came back to life on your node, things caught back up, the shares you submitted were immediately dropped and your expected payment went to what the network thought it should be.
In effect, even though your miners were mining, they weren't doing anything useful because they were solving shares for blocks that were already on the chain.
Yes - that sounds like the problem to me too - well spotted Meuh6879 Looks like that's my answer then. Thanks guys. I guess the increased bandwidth was probably because I kept spewing shitty info to other nodes and they kept re-requesting it (or however that bit works). I guess the question is how best to prevent this going forward. I don't have any objection to XT (I'm already running the BIP101 patch) so that may be the way to go. |
|
|
|
Yeah, that looks nothing like my monthly chart at all.  Did you redownload the p2pool sharechain yet?  Edit: Here's mine (click for larger) Edit1: It might even be a dodgy SSD? Yep. Restarted this morning at 9:10am. That system is using spinning-disk media. |
|
|
|
|
Show Posts
