Bible Pay

TestNet => TestNet Discussion Archive => Topic started by: Rob Andrews on September 01, 2017, 07:56:36 am

Title: [CLOSED] f7000 TestNet Testing Thread
Post by: Rob Andrews on September 01, 2017, 07:56:36 am
Welcome Bible Pay Users,

As you know we have had an exponential increase in interest and network hashing against Bible Pay since the launch, and now it is very hard to solo mine.  As a result, our Dev Team is writing a customized Bible Pay pool.

(The custom pool is necessary since we have a proprietary hash function that is resistant to ASIC and GPU mining.  In addition in the future the algorithm will be extended to raise the bar even higher, by requiring the full nodes to hash transaction lookups based on deterministic hash outputs, requiring the miners to be full nodes).

The purpose of this thread is to invite users to help test the pool from Test Net, to ensure it is ready for primetime.

We need to test things like: Hash Rate measurements, fair block payouts in the block distribution table, an accurate payment distribution at the time the block is solved, mining from many miners under one miner name to one pool, mining from multiple miners to one pool, the isolation of testnet from main net, the ability to withdraw BBP from the pool, the reliability of the pool, the reliability of the client miner, the fallback to solo mining if the pool is down, etc.  I will add more specific test cases and welcome any test cases.

Here is the location to download the latest wallet:

www.biblepay.org
Note, in order to pool mine, you will need at least v1.0.1.8 of the wallet (both daemon and qt should work fine).

How to set up the configuration for pool mining:

On windows, navigate to %appdata%\biblepaycore.  On linux, navigate to ~/.biblepaycore.

Edit the biblepay.conf file, and place the following lines in the config:

poolport=80
pool=http://pool.biblepay.org <- Note this URL is not live until approx Monday Aug 7th (Dev is deploying the pool tonight)
workerid=the_worker_id (explained below)
gen=1
genproclimit=10


After upgrading biblepay and modifying the config, biblepay wallet will automatically revert to solo mining if it cannot connect to the pool, even if the pool goes down for maintenance while you are on vacation.

Next, you will need to configure the Web site side of the pool.

In your web browser navigate to the Pool URL (see pool= above), and click Register, and create a web account.
After that, go the Main menu, then Account, and add a Miner.
(The Notes textbox may be filled in with something personal, like Rooftop linux i686 etc.)
Save the miner record.
Take the name of the miner (IE the worker ID), and edit your config file, setting it where we have "workerid=" in the above example and restart biblepay.

Next, check your mining stats as you normally would (IE check getmininginfo), you may do this by clicking Tools | Information | Console, and then type "getmininginfo".

The pool exposes a few lines of text for debugging purposes, the PoolInfoLine1 is just populated with the current Pool URL if your node is pool mining, and the Pool Miner Guid is populated in Line2.  Note this is just technical info and you do not need to know this.  This is useful if the pool goes down and you want to know if you are pool mining or not.  We have a field called "pool mining: true/false" that sums up what the miner is doing.  If any thread is successfully pool mining, the value is true, otherwise its false.

Please hold off on mining against the main chain In pool mining mode until we fully test the client.  Mining on the main chain in the pool could result in lost BBP, as the pool will sign the block and have no idea who to pay currently (until we verify the distribution system works).  NOTE: To disable the pool settings once you are done testing on that node for the day (IE if you want to mine on the main chain outside of the pool) just put an x in front of the pool= entry in your config file and restart in prod mode.  (IE xpool=pool.biblepay.org).

To start your client in testnet mode do the following:

cd c:\program files (x86)\biblepaycore
biblepay-qt -testnet
The background should be green if in testnet.  Please do all of the testing in testnet.
Note on the above biblepay.conf configuration settings:
You will need to copy the biblepay.conf settings from the biblepay.conf file down to the \testnet3\biblepay.conf file (IE just let the coin start, it will create the file, close the wallet, open the config, copy the setting rows, paste them into the target file, restart the coin).

(I realize this is convoluted, but Biblepay/Bitcoin have the settings coalesced like this for a certain reason so its easier for us to go through the double settings now rather than change the coalesce rules.)

Note that this version of the miner updates the hashmeter more slowly to squeeze out as much performance as possible, so be patient when re-running getmininginfo, as it is delayed approximately 30 seconds before a change occurs.

Alright, good luck everyone, lets make this a great pool.

As of Aug 6th at 20:00 CST US time, the pool has not yet been deployed.  I will edit this message as soon as the website is ready for you all to create accounts.
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 01, 2017, 11:09:36 am
Welcome to the new forum;  I see many active users starting to roll in from bitcointalk now.

I'm working on releasing the new Alpha pool now- it should be out in 2 hours.

This pool is "supposedly" an improved version of the pool that is in Beta; except, with some major improvements.

I would like to see this new alpha pool surpass our beta pool and become the standard pool for our users in prod.

It has future capabilities that are not unlocked: like the ability to attach documents and images to outgoing orphan letters, ability to read and write to the SAN, Voting, etc.

The alpha version uses a more advanced framework, that supports Ajax callbacks for a better user experience.

I plan on releasing the alpha pool to a new domain, and please we can test all the features here and find its shortcomings.
We can leave both pools live, so as to split the traffic for now.

Ultimately Id like to move the newest pool to "pool.biblepay.org" and move the current live pool to a backup (something like backup.pool.biblepay.org).


