Topic: BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh) - page 7. (Read 13217 times)

-> Regarding the password manager: We cant support debugging the pool with that on.  I went as far as renaming the password field behind the scenes, to something unrelated to passwords, but thats as far as I can go with that.  However, what I did do is I debugged the issue in a browser without a password cache, and verified that we absolutely do not populate the password field with any text on the page load now - (text was being populated before into the control - but that was a bug).  Now when you go to the page, the pass is initially blank.  If you populate it, it saves the new pass.  So I consider this fixed now.

-> Firefoxs extremely convoluted view is fixed (I had no idea it was like that).

-> Regarding nav links, thats a microsoft thing- they are rendering a whole bunch of stuff down with the aspx page.

-> Other fields not populating on account- Yes, you found a bug there.  The page has been upgraded to use the simple framework now, and is cleaner, and now populates all the fields every time.

-> On UserText1, btw, that is just a storage field for the user (the pool doesnt use it).  What I meant was, if you navigate to Account, ensure the password field is empty, and only change usertext1, and save the record, then you can logoff and back on and know that it did not update the password but it does update usertext1.

Hey eh eh, it looks like were back to high performance (in the pool) now.
The stored procs worked, and I think adding them improved the quality of the system & code anyway.

Hopefully we can make it through the next 30 days now, with high load.
I moved the Leaderboard link back to the protected area, in case it was being abused by the outside.

Ill take a look at the account issue next.

Yea, Im working on it, I have a couple new ideas that may or may not work.
Im going to convert a core part of the system over to stored procs and try that next (that might let the database server do 3-4 operations at a time, while right now they are one at a time).
After that, Ill look into running two instances and splitting the load.

Cant say exactly how long, but Im working on it now.

Raising the diff on the big dogs didnt help so Ill be putting that back.

it's a lost day and lots of troubles after the last update . 
2/3 of my workers are running dry and not even show up in account .

thanks for the explanation . 

I think he means increasing the share difficulty based on miner hash rate like you see in most pools. I'm not a mining pool engineer so maybe I'm a little off, but my understanding is that everyone in the pool is working towards solving the block at its network assigned difficulty and a share is any solution that a miner finds above a pool-designated difficulty threshold to show that they're actually working on the problem. Ideally, the pool would assign every miner a share difficulty based on their hash rate such that everyone reports a statistically meaningful number of shares every round.

If miner A is doing 1,000,000 H/s and miner B is doing 1,000 H/s, miner A would be assigned a 1,000 times higher share difficulty than miner B. If both had the same share difficulty, miner A would be pounding the server with 1,000 times as many shares as miner B, all of which have to be verified by the server. Scaling share difficulty lightens the server load, and by doing a calculation on the number of shares and their difficulty you can still get a very accurate approximation of each miner's hash rate for calculating their reward.

>>I have a history of a big dog, we can start each of their work units out a little harder

does this mean you are going to throttle heavy miners somehow  ?

Yea, this morning it was doing fine.  I just checked on it and reset it and its up, but its getting pounded.
Its receiving over 250 hits per second.  It is actually inserting 250 rows per second of work in the work table.
One other thing that is surprising, is I see over the last two days, we increased our pool activity by 20% per day and user count by 20% per day.  I do have a new server at home for it, but Im on vacation.
In the mean time, Im going to check and see if I can gauge how the bigdogs ask for work, possibly if I have a history of a big dog, we can start each of their work units out a little harder.  Ill check that out now and that might decrease the hits per server to half.
Inblue, Ill have to look at all that you wrote a little later today.

I'm getting this trying to log in to the pool :

Service Unavailable
HTTP Error 503. The service is unavailable.

earlier today it was very slow.

Wow, great work on the interface!


OK, I still think this is an issue. My case can be reproduced with a browser password manager, which of course is not the norm, but let me explain why the issue also applies to the use without a password manager. Normally, when you go to edit your account on any website, the password field is not pre-populated with your password and its purpose is to enter your current password to be able to submit changes to your account. And that's not changing the password, it's just asking you for it to confirm other sensitive changes. And when you do want to change the password, then you are presented with a dialog to enter your current password, then another two fields for your new password, to type it twice to not make a mistake. And that's the norm. Here in the pool, the interface is presented in such a way that it doesn't look like you would be changing the password, only confirming it.

