Messages

3976

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 18, 2017, 08:18:08 PM »

http://wiki.biblepay.org/Retirement_Accounts

exec retirementbalance
exec tradehistory
exec orderbook
exec listorders
exec order [  Buy/Sell/Cancel ]   Qty  Symbol [Price]

Im free to test too

I just got back in and should be around for an hour or two.

Anyone up for a trade?

Dont forget, when you do the exec orderbook, you can widen your rpc display to see it better.

I just did: exec order sell 50000 rbbp .0293

If someone wants to add the opposing Buy order?

Please do an exec retirementbalance before trading so you can see the prior balance.

After 5 confirms on our trade, then you can do an exec tradehistory, and exec retirementbalance and reconcile them..

3977

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 18, 2017, 04:18:43 PM »

Yup it's only every few hours. Thanks!

Thanks for checking, yeah Ill fix that area, please follow up with me in a week and we can ensure its right (regarding the keypool test and message), I need to get past this hump with the ecommerce release and need to ask more people to help test these retirement accounts starting tomorrow.

3978

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 18, 2017, 12:50:06 PM »

Hey Rob, I was looking through my logs and I'm seeing a new error now from time to time.

I was wondering if you had any idea where it could be coming from?

 ** TestBlockValidity FAILED - pindexNew->pprev != chainActive.Tip() (assert(pindexNew->pprev == chainActive.Tip())); **
2017-11-18 01:32:04 TestBlockValidity failed while creating new block
2017-11-18 01:32:04 BiblepayMiner -- Keypool ran out, please call keypoolrefill before restarting the mining thread

(my wallet has 40000 keys  pre-generated so it's def not running out of that)

That means the best block changed while you were generating a new block for mining.  The keypool error is misleading, should be taken out.

Please verify this only happens once every few hours then that will confirm it.

3979

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 18, 2017, 08:04:28 AM »

I guess we can try another retirement trade.  Togo?  If not, anyone else?

You must be on 1061 to test retirement trading.  Windows is out there also.

3980

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 18, 2017, 07:52:34 AM »

BiblePay - 1.0.6.1 Available
Mandatory Release for TestNet


- Fix checkblock(1) errors diagnosed with Alex that occasionally results in an invalid BibleHash
- Upgrade wallet graphics with new logo pack
- Show OpenSSL version in Tools | Info

www.biblepay.org | Downloads
https://github.com/biblepay/biblepay/

3981

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 07:02:48 PM »

Just checked all my logs and Yup, no errors!

I've also successfully set up a masternode on testnet.

Best thing I heard all week!  Great!  Thanks for the help!

Yeah, Im testing the new version and compiling one for windows now, and Im going to send it out as a highly recommended (just short of mandatory upgrade) to Prod & Testnet in a few hours.

(Cant go with Mandatory as it may upset CCEX).

3982

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 01:34:34 PM »

Ok on Linux machine I just realized I never removed the banlist.dat file from the ~/.biblepaycore/testnet3 folder, woops,
I only had 2 connections before, now I have 12! Not sure how much this affected the retirement coin testing 

I assume in the future we will want banlist.dat file?
Is there a linux command to delete the contents inside the file?
I just used rm (remove) command, but I assume that means I cant ban anyone going forward now.

===

Rebuilding/Resyncing Chain:

GUI:  Tools >> Wallet Repair >> Rebuild index
Linux:  ./biblepayd -daemon -reindex

===

Windows GUI Wallet is now v1.0.5.9
Linux Wallet is now v1.0.6.1

Thanks, well that would have worked its way out after 24 hours as the max ban flag is one day, but yeah, I think Alexs discovery had a lot to do with our shrinking and decomposing network, with increasing banned nodes.

Since a few hours have passed I think the general consensus is that Alex hasnt found any new issues so I will probably ask you all to update to the latest version so we can do a pulse test of stability over the next 10 days.  Id like to see no banned nodes, no lost syncs, and a good masternode list.  But hold off for a couple hours as I am working on a feature we may be able to test together.

Regarding the retirement testing, I did find a bug in there, very minor, and its "technically" corrected in the last version but not tested.  Let me go ahead and test that first before we try more retirement tests.

The other thing is I am hoping to release e-commerce alpha soon.  Then we can test that also.

3983

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 10:01:57 AM »

Oh this is mainnet not testnet sorry

Oh I see, OK we have a solid reason for this.  So in mainnet, tithe blocks are active til Christmas but in TestNet they are not.
Since the block the miner works on is n+1, if it will be an *upcoming* tithe block, the hash changes to be Higher, to allow the Diff to be Lower, so is normal for the blocks in Prod that will end in n+1 % 10 to be different, you can see if you increment the height up through n+9 no changes until you hit another tithe block.
Yeah, I confirm that hash is 011 in prod, and 2aaa for the tithe block .

So far, so good! I guess I can let you burn in for a while longer.


This is excellent, this will most likely fix the reason we went out of sync twice in testnet.

EDIT:  THANKS ALEX FOR YOUR PERSEVERANCE AND FINDING THIS FLAW!!!!!

3984

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 09:56:30 AM »

Oh this is mainnet not testnet sorry

Let me restart in mainnet and try that....

3985

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 09:52:38 AM »

Well well, I've been spamming the forensics command and I can happily say that it is now giving me the same hash no matter what!

However, with the same parameters but the block height, am I still getting the wrong hash for block 17078 and 17079 for example?

biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17078
{
  "Command": "biblehash",
  "BibleHash": "0000000000011c6f2cd7107900e4308d6db47227d9f1753e65b9d6fe206f3072"

biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17079
{
  "Command": "biblehash",
  "BibleHash": "0000000000002aaa46b9dc122688a0e203a7ddec60b104c95c0f1372eb43e0dd"

Did you say 0011 was invalid?

Im not able to reproduce that on 1061, I am running 1061 in testnet and moving from 78 to 79 still yields the 011 (not seeing the 2aaa).
What network are you in and is this definitely 1061?   Yeah, no changes should occur until you hit something like block 27000 etc.

Great on the improvement so far!  I bet we fixed it!  I bet this anomaly you found has a reason, such as cli being connected to 1060

3986

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 09:38:57 AM »

Hey Rob, I finished updating one node and it is now mining on mainnet. How should I test that new version? Wait until I get an error in the log or should I spam the forensics command and see if I get different hashes again?

You can do both, go ahead and try to break it.

Yeah, we wont know its broken til it spurts out an error though....

3987

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 09:29:57 AM »

im still PRE-ENABLED  ... shit


by me,this masternodes is PONZI SCHEME like BBP : and i screw on all masternodes..... still not exists guide why watchman doesant running stable,im do all by guide and ROB=ADMIN still wrote with puzzles

ASKING YOU : how long being when you start WATCHMAN and your STATUS in controller wallet changes from preenabled to enabled? immediately?


i hope that masternodes wont be exists on BBP,cos this setuping is massacer

Dude its obvious you have a bad attitude and I dont want it here, why dont you try dash out for a while and see how easy it is to set one up and then come back later and tell us how it went?

3988

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 09:19:30 AM »

Rob

1.how long being when status WATCHDOG changed to ENABLED from WATCH_DOG EXPIRED when watchman run?
2.where i can see that watcham is running?

3.RE-ENABLED : watchman doesnt running,right?

1) If you delete your Watchman.db database and re-sync masternode data, and clear all your sanctuary .dat files (like mncache), then 15 minues, otherwise 8 hours.
2) You run watchman from the command line and see if it returns empty string.
3) Depends, if you just synced, you have to do queries in the watchman database to find the answer.

