My Evo client ist a block 123073 right now:
geblockhash 123073
94126577117a19fe0b32f68fe327c2095e17875f69f485f15b37dd5376836182

But all my valid connections are to 1.2.0.1 Clients :/

How is the network status right now?

I just looked into my desktop wallet, and it shows only connections to 1.2.0.1 clients with my 1.4.3.1 wallet.
All newer wallets have problems, most of them are stuck at 122999 and my clients kills these connections.

I have the same block hash:

getblockhash 123010
ad6f362c94ff32ebd0875a1686529fb21e5bbb15ab5afc93c8af7310b32bdcc3



P.S.: By the way: Purepool is in maintenance right now, until all is working fine again

Mhhh, that sounds strange and required a deeper look into it. The numbers of the main pool and purepool should be close/the same.
I just looked into the transaction list, and saw that some are not done /marked as error. Maybe that is the source of that.

I will try to look into it in the weekend, sadly I'm away again right now and can not do it right away :/

Yes, purepool checks the nonce on every share.


Yes, I'm a sure the numbers are right
But as said, my test might be simply different from what capulo had done. My test was much shorter, too. I simply can't run the test for 4 hours right now, I need to wait for the weekend to do that.

But at the same time, I'm not sure if there isn't another factor of importance here:


No, purepool does not limit the threads. No information given by the client that can not be verified is part of the checks. Only the calculated share is of importance, it must be unique and valid.
Everything else seems quite easy to fake, so I don't think it is of any use to build on these.

But given that 40 threads and 320 theads are quite different, what happens if you run 8 wallets with 5 threads each = 40 threads. That would be a fair run, and ensure that the thread count isn't the "problem".

Aside from that, I'm not sure how any of this could be prevented, if it is true. What stops a user from creating multiple accounts on the main pool or purepool and run one wallet of the multi wallet setup per account against the pool? We could check the ip address, but that would harm other users, too, if we allow only one miner per IP.

You calc 1 wallet/40 threads  =40 threads  vs.   8 wallets/40 threads = 320 threads?
If that is right, what happens if you calc 1 wallet/320 threads?

So, I run my test against purepool, but I couldn't verify what happened on the main pool.
Maybe my tests are wrong, but in my tests, a single wallet gets around 25% more shares than a multiwallet setup. Looks like the overhead kills hit here.

My test system: I created an VM with ubuntu 18.04 and biblepay from the official repo. I created a new wallet and run it for 1 hour against purepool with 16 threads on my cpu (with 16 cores).
After that, I created 8 new wallets (each from scratch) and pointed them to a new biblepay adress in purepool, each with two threads. The cpu usage was the same with both setups.
I even gave the multiwallet setup two minutes more time, as they needed more time to fully start.

I tried it with more wallets (16), but my internet connection died trying it. Not sure why, I suspect my internet box died with the many open connections.
Maybe it wasn't enough wallets, but I can't test with more until the end of the week with more wallets.

Was my setup wrong?

Still not sure how this would work. I will try to test on multiwallets this weeks, but I have still no idea how this could work. Shouldn't be a multiwallet miner even be slower because of the overhead of multiple instances running?

Oh, that looks nice. Biblepay Central is down right now, but if your tool is making good progress, I can transfer you the domain if you like.

In this case Purepool should not be affected, as it only counts the valid shares of the users. No HPS2 tricks or anythink like that

Everybody should mine normal in pool mode on purepool right now. I did a hotfix for the podc/cpid problem yesterday.
I see normal mining on my own systems, too. Plus I see regular outgoing transactions.

Edit: But biblepay-central.org was way out of date. I disabled it for now.

Simply set minersleep= and the right amount of genproclimit
Running more wallets only forces the OS to do more context switches, so you will be slower. There is no way to "screw this system", as there is no artifical block in POBH. You get a block if you can calculate the right result, running more clients won't help, as your system is not getting more powerful this way.
There might be edge cases in which two wallets might help, but running 56 Wallets is bullshit

Edit: If "system" means the official pool, that might be a different story. I remember hacks like this. But this is not biblepay itself.

I just did an hotfix, should be fine from now on

I will have a look at it, thx

I hadn't followed the latest development, plus I never really enjoyed PODC and had only used it for a short time. So I'm not uptodate on this topic.

@Rob: Is the CPID still required? I'm not uptodate with the current updates

Purepool is on this chain now

This is my old one I still maintain, but most of the time with a longer "gap" between new release and packages build.

Official repo infos:
http://wiki.biblepay.org/Ubuntu_Packages

The older Ubuntu PPA compiles the new release right now. After that is finished, Purepool will be updated (again...)

Purepool is updated and resyncing right now

Hope I can do it in the next 2-3 hours.