Rob

Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 01, 2017, 02:35:48 pm
I'd suggest after testing, move the current pool to pool2.biblepay.org and keep it live.  Increase the pool fee to 1.5% for all users to discourage use but still allow for it.

Yeah, thats what I was thinking also.

Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 01, 2017, 02:38:16 pm
Alright, the new pool is ready for testing.

Anyone who wants to point miners at it, can go ahead and hit it- it is completely separate from our live beta pool.

Here is the info:

URL:

http://pool2.biblepay.org


It shares the same database, so your existing credentials should already work, and miner records should be there.



Please test:  Account Edit, Withdrawing BBP, Mining against pool2.biblepay.org, Leaderboard, sorting, My Leaderboard,  Orphan List, Orphan Write To (Yes, please write some real letters, that would be nice), Read Letter, and anything else that is apparent.




Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 01, 2017, 02:55:14 pm
I forgot to mention: when testing the new pool, some weblist options are right click (intuitive software design).
So, for example to write a letter to an orphan you have to list the orphans, then right click the row and click Write.  Voting is implemented the same way. 

Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 01, 2017, 04:12:53 pm
I forgot to mention: when testing the new pool, some weblist options are right click (intuitive software design).
So, for example to write a letter to an orphan you have to list the orphans, then right click the row and click Write.  Voting is implemented the same way.
One more thing: Anyone who was Mining against pool2 up to 16:11 CST, the pool was not actually accepting solutions due to a bug.
Its resolved now, and I verified my last hash was accepted , so please, just restart your setgenerates and look now for leaderboard position against pool2.

Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 06:21:59 am
Westwarnsworth, I finally reproduced the crash you experienced in 1027.
I made a change, and deployed overnight.  V1028 is out there now.  Please try it.

In my case, it crashed when every thread received "Miner IP banned".  After upgrading, I got past that issue.

Also, on pool2.biblepay.org, I raised the thread limit to 200 threads, and, raised the IP ban threshhold to 10,000 hits (IE basically removing it).
If any bigdogs want to hit it now, hit it.

Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 06:59:46 am
It appears we are nearing the deadline to wrap things up for f7000.  I really don't want to make any 'breaking' changes, as the supermajority is running the latest version with the upcoming f7000 features now.

Since we Need to give c-cex a good 1000 block notice, to stop trading, we need to focus on wrapping this up within one day.

Westwarnsworth could you please double check 1028 does not crash, regardless of your tests, try disabling the network adapter, etc.  Ill work on the Genesis bug you reported.

Also, everyone else try to verify the new pool is working properly with the client, the 200 threadlimit is working with the large big-dogs, and that everything in general seems good for the next release.

We need to regroup here by the end of the day and pack up this version and notify c-cex, in order to make our deadline.

Title: Re: TestNet Testing Thread
Post by: Shoko on September 02, 2017, 07:14:24 am
I've been trying to log in on the new pool without success :(. I tried multiple browsers and I always get this error in the console "Failed to load resource: the server responded with a status of 500 (Internal Server Error) /pool.ashx". I'm not sure if anyone is having the same issue?

Also, pool2.biblepay.org has the same ipv6 address as pool.biblepay.org. I got my miners banned when trying to test the new pool as I didn't realise that I was still connecting to the old one :-[
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 07:34:13 am
Regarding the Genesis readbibleverse bug Westwarnsworth reported:
FIXED- in the next version if you type 'run readverse gen 1 1' that works now, the slow delay-lag is fixed when loading "Read Bible" from the help menu (after clicking a chapter), and also, now you can select Genesis, and also, when you pick Genesis 1:1 for example, it will come up quickly.

This will be in the next version.

Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 07:36:26 am
I've been trying to log in on the new pool without success :(. I tried multiple browsers and I always get this error in the console "Failed to load resource: the server responded with a status of 500 (Internal Server Error) /pool.ashx". I'm not sure if anyone is having the same issue?

Also, pool2.biblepay.org has the same ipv6 address as pool.biblepay.org. I got my miners banned when trying to test the new pool as I didn't realise that I was still connecting to the old one :-[

So, lets go in baby steps.  From the UI perspective when you log in to 'http://pool2.biblepay.org' are you able to access your account, and list the leaderboard successfully?

From the Client perspective, do you point to pool2, and, please ensure you have 1.0.2.7+ in order to avoid getting miners banned, then restart, and see if getminininginfo is clear?

Title: Re: TestNet Testing Thread
Post by: Shoko on September 02, 2017, 07:43:01 am
I actually managed to find the cause of my login issues. I have a long (25+ chars) and complex (lots of special characters) password and for some reasons it doesn't work on the new pool. I changed my password to something more simple and it started working. I tried to switch back to my original password and I was getting the error 500 again.

EDIT: I was going to post this reply just when you did.

The ipv6 addresses of pool2 and pool are actually the same (2400:cb00:2048:1::6819:fa6e). So somebody using ipv6 will have pool and pool2 point to the same address. Only the ipv4 addresses are different.