The problem with password managers which auto populate the fields is that I'm used to Chrome auto filling the password, even though I don't want to change the password, so I instinctively erase the password from the yellow field (https://i.imgur.com/C6LfM5c.png). That's what I did here, because I thought that there was nothing in that field previously, that Chrome added that. But it turned out the current password was already filled there, so Chrome only filled it again and made it yellow. So when I saved the form, my password changed to blank. It did the opposite of what I wanted - I didn't want to change the password at all, so that's why I erased that field. And of course, security-wise, it shouldn't be allowed for the password to be empty. If you want to have the ability to reset a user's password, that shouldn't be done like that, instead you should have that option in your admin page, and not allowing users to mess up or for somebody else to access their account when the password is blank.

I'm not sure if the part about hashing passwords is correct because you can go to the account page, right click on the password field where you see the circle asterisks and click inspect. Then in the code just change type="password" to type="text" and you'll see your password in plain text right there, filled in by the server. I tried that in a different browser, without a password manager, so I'm sure it's filled by the server, not my computer. Also, your example of changing usertext1 doesn't seem to make sense because how does that prove the passwords are stored as hashes? The password field is pre-filled, so whatever you change, if you don't touch the password field, of course you can log back in with the same password.

Now after typing all of this, I see that you just changed the account page not to populate fields anymore, no more username and email address either, but also no balance.

Speaking of a different browser, this is how the website looks in Firefox:
https://i.imgur.com/D2FSNQ9.png
https://i.imgur.com/8aj9Mho.png

Also, now the site can't be accessed most of the time or it's extremely slow:
https://i.imgur.com/V19OE9D.png

Another small thing I found:
Navigation links can't be clicked with middle click (to open in new tab), for example if I want to open block explorer in a new tab and I don't want to leave the pool page. Yes, it can be clicked with Ctrl+Left Click or Right click+Open in new tab, but I don't see why links need to be convoluted like that with some JS code instead of just plain and simple Main.aspx, Leaderboard.aspx etc.

Inblue, regarding the pool punchlist, progress has been made:




1. If you don't type your password when you edit the account,
the password for your account will change to blank,
so if you try to login again with your (old) password,
it will be denied and then it turns out you can login just with the username, leaving the password field blank!
-> Unable to reproduce (appears to not be broken).  B: When the password is deliberately set to blank,
 you may log in with a blank password temporarily - this is by design so I can reset a users password.
NOTE: The users passwords are stored as hashes, so the system does not actually store passwords on disk.
You can test this problem by just changing usertext1 only, and click save.  Then logoff and log back in with your standard password.

2.
 Block explorer navigation link exists only when you are logged out
-> Fixed, and moved the Orphans to the unprotected area also to expose these links to the world.


3. From the Withdraw page, the Home navigation link leads to the Account page
-> Fixed

All navigation links are visible only from the home page, on all other pages there is only the Home link,
which can be annoying to go through two links every time you want to take a look at something else
-> User can click Back on mouse, not worth fixing yet unless we upgrade entire menu to a database driven flyout menu system
-> Partially fixed though, since now you can click unprotected links from the masthead, maybe we will make those nicer and put more up there in the future.

Switch to Test Net link shows Switch to Main Net only after you click it, later it shows Switch to Test Net again and you can't go back to Main Net unless you refresh the page
-> Fixed

Existence of a horizontal scrollbar on all pages (empty gray content on the right)
-> Fixed

Block distribution history table changes row background color after your highlighted yellow row, instead of not changing it until the next block height
-> Fixed

Kind of a similar thing on the Leaderboard - it was probably intended for the same user to retain the same row color if their workers are next to each other, but that seems useless because:
-> Fixed

Users can have vastly different hash rates so their workers will not be next to each other
-> Leaderboard sorted by hashpersec desc... Cant do much here

It kind of exposes anonymous users when their workers are next to each other because you can conclude that's the same anonymous user, not multiple users
-> This really is hashpersec desc, so this is just a coincidence

Confusing order of navigation links - especially Log off which should be at the end, not somewhere in the middle;
or Leaderboard which is probably a very used link, but it's placement is like it's less important than the Switch to Test Net link.
-> Moved LogOff to last position; Moved leaderboard to unprotected area (allowing clickability sitewide and exposing it to the masses)

General look of the website which people may not find aesthetically pleasing
-> I havent looked into this yet; but could you please give a few of the most important improvement recommendations we could make, being relatively specific in this case?




EDIT: PS, Before UAT testing on the above, be sure to press ctrl-f5 after logging in to pull latest css files.

Wheels are rolling again, update:

Hello all, 1.0.2.3 for testnet is now available on the website (www.biblepay.org) inside the Prod download, and as usual, the testnet features are not enabled in prod, but are ready for testing in testnet.

Will you all please delete the testnet3 blocks and chainstate folder first?  This will make it easier, and more rapid to test what we want to test, as I made the cutover rule in testnet start at block 1.

In the new version, we now raise the bar even higher, by integrating our unique txindexlookup in the PoBh algorithm.  The txindexlookup supports 3 call types: blockhash, txid, and tx.vout.address.  This way, the miner must be a fullnode to actually query these outputs.  Each mining loop performs a security hash using PoBh, but also a txindex lookup.  Now we have 2 biblehashes for every x11 hash, minimizing the effects of x11.  X11 is used for our blockindex lookups for speed.

I will start my node now in testnet, and unban anyone I have banned.  If you cant get a connection to me, let me know as I may have to unban you again until you upgrade.

The only thing not addressed in this update is the networkkhps.  I cant determine it yet, we will need to do more testing on this new version to try to calculate it.

We can also verify that the late block threshhold has been alleviated, down below 30 mins.

Thanks!

Thats just on the web pool side, so we can resolve that without changes to the core.

Will the thread limit per worker be lifted in the next mandatory maybe?

Thanks happy, that analysis is very helpful.  I had added in the human readable block timestamp to showblock, and was going through them manually, but of course this is much more detailed and valuable.

Its pretty revealing.  The good news is we are not far off to achieving the proper diff level , subsidy level and spacing expected without x11.  But I see a few adjustments that need made.  

I agree, on the minimum spacing, we solved that, so it is of little concern and would just pollute the code to enforce any block minimum, as without x11 I believe in prod, there will be many fewer minimum spaced blocks now.


Regarding the late block threshhold however, the 4-5 you encountered that took one hour, I see the problem.  The good news is, I found the root cause, and its because the switch in testnet didnt actually enter the code that resolves late blocks > 30 mins elapsed!  So that is being fixed now, along with the minor diff tweak and gui tweak.  

The other thing that needed fixed is the subsidy calculation for higher diffs. Without x11, the subsidy drops quicker because the diff will rise with a different curve.
The new curve being implemented now for the next version will cure this:




I think what I would like to do now is make an attempt at raising the bar higher, and integrating our txindex lookup into testnet, then we test these few changes as one, and if all goes well we shoot for a mandatory with all this in at once.  I want to minimize mandatories so as not to upset our service providers.

Ill work on the txindex feature next and get back to you all.


EDIT: I forgot to add, on the x11 ratio you inspected, you are correct, it is now 1:1.  I was doing analysis on the viability to make it one x11 to a million biblehashes, but for technical reasons, it has to be just a flat 1:1.  Basically, every time the nonce on the block is incremented, the miner must know the x11 hash in order to hash the biblehash, therefore in the new system it really is 1:1.  That should be of no concern at all to our goal however, and should work fine for us and allow us to move forward. 

We can silence the debug info once the pool is ready to go to prod.  Right now its still valuable to me occasionally.  The format for those messages are: each thread is reported sequentially and semicolon delimited; RM means ready to mine; Guids are miner guids;etc.  I plan on leaving the informative ones in and removing the miner guid and pool addresses and things that are not human.

Yes, and in addition, we are known for our fruits, you can see we sponsor 74 orphans.
Your fruits however look sour (negatives next to your name).

Thanks for that, that helps a lot.
Above all, I dont see any hacking activity in the logs around this time, and nothing strange about cang2 at 2 am.  Although I do see something that needed fixed in the log based on this and now is fixed. But back to the issue of the high shares.  I have an audit table that keeps track of historical work by minerguid and it appears cang1 is the high power server (300khps) and cang2 was temporarily a low power server. Anh was probably expirimenting and pointed the high power server at the low power miner.  All I can fabricate is he received a ton of small work based on his proven level, but cang1 was actually solving all of it quickly and asking for harder work.  Then he probably put configs back to the original way to see what happens.  Then the hashes diminished in the round for cang2.
I will keep an eye on this particular situation.  The pool does make it incrementally harder for the miner once it gets a feel as to how fast it is.  I dont see anything else unusual other than the high rate in which solutions were solved (all the solutions are checked).

The next block was mined. The miner in question (cang2) wasn't even taken into account for calculating the reward (just cang1 and cang3). So the pool seems to have some sort of failsafe against this kind of erratic behavior.

So you're saying it does have something to do with it?

And this coin does Christian deeds like helping children in need, you should read up more about it.