3989

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 09:17:38 AM »

All the "mn" nodes are Ryzen 7 with 64gb of DDR4 and 2xSSDs in Raid0. So decent machines I think!

Thats very interesting.  Im honestly thinking, the Ryzen processor may be so fast that one mining thread is loading the AES512 encryption key partially in the core while the other receives a hash based on a faulty encryption key.  I did find a circumstance where I believe that is possible, so all this effort is definitely worth it, as this will "potentially" give us a stable biblehash, if this is the problem.

Ok, I tested the new version to ensure it yields the same hashes and mines in prod and testnet so I am checking it in.
Please grab 1061.

In this version, we use a different call to openssl's md5 (IE directly from the biblehash lib), we change our call to AES512 to be more efficient, and we set up a few miningparams once before we mine to not require those calls for every hash (so thats a slight improvement there too).  The biggest change, the one that might make or break this as the fix, is this:  I found the bibleminer was re-loading the encryption key for every hash, and that could be the problem.  I fixed this! So lets go ahead and try it again and see if it fixes.

3990

TestNet Discussion Archive / Re: BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: November 17, 2017, 08:57:57 AM »

Oh also and I may have misunderstood you. Since everything is the same but the prev block number, shouldn't these hashes be the same?

root@mn2 ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17079
{
  "Command": "biblehash",
  "BibleHash": "0000000000002aaa46b9dc122688a0e203a7ddec60b104c95c0f1372eb43e0dd"
}
root@mn2 ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17078
{
  "Command": "biblehash",
  "BibleHash": "0000000000011c6f2cd7107900e4308d6db47227d9f1753e65b9d6fe206f3072"

root@mn2 ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17069
{
  "Command": "biblehash",
  "BibleHash": "0000000000002aaa46b9dc122688a0e203a7ddec60b104c95c0f1372eb43e0dd"

Yes, they should be the same - all 3 of them should be the same since only the last parameter is changing, the correct hash is 2aaa in prod - Im running it now in the rpc.  The 11c6 hash is a bad hash.   That looks like the problem.  Its interesting you can generate those hashes so easily.  Would you say that the type of node you are testing on in prod is a very, very slow node with very low ram, or is it a super machine running many threads with a lot of ram?