EDIT 2: Realised that the ipv4 also point to the same ip address for both pools, my bad. I thought they were different. Yes I do point my miners to pool2.biblepay.org. I had restarted the miners so they would load the new config and I'm running 1.0.2.8. I saw them showing up in the leaderboard on the old pool so I assumed it was still using that pool instead of the new one.
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 07:48:38 am
I actually managed to find the cause of my login issues. I have a long (25+ chars) and complex (lots of special characters) password and for some reasons it doesn't work on the new pool. I changed my password to something more simple and it started working. I tried to switch back to my original password and I was getting the error 500 again.

EDIT: I was going to post this reply just when you did.

The ipv6 addresses of pool2 and pool are actually the same (2400:cb00:2048:1::6819:fa6e). So somebody using ipv6 will have pool and pool2 point to the same address. Only the ipv4 addresses are different.

Oh my, all the code is based on ipv4.  Hows it working with ipv6?  Is it OK?

Title: Re: TestNet Testing Thread
Post by: Shoko on September 02, 2017, 07:54:34 am

EDIT 2: Realised that the ipv4 also point to the same ip address for both pools, my bad. I thought they were different. Yes I do point my miners to pool2.biblepay.org. I had restarted the miners so they would load the new config and I'm running 1.0.2.8. I saw them showing up in the leaderboard on the old pool so I assumed it was still using that pool instead of the new one.

Quoting my previous edit in case you missed it, I wasn't expecting you to answer that quickly haha.

I'm actually using both ipv4 and ipv6 but I guess it's defaulting to ipv6 when available. Everything has been working fine so far =D.

I'm not sure if something changed but I've just deployed a new miner and it doesn't seem to be able to connect the seed node for the initial download? I'm wondering if it's trying to connect using ipv6 and getting denied? I will just disable it I guess and see if it works :P
Title: Re: TestNet Testing Thread
Post by: Shoko on September 02, 2017, 08:25:44 am
I totally missed the part where you said you switched to cloudflare, I just realised that after looking more closely at the latency and the whois of the IP. I totally feel stupid now :P.

So I'm still having issues with deploying my new miner (0 connections) and thought it was an IPv6 issue first but it seems to actually be more of a Cloudflare issue.

I'm not sure how Cloudflare works exactly but I remember the wallet initially tries to connect to node.biblepay.org on port 40000 and I was wondering if this was still forwarded to the actual server. I tried doing telnet node.biblepay.org 40000 with no success. I tried to do the same with the actual IP of the server and it worked this time.

Concerning IPv6, I don't think there should be any issue since Cloudflare does a 6to4 tunnel so it should be totally transparent for the biblepay server.

It also might be a good idea to get a new IP for the biblepay server as it would be easy to just look at the first pages of the bitcointalk forum to find the actual IP address of the server and DDOS it, totally bypassing Cloudflare.


Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 02:15:49 pm
I totally missed the part where you said you switched to cloudflare, I just realised that after looking more closely at the latency and the whois of the IP. I totally feel stupid now :P.

So I'm still having issues with deploying my new miner (0 connections) and thought it was an IPv6 issue first but it seems to actually be more of a Cloudflare issue.

I'm not sure how Cloudflare works exactly but I remember the wallet initially tries to connect to node.biblepay.org on port 40000 and I was wondering if this was still forwarded to the actual server. I tried doing telnet node.biblepay.org 40000 with no success. I tried to do the same with the actual IP of the server and it worked this time.

Concerning IPv6, I don't think there should be any issue since Cloudflare does a 6to4 tunnel so it should be totally transparent for the biblepay server.

It also might be a good idea to get a new IP for the biblepay server as it would be easy to just look at the first pages of the bitcointalk forum to find the actual IP address of the server and DDOS it, totally bypassing Cloudflare.
Hmm, yeah, you have some good points here.  Before I go further with cloudflare, could you tell me if you got your miner working, and if not, did you try both pool.biblepay and pool2.biblepay with it?  I would assume both would be blocked.  Im confused on that because even though I have cloudflare enabled, to not reveal the servers IP, my web server can mine against the public pool2.biblepay.org DNS resolved address.

But, your right about that telnet test.  I normally tell people to try to telnet to 40000 on the node.biblepay.org, and it is definitely blocked.  However, I have 740 connections right now, so I can see the traffic is finding the node.

Ill go to the dashboard and see if I have any control over exposing telnet.

As far as hiding the public IP, I do have a new second ISP running a line in here next week, so Ill keep that second line private if possible.


Title: Re: TestNet Testing Thread
Post by: Shoko on September 02, 2017, 05:24:51 pm
I had to manually do "addnode" to be able to get my first connection and download the blockchain. I did wait a few hours before doing that but I'm not sure how IPs of node are advertised and if it would have been able to find a connection by itself after some time. (Could that also interfere with trying to hide the IP of the server behind Cloudflare?)

My new miner seems to be working on both pools. Did a tcpdump and it looks like the miner and the pool are using port 80 to talk to each other? If so, it would make sense that it is still working with Cloudflare since port 80 is forwarded to the actual server.

I did find this article:
https://support.cloudflare.com/hc/en-us/articles/200169156-Which-ports-will-Cloudflare-work-with-

It looks like Cloudfare wouldn't be able to be used with port 40000 :/

I'm wondering if the connections you see are from nodes that had established connection with the biblepay server before you enabled Cloudflare?

