BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

Started by Rob Andrews, October 03, 2017, 01:07:26 PM

Previous topic - Next topic

jaapgvk

My laptop had some problems, so my masternode went down. But I am syncing as we speak, so I should be online again soon.

Aside from that, I'm taking a step back from the crypto world, for a while at least. In my experience, there is so much power and greed involved in bitcoin at the moment, that I feel I can't really cope with the pressure of 'keeping up with the news'. Core vs Jihan etc. So I'm blocking all bitcoin-related sites for a while.

This forum will be the only crypto-related thing I will be keeping an eye on. I will keep the masternode enabled to support our testnet, and if I find the time I will write a guide for the pool (I'm sorry I didn't get to that Rob, and if anyone else want to give it a go, be my guest).

Rob Andrews

Quote from: togoshigekata on November 23, 2017, 08:04:36 PM
For the ecommerce config,

is it okay to have spaces in the config values?
Do I need to put double quotes around values with spaces?

For state should I use TX or Texas?
For phone do I need to add dashes or anything?

Thanks!
Hi Togo,
I tested spaces the other day and the spaces actually work, without quotes. 

For state, please use TX.  For Phone yes please use the dashes so you have a 12 character phone.

This will be interesting, let me know when you place the order and Ill see if any errors occurred.



Rob Andrews

Quote from: jaapgvk on November 26, 2017, 06:29:32 AM
My laptop had some problems, so my masternode went down. But I am syncing as we speak, so I should be online again soon.

Aside from that, I'm taking a step back from the crypto world, for a while at least. In my experience, there is so much power and greed involved in bitcoin at the moment, that I feel I can't really cope with the pressure of 'keeping up with the news'. Core vs Jihan etc. So I'm blocking all bitcoin-related sites for a while.

This forum will be the only crypto-related thing I will be keeping an eye on. I will keep the masternode enabled to support our testnet, and if I find the time I will write a guide for the pool (I'm sorry I didn't get to that Rob, and if anyone else want to give it a go, be my guest).

Thanks Jaap, I commend your decision!  Im going through the same thing right now- the other community is begging me to do something greedy, to switch to a base of a private version of Ethereum and I said no, I cant take it, I would leave, and besides Im here for BiblePay forever now.  The Greed is killing Americans, and they are choking Jesus out of their lives.  How much is enough?

Anyway yes, once we get this testnet bug-free hopefully you will be back by Christmas to launch a full node.

Have a good one in the mean time.
Rob

Rob Andrews

Quote from: tiras on November 25, 2017, 11:41:26 AM
masternode was shut down on it's own.

updated the wallet from git.
started the daemon . 
after re-syncing got the status "NEW_START_REQUIRED"

rebooted the VPS.
started the daemon . 
after a while the same :  "NEW_START_REQUIRED"

checking watchdog :

cd /root/.biblepaycore/watchman && ./venv/bin/python bin/watchman.py
Invalid Masternode Status, cannot continue.

what did I do wrong ?

thanks

I think klondike already answered but I wanted to add:
The masternode requires a status of "999" before it actually listens to our commands (I know, pain), so add this into the process:
After rebooting a masternode wait until 'mnsync status' shows 999, then issue the commands from the controller like start-many etc.

I did prove the other day that you do not have to restart a masternode (physically) when it says new start required.  You can do the start-many and it will respond, as long as its already synced.

Another words life in prod should be like this:

As days go by, and no upgrades are being pushed out:  If you ever see new start required, you go to your controller and issue the start-many command.

Reboots should only be necessary when upgrades (to the software) are required.


Rob Andrews

Quote from: Alex on November 23, 2017, 04:56:42 AM
So my Ryzen 7 is getting around 13 500 (genproclimit = 18) on f8000 but I need to do more tests with different genproclimits.

For the e-commerce test, that's very generous thank you! However, I was wondering if it would work for ppl living outside of the US or if it only works with US addresses for now?

Also, I'll have more free time starting tmr so tell me if there's anything else that needs to be tested!

Sweet, so Alex was getting 13,500 on a Ryzen, and on my old 3 year old desktop (AMD 6 core, 2.8ghz) I am getting 3500 hps.
This is pretty much inline looking at the processor specs (8 cores, 4.0 ghz, more threads per core, 4* the performance) yielding 4* the hash speed I am seeing on my older hardware. 
I did a test, where I ran biblepay twice on my desktop, and Im not seeing any addl throughput, and that is inline with Alexs observation of consuming the entire 100% of the processor.  So far so good.
Now we have to look at Togos speed.


