Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rob Andrews

Pages: 1 ... 167 168 169 170 171 172 173 [174] 175 176 177 178 179 180 181 ... 185
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.

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.

BiblePay - 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 | Downloads

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).

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.

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.


Oh this is mainnet not testnet sorry
Let me restart in mainnet and try that....

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 :)

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....

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?

Rob 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.

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.

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?

[email protected] ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17079
  "Command": "biblehash",
  "BibleHash": "0000000000002aaa46b9dc122688a0e203a7ddec60b104c95c0f1372eb43e0dd"
[email protected] ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17078
  "Command": "biblehash",
  "BibleHash": "0000000000011c6f2cd7107900e4308d6db47227d9f1753e65b9d6fe206f3072"

[email protected] ~ # 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?

  im deleted chain+blocks ans im back  ...

question: how long being when status WATCHDOG changed to ENABLED from WATCH_DOG EXPIRED?


There are multiple layers of issues when you resync. When you have been synced for 24+ hours, if you had a watchdog problem, watchman would update the database and the gui and the votes in 15 minutes.  When you re-sync, your mncache.dat file is hosed and it takes about 6 hours to fix itself.

Lets just ensure your watchman command returns empty, and then wait for something to change once you are synced.  If not fixed in 8 hours something is wrong.

Just started a VM to try it and I also managed to get different biblehash!

Note: The mn4 machine above is running OpenSSL 101t while this one is running OpenSSL 102g

[email protected]-fsn1-1 ~ # biblepay-cli exec biblehash e0118ac9c4b5f6ec508e4bfefc38599fd55e7f79d108a560aeff9ceb0debc347 1510892191 1510890756 17074revheight 17111.000000 pindexPrev 20e9f4416b8e469b23a6fde82f197342086622e9ac827e78875701d001ca3916
2017-11-17 10:05:14 ERROR: CheckBlockHeader(): proof of work failed
2017-11-17 10:05:14 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-17 10:05:14 Misbehaving: (0 -> 5)
2017-11-17 10:05:14 UpdateTip: new best=541a323bbf91103d90556af0e5b9143673a2cd36680fffe21bc3b7a9cbc85356  height=17112  log2_work=57.818294  tx=28819  date=2017-11-17 10:05:12 progress=1.000000  cache=0.0MiB(112tx)

Nice tests, thanks, you really gave a lot of data to work with and pretty much every condition LOL.

So Im going to make this my top priority today. 

On your question about re-running the biblehash command with a prior blocknumber parameter (the ones you noted 17069, same as 17079) etc, that is fine because the block number parameter being sent into the biblehash is only used for it to determine the chain height, to turn on or off f7000 or f8000, and that is enforced on all nodes so that is secure, so changing that between f7000 start and f8000 start will just give you the same exact biblehash, so that is OK.  Changing the lastblocktime is a similar issue: that only drives when the block becomes "late".  When the block time exceeds 30 minutes then and only then the hash changes, so that is OK too.

On the question regarding the if statement, which hash its using, in this last version 1060, it is actually checking both, first it says if biblehash1 is too high, then if biblehash2 is too high, so your log only yields errors where they both were high hashes.  But thats OK too, because you still exposed enough information.

However I wasnt sure if you had to run the cli command 10,000 times programatically to change the hash in your example because I ran one of your examples 125 times from my RPC and received the same hash every time so so far I have been unable to change the hash like you have, but dont worry, I have enough info from your log for something to go on.

But focusing in on the one where you show that the hash1 and hash2 are actually completely different now that is the big dog right there, that is the smoking gun, I have never seen that.  Imo, that rules out the math operator and math class, that was generated on 101t, so it "points" toward not being openSSL versioning, it really points to either the MD5 function 'caching' the prior result (from the last blockindex check), or the AES512 vector 'caching' the last result.  So I think today, Im going to hone in on making an alternate (compatible of course) biblehash, using a different md5 supplier and refactoring the AES512 call, and we can run that side by side, and see if something changes.

Pages: 1 ... 167 168 169 170 171 172 173 [174] 175 176 177 178 179 180 181 ... 185