As a side note, I know it's not really a priority right now but did you see my post where I wouldn't be able to log in and was getting an error 500 on pool2 depending on what password I was using?


Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 02, 2017, 07:16:31 pm
I had to manually do "addnode" to be able to get my first connection and download the blockchain. I did wait a few hours before doing that but I'm not sure how IPs of node are advertised and if it would have been able to find a connection by itself after some time. (Could that also interfere with trying to hide the IP of the server behind Cloudflare?)

My new miner seems to be working on both pools. Did a tcpdump and it looks like the miner and the pool are using port 80 to talk to each other? If so, it would make sense that it is still working with Cloudflare since port 80 is forwarded to the actual server.

I did find this article:
https://support.cloudflare.com/hc/en-us/articles/200169156-Which-ports-will-Cloudflare-work-with-

It looks like Cloudfare wouldn't be able to be used with port 40000 :/

I'm wondering if the connections you see are from nodes that had established connection with the biblepay server before you enabled Cloudflare?

As a side note, I know it's not really a priority right now but did you see my post where I wouldn't be able to log in and was getting an error 500 on pool2 depending on what password I was using?
Thanks for the article on cloudflare, didnt know it could only handle certain ports.  Thats cool, yes its certainly possible the 725 or so nodes were present and whitelisted before cloudflare was enabled.  Just to be safe, I disconnected cloudflare on port 40000 only, and now, I can telnet to node.biblepay.org. 

As far as your 500 error, yes, got it, Ill have to fix that sometime.  As a test, could you try entering a Ticket in the pool and assign it to bible_pay for programming?  This is just to see if the tickets work.

Its good to here you are mining now.  I assumed the entire forum would light up with problems if cloudflare started blocking the mining traffic :).

Title: Re: TestNet Testing Thread
Post by: Shoko on September 02, 2017, 09:47:40 pm
I tried to create a ticket just now and it doesn't seem to be working unfortunately. I filled all the fields and this is the error I get when pressing the save button:

POST http://pool2.biblepay.org/pool.ashx 500 (Internal Server Error) jquery-1.12.4.js:10254

I'm also a little bit confused by how we're supposed to fill that form. What are we supposed to write in the "Ticket Number" field? I tried putting 1 in my attempts but is it supposed to be a number automatically generated instead?

Also, I was wondering if everyone could see all the tickets submitted or if they could only be seen by the account who submitted them. If it's the latter, would it be better to have the author of the ticket automatically be handled by the server instead of the "Submitted by" field? For example, in the case of someone pretending to be someone else and claiming they have issues accessing their account, etc.



Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 07:03:26 am
I tried to create a ticket just now and it doesn't seem to be working unfortunately. I filled all the fields and this is the error I get when pressing the save button:

POST http://pool2.biblepay.org/pool.ashx 500 (Internal Server Error) jquery-1.12.4.js:10254

I'm also a little bit confused by how we're supposed to fill that form. What are we supposed to write in the "Ticket Number" field? I tried putting 1 in my attempts but is it supposed to be a number automatically generated instead?

Also, I was wondering if everyone could see all the tickets submitted or if they could only be seen by the account who submitted them. If it's the latter, would it be better to have the author of the ticket automatically be handled by the server instead of the "Submitted by" field? For example, in the case of someone pretending to be someone else and claiming they have issues accessing their account, etc.

Hi Shoko-

The ticket system was written by my company and included in a prior product that I never released, so its just being shoehorned in to see if it is valuable for the web issues (in contrast to the qt-Client issues on github), so thats why its kind of malfunctioning as it has not even been configured for its intended use.

So looking at this, the ticket number field is supposed to auto increment when a new ticket is added.  FIXED.

The submitted by field is supposed to be populated with the submitters name: FIXED

The permission-view behavior by the other users on the system is supposed to respect the permission tree of the system based on the roles they play.  Since the roles are missing, everyone can see everyone elses tickets.  I am just going to leave it like that for a little while, so we can send each other tickets and escalate things to each other who want to become managers in the phase between now and the masternodes burn in period.  I could see assigning certain things to my team members who start in IT, and non-IT issues to non-it team members.

So if you want to go ahead and add it again, and then see if you can view the ticket list and click on it also.

Thanks.
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 07:22:30 am
Ran the 1.0.2.8 all day, no issues, I'll run it all night and hopefully the same there.

On the pool2 website, Orphan Fundraisers page doesn't display the date/time it was auctioned like it does currently on main.  Also, it would be interesting (feature request) to see the current balance of the Orphan Fund account "live" on that page in terms of BBP.  And furthermore, it would be handy to have a short, written report with each auction, or even just once a month or so, of how the previous funds were applied.

On pool2, the Sponsored Orphan List, shows 11 children as "Birthday Today", all show birthdays as August 19, so a date error on two counts I would believe.

Feature request, on Home screen, would be ideal to see pool balance (maybe broken up by mature and immature)

On burning in 1028: Great, because that kind of thing really hampers progress, lets hope we nailed it.
On Orphan Fundraisers List: I added the Updated column.
I agree, it would be nice to have a field to show the current orphan wallet balance.  The problem is, the listunspent command can only access the local wallets addresses, so I cant call out to get the balance from the pool.  The BX keeps track of it because it has elaborate code to map every address.  However, we can probably reverse engineer the value by running the rpc contribution report and subtracting the expenses spent.  The problem with that is, we currently only track the recurring expense amount and not the recurrent expenses payable items.  Im going to add payable items before the next orphan payments are due however, so we can track those, then we can add the field.  If you want to put a ticket in for the Orphan balance, go ahead and assign it to me.