Edit: I dont see any problems on windows vs linux.  Im running at 3000 HPS in windows on my current desktop.  Ill test Vultr linux instances in a minute.

Rob Andrews

Quote from: togoshigekata on November 23, 2017, 10:29:23 PM
I tested v1.0.6.2 in testnet on my Ryzen,
at 26 threads I got 12.3-13k HPS, it fluctuated alot in that range
Does this seem correct? >.>
Ah huh, great!  So you are inline with Alex's readings on his ryzen of about 13000.  Yeah, so far so good.  Let me test out vultr and Ill report back.
Its a $40 per month 4 core debian.

EDIT:  Ok, so Im getting about 900 HPS on the $10 a month vultr debian (which is really the same as the $5, it just has 8Gig ram instead of 4Gig), and getting 4000 HPS on the $40 per month 4-core-debian.  Which means the Ryzen is really a beast!  I dont see any problems so far, just a little interesting that my 3 year old desktop matches the $40 per month rented node.  However on the great side, there is no huge disparity between windows and linux now.  I have 3.5K HPS on my windows box, and 4K HPS on the $40 per month rented linux box.





togoshigekata

Tested ecommerce again!

Facepalm... I had one config key misspelled... hahaha

I have a new error now:

./biblepay-cli exec buyproduct 0718083296
error code: -1
error message:
BAD USERID


I believe these are the relevant lines in the code, I couldnt find USERID though:

https://github.com/biblepay/biblepay/blob/9f4868bd447b2346bd1ddd5f04207cec27127a9c/src/rpcblockchain.cpp#L2036

https://github.com/biblepay/biblepay/blob/9f4868bd447b2346bd1ddd5f04207cec27127a9c/src/rpcblockchain.cpp#L1292

klondike

guys: when you talking about HPS what you talk HPS1 or HPS2?

my ryzen 1700 linux= 205 000+ HPS 90%loading CPU


tiras

Quote from: klondike on November 26, 2017, 03:02:56 AM
tiras,   yes like togo wrote: i dit it same

VPS rebooted, started daemon then started watchdog and then in controller wallet did command :   masternode start-alias POKUS and worked

thanks.   I also updated controller node and started with "start-alias"  .  looks good now

tiras

Quote from: admin on November 26, 2017, 09:20:08 AM
I think klondike already answered but I wanted to add:
The masternode requires a status of "999" before it actually listens to our commands (I know, pain), so add this into the process:
After rebooting a masternode wait until 'mnsync status' shows 999, then issue the commands from the controller like start-many etc.

I did prove the other day that you do not have to restart a masternode (physically) when it says new start required.  You can do the start-many and it will respond, as long as its already synced.

Another words life in prod should be like this:

As days go by, and no upgrades are being pushed out:  If you ever see new start required, you go to your controller and issue the start-many command.

Reboots should only be necessary when upgrades (to the software) are required.

thanks Admin.  good to know for future

Rob Andrews

Quote from: klondike on November 26, 2017, 01:52:19 PM
guys: when you talking about HPS what you talk HPS1 or HPS2?

my ryzen 1700 linux= 205 000+ HPS 90%loading CPU


In prod, the HPS is faster, but allows the multi-instance exploit.  In Testnet, f8000 is enabled, and offers no gain when running dual instances.
Please do a getmininginfo in Testnet to see your HPS, and compare to Alex's 13,500 HPS.  Im getting 4K HPS on my windows dev machine.

(In f8000)

EDIT: Pool mining should be disabled in testnet for this test; just to ensure the thing isnt trying to reconnect to the pool every 60 secs.

Rob Andrews

Quote from: togoshigekata on November 26, 2017, 10:17:25 AM
Tested ecommerce again!

Facepalm... I had one config key misspelled... hahaha

I have a new error now:

./biblepay-cli exec buyproduct 0718083296
error code: -1
error message:
BAD USERID


I believe these are the relevant lines in the code, I couldnt find USERID though:

https://github.com/biblepay/biblepay/blob/9f4868bd447b2346bd1ddd5f04207cec27127a9c/src/rpcblockchain.cpp#L2036

https://github.com/biblepay/biblepay/blob/9f4868bd447b2346bd1ddd5f04207cec27127a9c/src/rpcblockchain.cpp#L1292