Regarding Birthdays:  those birthdays were on the days that the orphan was initially sponsored (IE the Added date of the record) so those really were the birthdays, on that day, but obviously not Today. 

Regarding the Home page feature to show the users balance, I just added a home Announcement window, which I think we will need, and I added those two fields in there, and deployed.

Thanks for testing. 
Title: Re: TestNet Testing Thread
Post by: Shoko on September 03, 2017, 07:58:18 am
Hi Shoko-

The ticket system was written by my company and included in a prior product that I never released, so its just being shoehorned in to see if it is valuable for the web issues (in contrast to the qt-Client issues on github), so thats why its kind of malfunctioning as it has not even been configured for its intended use.

So looking at this, the ticket number field is supposed to auto increment when a new ticket is added.  FIXED.

The submitted by field is supposed to be populated with the submitters name: FIXED

The permission-view behavior by the other users on the system is supposed to respect the permission tree of the system based on the roles they play.  Since the roles are missing, everyone can see everyone elses tickets.  I am just going to leave it like that for a little while, so we can send each other tickets and escalate things to each other who want to become managers in the phase between now and the masternodes burn in period.  I could see assigning certain things to my team members who start in IT, and non-IT issues to non-it team members.

So if you want to go ahead and add it again, and then see if you can view the ticket list and click on it also.

Thanks.

Hi Rob,

I saw your ticket and can only see the ticket 902 and can click on it to see the details.

Apologies for not replying using the ticket system but it seems I am still having troubles with submitting/updating a ticket. I'm still getting the same error 500 when pressing the save button. This happens whether I'm trying to create a new ticket or update yours.
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 08:15:05 am
Hi Rob,

I saw your ticket and can only see the ticket 902 and can click on it to see the details.

Apologies for not replying using the ticket system but it seems I am still having troubles with submitting/updating a ticket. I'm still getting the same error 500 when pressing the save button. This happens whether I'm trying to create a new ticket or update yours.

Alright maybe the update didnt push, I updated, please try now.  You can first try editing the ticket and saving, then editing and reassigning, this way you can tell me where exactly it breaks with a 500?

Thanks.
Title: Re: TestNet Testing Thread
Post by: Shoko on September 03, 2017, 08:26:56 am
I did try first to just edit it first without modifying anything else. I also tried different combinations of just modifying the the "body", "submitted by" and/or "assigned to" . I also tried to just open it without modifying anything and just clicking on save but it was throwing the error 500 in every case :(

I was about to try again but I'm now having  a different issue. The pool (old and new) doesn't seem to be recognising my password anymore?
Title: Re: TestNet Testing Thread
Post by: Shoko on September 03, 2017, 09:18:06 am
So I tried different things:

-I tried creating a new account on pool.biblepay.org. I can log in on pool.biblepay.org but not on pool2.biblepay.org (getting the invalid username/password error).
-I tried creating a new account on pool2.biblepay.org. This time I can log in on both pool.biblepay.org and pool2.biblepay.org.

Unfortunately I still can't log in on either pool with my original account :(
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 09:25:26 am
So I tried different things:

-I tried creating a new account on pool.biblepay.org. I can log in on pool.biblepay.org but not on pool2.biblepay.org (getting the invalid username/password error).
-I tried creating a new account on pool2.biblepay.org. This time I can log in on both pool.biblepay.org and pool2.biblepay.org.

Unfortunately I still can't log in on either pool with my original account :(

I set your password to null, so now you can log in with an empty password.
Note: the password must be completely empty, not a space.

Then you can change it.

Earlier this morning, I edited the ticket as you and saved it, so it might possibly be your browser.  After you get back and try again let me know the browser details if you still receive the 500 on save.
Ensure you have no plugins etc.
Title: Re: TestNet Testing Thread
Post by: Shoko on September 03, 2017, 09:39:04 am
Thanks!

Usually I'm testing things using Chrome in incognito mode so that I have nothing from previous sessions (cache, cookies, etc.) and also no plugins enabled. I do the same thing in Safari and Firefox if I see that it is not working in Chrome just to be on the safe side.

I managed to successfully edit your ticket and reassign it back to you. I also managed to create two tickets:
-One with the body field empty.
-One with test2 in the body field.

The reasons I did is that is that I first tried to submit a ticket with this content in the body field:
"
I have a long (25+ chars) and complex (lots of special characters) password and for some reasons I couldn't log in on the new pool. This is the error I was seeing in the console (Failed to load resource: the server responded with a status of 500 (Internal Server Error) /pool.ashx)

I changed my password to something more simple and I could log in on the new pool. I tried to switch back to my original password and I was getting the error 500 again.

This is the password (not used anymore) that wouldn't work with the new pool. Hopefully it will help with debugging:
[4i.r2Zugkb4WxbTTLy&[email protected]
"

For some reasons, I get the error 500 when trying to send that.

Also I was thinking, would it be possible that Cloudflare keeps in cache some of the files you're updating? As we're probably not using the same CDN servers, maybe if don't flush it manually we're getting different versions of theses files when rapidly updating them?
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 09:53:46 am
Thanks!

Usually I'm testing things using Chrome in incognito mode so that I have nothing from previous sessions (cache, cookies, etc.) and also no plugins enabled. I do the same thing in Safari and Firefox if I see that it is not working in Chrome just to be on the safe side.

I managed to successfully edit your ticket and reassign it back to you. I also managed to create two tickets:
-One with the body field empty.
-One with test2 in the body field.

The reasons I did is that is that I first tried to submit a ticket with this content in the body field:
"
I have a long (25+ chars) and complex (lots of special characters) password and for some reasons I couldn't log in on the new pool. This is the error I was seeing in the console (Failed to load resource: the server responded with a status of 500 (Internal Server Error) /pool.ashx)

I changed my password to something more simple and I could log in on the new pool. I tried to switch back to my original password and I was getting the error 500 again.

This is the password (not used anymore) that wouldn't work with the new pool. Hopefully it will help with debugging:
[4i.r2Zugkb4WxbTTLy&[email protected]
"

For some reasons, I get the error 500 when trying to send that.

Also I was thinking, would it be possible that Cloudflare keeps in cache some of the files you're updating? As we're probably not using the same CDN servers, maybe if don't flush it manually we're getting different versions of theses files when rapidly updating them?


Yeah, it was probably the complex password.  Ill put a ticket in and either farm that out to one of our devs or get to it eventually.

I dont think cloudflare is caching these particular requests, because if they were, every callback should fail.

Thanks for testing we will regroup on this soon.
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 09:56:19 am
UPDATE ON F7000:

Alright, I have not heard any more complaints, so the window is closing.
I am compiling 1.0.2.9 now and will release as a mandatory upgrade tomorrow morning.

I notified CCEX that we have a mandatory at 7000.  They will be closing our wallet for maintenance soon.

The linux users can upgrade to 1029 now if you want to do any final testing.

I suppose we can "try" to release the beta pool as the Prod pool around the time of the mandatory, so that we have a Pool in production.

Title: Re: TestNet Testing Thread
Post by: Shoko on September 03, 2017, 10:01:18 am
Sorry I forgot to add I actually tried to send it without the password part! Could it be the length maybe?

For the Cloudflare cache, I know that it can cache a lot of things including js files so I'm not sure if that was modified? I'm only saying that because I'm pretty sure I tried with multiple browsers and with my previous sessions cleared, but maybe I actually didn't!

Thanks for all the work! Happy to help if you need anything else!
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 03, 2017, 10:16:34 am
Sorry I forgot to add I actually tried to send it without the password part! Could it be the length maybe?

For the Cloudflare cache, I know that it can cache a lot of things including js files so I'm not sure if that was modified? I'm only saying that because I'm pretty sure I tried with multiple browsers and with my previous sessions cleared, but maybe I actually didn't!

Thanks for all the work! Happy to help if you need anything else!

Yes, the long length could possibly be causing an internal error in the cryptography class. Its hard to say if your pass got saved that way, or if its thrown at login.  We can look at that sometime in the future,

Today, only DLLs were changed, so no cache issues.
Title: Re: TestNet Testing Thread
Post by: jaapgvk on September 06, 2017, 10:00:08 am
I saw the comment about the outgoing orphan letters on the bitcointalk-forum, so I would like to give some (hopefully helpful) feedback:

I know you could write letters in de old pool, but I can't find that option in the new one (nor can I figure out how to upvote letters), but maybe I'm just not seeing it. Another thing is that the 'BIRTHDAY TODAY' notes aren't really helpful, since they were only valid on the day they were added, so it might cause some confusion.
Title: Re: TestNet Testing Thread
Post by: togoshigekata on September 06, 2017, 10:46:44 am
I saw the comment about the outgoing orphan letters on the bitcointalk-forum, so I would like to give some (hopefully helpful) feedback:

I know you could write letters in de old pool, but I can't find that option in the new one (nor can I figure out how to upvote letters), but maybe I'm just not seeing it. Another thing is that the 'BIRTHDAY TODAY' notes aren't really helpful, since they were only valid on the day they were added, so it might cause some confusion.

1. Go to Pool website: http://pool.biblepay.org/
2. Go to "Orphans" tab >>> "Sponsored Orphan List"
3. Right click row of Orphan
4. Write Letter, click Save!
5. Letter Writing Tips: http://pool.biblepay.org/LetterWritingTips.htm
Title: Re: TestNet Testing Thread
Post by: jaapgvk on September 06, 2017, 11:59:46 am
1. Go to Pool website: http://pool.biblepay.org/
2. Go to "Orphans" tab >>> "Sponsored Orphan List"
3. Right click row of Orphan
4. Write Letter, click Save!
5. Letter Writing Tips: http://pool.biblepay.org/LetterWritingTips.htm

Thank you! I'm on a laptop with a touchpad, so it wasn't really intu´tive :)

Next thing: the vast majority of orphans have a 'correspondence language' that is non-English. I don't speak Spanish, Portugese etc. Is it even worthwhile to send these orphans letters in English?
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 07, 2017, 09:51:06 am
Thank you! I'm on a laptop with a touchpad, so it wasn't really intu´tive :)

Next thing: the vast majority of orphans have a 'correspondence language' that is non-English. I don't speak Spanish, Portugese etc. Is it even worthwhile to send these orphans letters in English?
The right click menus in the pool Are intuitive, they are not instinctual.  The contrast being that once people know right click options exist, and there is only one way to perform certain weblist tasks, at that point becomes valuable and intuitive (as more options are added to weblists).  In contrast to the way Microsoft veered away in its latest office software design requiring you to Switch Screens to perform a list of certain functions (non-intuitive, possibly idiotic), while caving to the left wing consulting groups for the sake of internationalization.

Anyway, the pool only supports English right now.  I realize the 'proper' way to do it is to support multiple native languages, by creating a captioning system that supports language overloads.  That can be a project for my slack team.  In the mean time let me make a distinction here:  English as the only user interface language is referred to : UI Interface Language->English, and communicating with orphans is referred to as:  Operations->Communication.    I just want to make a distinction between our software UI and our day to day ops.

When you use the User Interface in English, the translators at compassion will automatically translate the letter from English to the native orphan language, and regenerate the final hardcopy and mail it to the orphan :)!  So thats a big bonus for us.  What I have to find out is:  Are we required to write in English, as  our bible_pay org account is signed up in English.  I believe that is the case currently.
Title: Re: TestNet Testing Thread
Post by: jaapgvk on September 07, 2017, 01:38:29 pm
The right click menus in the pool Are intuitive, they are not instinctual.  The contrast being that once people know right click options exist, and there is only one way to perform certain weblist tasks, at that point becomes valuable and intuitive (as more options are added to weblists).  In contrast to the way Microsoft veered away in its latest office software design requiring you to Switch Screens to perform a list of certain functions (non-intuitive, possibly idiotic), while caving to the left wing consulting groups for the sake of internationalization.