Very interesting, OK cool, Ill try it again and might have a few questions.  I havent bought anything yet from biblepay-cli, I bought mine through windows-qt, from the RPC.  I got my bible in the mail 2 days later, it seems pretty interesting so far.

Let me try to reproduce...



Rob Andrews

Quote from: Alex on November 26, 2017, 06:24:21 PM
Hey Rob, I was wondering if you saw that message.

I would need to check the logs again but I have been receiving masternode rewards for 1 day if not 2 while biblepayd crashed/wasn't running.

Oh OK cool, I havent had any nagging crashes, but I can investigate if you can provide the last page of the debug log before the crash.

On the payments, if you could please check to see if the masternode status is 'Enabled' on a node other than your masternode - and that your masternode is actually in sync.  If the masternode is in sync, it should be able to vote for itself for payments if its status is 'enabled' on everyone elses client.  Of course it has to have watchman running though.  If you want to give your IP I can tell you right now what the status is on this end?

Great on testnet BX, thats cool.

Yeah, I forgot to answer you on the Ecommerce post a while back when Thanksgiving hit.  Right now, the Mouse API only supports US deliveries.  But whats nice is we have the capaibility to deliver through Walmart and AMazon to the EU!  But first Id like to see how many orders we receive in the US to ensure its worth expanding to the EU (because its more work and more to support).  If we sell quite a few items per month Ill expand the API to include more countries each month.



Rob Andrews

Quote from: togoshigekata on November 26, 2017, 10:17:25 AM
Tested ecommerce again!

Facepalm... I had one config key misspelled... hahaha

I have a new error now:

./biblepay-cli exec buyproduct 0718083296
error code: -1
error message:
BAD USERID


I believe these are the relevant lines in the code, I couldnt find USERID though:

https://github.com/biblepay/biblepay/blob/9f4868bd447b2346bd1ddd5f04207cec27127a9c/src/rpcblockchain.cpp#L2036

https://github.com/biblepay/biblepay/blob/9f4868bd447b2346bd1ddd5f04207cec27127a9c/src/rpcblockchain.cpp#L1292


Hi Togo,

Ok, I tracked down the "BAD USERID" error and I see whats happening- in the abstraction layer where AWS stores the order, there was an issue with having blank Email address, so I fixed that issue and it is deployed again, and, I also tested this on biblepay-cli vs QT and it actually works in both CLI and biblpayd and biblepay-qt, so its OK if you want to test it again on the -cli version.

EDIT: I also added more verbose error messages so if any field in the config is not stored you will get an error for that field - in the next version.




Rob Andrews

Quote from: Alex on November 26, 2017, 06:52:43 PM
There wasn't really anything in the log except this:
2017-11-23 10:58:07 ProcessNewBlock : ACCEPTED
2017-11-23 10:59:35 ERROR: AcceptBlockHeader: block is marked invalid
2017-11-23 10:59:35 ERROR: invalid header received d202afcba304c82b59ead0c82bbb545c65d5206f4318fc072ae6aa1f9fa83234

Is there a way to get more things in the debug.log (logging levels)? If so, I will just run it with the most logging possible.

My masternode is enabled right now as I restarted biblepayd when it crashed and restarted it (208.68.37.149 ). What I am going to do now is kill biblepayd manually now and see if it still stays enabled and/or if I still keep receiving reward.

For the ecommerce post, I thought so too. Amazon is set to launch in Australia soon so maybe deliveries here will be possible too!

Yeah, you can set 'debugmaster=true' if you want, but its going to create Huge debug files.  Those messages are primarily for masternode debugging but I suppose there could be one that is revealing.  Im thinking I am possibly part of the problem here because I didnt upgrade 2 of my 3 nodes to the 1062 version (thats the one where we fixed the biblehash issue) so I might have sent you a bad header.  But still, thats supposed to d-dos ME and not make you crash.   (Edit:  I just upgraded my other 2 nodes).  Building windows now for the controllers.


If you want to run it with that switch, and "possibly" run valgrind again in testnet mode, if you get a crash, I believe valgrind might show the source stack trace of where it died and if you get that I can see what caused it to segfault right there?

Yeah, that would be cool if we could actually create some e-commerce volume through biblepay purchases.  Im interested in seeing 4-5 btc of trading volume due to this, then we could go and get on more exchanges and get a biblepay debit card started if that all came about.