Anyway, the pool only supports English right now.  I realize the 'proper' way to do it is to support multiple native languages, by creating a captioning system that supports language overloads.  That can be a project for my slack team.  In the mean time let me make a distinction here:  English as the only user interface language is referred to : UI Interface Language->English, and communicating with orphans is referred to as:  Operations->Communication.    I just want to make a distinction between our software UI and our day to day ops.

When you use the User Interface in English, the translators at compassion will automatically translate the letter from English to the native orphan language, and regenerate the final hardcopy and mail it to the orphan :)!  So thats a big bonus for us.  What I have to find out is:  Are we required to write in English, as  our bible_pay org account is signed up in English.  I believe that is the case currently.

You're absolutely right. I saw that more right-click features have been added, and I already noticed some screens popping up as a sort of overlay (I'm not really familiar with the technical terms). It's just that I was expecting a 'normal website', so I didn't think about right-clicking. But it has already become second nature now, and I must say that I'm impressed :)

It's great to hear that there are translators working at compassion.com. That takes away my worry about that point.
 
There are a few other observations that I'd like to make:
1. Is it an idea so somehow integrate all the sent/received letters per orphan in one place, so that you can see right away what the last letter is? Because now I have to first look if there's a letter from a particular orphan, then I have to scroll down the 'outgoing letters' tab to see if someone else didn't write first, and then I have to go to the 'sponsored orphan list' to actually write a letter. I know it's not really compatible with the 'upvote list', but it's just a thought.

2. Related to point 1: The letters are a bit personal in nature (questions asked/answers received), and I was wondering how we as a group can streamline this. I guess a one-on-one writing relationship between orphan and biblepay user is not really practical, especially with the upvoting system. Also, the name I see accompanying a lot of letters is 'Robert', but of course I have a different name. So isn't it confusing for the orphans to receive letters from a lot of different users? Or is it a common thing to sponsor orphans as a group?
Title: Re: TestNet Testing Thread
Post by: Rob Andrews on September 13, 2017, 07:22:38 am
You're absolutely right. I saw that more right-click features have been added, and I already noticed some screens popping up as a sort of overlay (I'm not really familiar with the technical terms). It's just that I was expecting a 'normal website', so I didn't think about right-clicking. But it has already become second nature now, and I must say that I'm impressed :)

It's great to hear that there are translators working at compassion.com. That takes away my worry about that point.
 
There are a few other observations that I'd like to make:
1. Is it an idea so somehow integrate all the sent/received letters per orphan in one place, so that you can see right away what the last letter is? Because now I have to first look if there's a letter from a particular orphan, then I have to scroll down the 'outgoing letters' tab to see if someone else didn't write first, and then I have to go to the 'sponsored orphan list' to actually write a letter. I know it's not really compatible with the 'upvote list', but it's just a thought.

2. Related to point 1: The letters are a bit personal in nature (questions asked/answers received), and I was wondering how we as a group can streamline this. I guess a one-on-one writing relationship between orphan and biblepay user is not really practical, especially with the upvoting system. Also, the name I see accompanying a lot of letters is 'Robert', but of course I have a different name. So isn't it confusing for the orphans to receive letters from a lot of different users? Or is it a common thing to sponsor orphans as a group?


Wow, you have some great ideas here.  Well as you know I believe you wrote #1 before we had the NeedsWritten column decimal (1 or 0), however its still valid in the sense that it would be nice to see outgoing leters to a distinct orphan grouped together, the list order by added descending, and maybe the top page has the most recent activity.  I dont mind doing it but this brings up one sorely needed feature for the web list that is missing: pagination.  Maybe I need to step back, and add pagination to the web list first.  If you want you can put a ticket in for me to group outgoing letters by orphan and added descending - assign to bible_pay for programming.

On #2, I agree very much that these  letters are personal and up til now didnt think we had anything we could do to combat that (I thought you know we are doing the greater good here, so we have to live with it).  But you bring up a great point, we could probably just as well allow one on one private letters, but that brings up the original problem.  The reason they are public is so the community can do the work of upvoting in order to 'approve' the letters so I dont become a letter policeman for my day job - so I can be free to keep programming.  So the condundrum is, if we allow private letters how do we know the letter doesnt contain expletives and things about my house is so big I wish I could share it but too bad?
Title: Re: TestNet Testing Thread
Post by: maarek on September 13, 2017, 04:44:42 pm

Wow, you have some great ideas here.  Well as you know I believe you wrote #1 before we had the NeedsWritten column decimal (1 or 0), however its still valid in the sense that it would be nice to see outgoing leters to a distinct orphan grouped together, the list order by added descending, and maybe the top page has the most recent activity.  I dont mind doing it but this brings up one sorely needed feature for the web list that is missing: pagination.  Maybe I need to step back, and add pagination to the web list first.  If you want you can put a ticket in for me to group outgoing letters by orphan and added descending - assign to bible_pay for programming.

On #2, I agree very much that these  letters are personal and up til now didnt think we had anything we could do to combat that (I thought you know we are doing the greater good here, so we have to live with it).  But you bring up a great point, we could probably just as well allow one on one private letters, but that brings up the original problem.  The reason they are public is so the community can do the work of upvoting in order to 'approve' the letters so I dont become a letter policeman for my day job - so I can be free to keep programming.  So the condundrum is, if we allow private letters how do we know the letter doesnt contain expletives and things about my house is so big I wish I could share it but too bad?

Since letters are likely going to occur in batches, could letter reviews become a Sanctuary oversight function? Perhaps tie vote power to accurate review of letters (which could be done by distributing each letter to 2 or more sanctuaries and using a 2of2 of 2of3, 3of4, 4of5...etc approval process)? That way it decentralizes the review process but at the same time limits the public exposure to those nodes that are part of the governing org of the crypto.
Title: Re: TestNet Testing Thread
Post by: jaapgvk on September 15, 2017, 03:51:59 am

Wow, you have some great ideas here.  Well as you know I believe you wrote #1 before we had the NeedsWritten column decimal (1 or 0), however its still valid in the sense that it would be nice to see outgoing leters to a distinct orphan grouped together, the list order by added descending, and maybe the top page has the most recent activity.  I dont mind doing it but this brings up one sorely needed feature for the web list that is missing: pagination.  Maybe I need to step back, and add pagination to the web list first.  If you want you can put a ticket in for me to group outgoing letters by orphan and added descending - assign to bible_pay for programming.

On #2, I agree very much that these  letters are personal and up til now didnt think we had anything we could do to combat that (I thought you know we are doing the greater good here, so we have to live with it).  But you bring up a great point, we could probably just as well allow one on one private letters, but that brings up the original problem.  The reason they are public is so the community can do the work of upvoting in order to 'approve' the letters so I dont become a letter policeman for my day job - so I can be free to keep programming.  So the condundrum is, if we allow private letters how do we know the letter doesnt contain expletives and things about my house is so big I wish I could share it but too bad?

Happy to help and to provide feedback on the project :) i tried to send you a ticket, but at first it didn't seem to work, so I also send you a couple of 'test messages'. Is there a max on the amount of letters you can use on a ticket? Because at first I typed a few sentences and it wouldn't send, but when I shortened it, it would.

I would really like to have a better overview on which orphan was send what, and what their replies were, because now I feel a bit lost when I try to send a letter, because I don't have an overview of the current state of things. Well right now it isn't that bad, but as more and more letters and send and replies are gotten, the more it will become messy in my view.

About #2: I didn't mean that they were explicitly private in the sense that they weren't approvable by others.  But If I was an orphan, I would become confused as to who is actually writing to me. Is it an idea that we start our relationship with orphans by stating that we are a group of people who joined hands to help them? Because if I was an orphan that was adopted, and I started receiving letters from 'bob12' one day and 'hobo_strike' the other (who didn't even reply to my question to bob12), I'd be a little confused and probably hesitant to write another letter.

But I think that this problem would solve itself if we can somehow make more explicit who's writing who in a nice overview. That way you can see who send which letter to whom, and upvote a new letter accordingly.

So for example, Heather wrote a letter to an orphan, the orphan replied, and you can see this in the overview. Now, Heather wrote another letter to the same orphan. I, as a voter, would then upvote Heaters letters, because it fits. If 'hobo_strike' comes along 'mid conversation' and tries to send a completely irrelevant letter, I could downvote it.
If Heather stops with the project, people can see that there hasn't been send a letter to 'her orphan' for some time, because it's near the bottom of the list (sorted by date). I would then be incentivised to start a new conversation with that particular orphan, stating that Heather seems to be gone, but that we are a group, and continue the 'back an forth' where Heather left off. Hobo_stike could to the same here, and his letter would now get upvotes because people can see that it's been a long time since Heater replied, and hobo_strike also replies to questions the orphan asked.

Just an example of course, and if we introduce ourselves as a group from the beginning, it wouldn't be confusing to the orphan I guess?