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

[Rob Andrews]

Code Select Expand

./biblepay-cli exec orderstatus
{
  "Command": "orderstatus",
  "0718083296": {
    "Product ID": "0718083296",
    "Price": 12230,
    "Added": "",
    "Title": "The NKJV, Holy Bible, Larger Print, Paperback",
    "Status1": "PLACED",
    "Status2": "FILLING ORDER",
    "Status3": "USPS XXXXXXX",
    "Details": ""
  }
}


I see the order status! (replaced it with Xs)

USPS tracking service is currently down haha, so cant check online yet, but awesome!

Oh thats great dude!
Yeah, a week ago I thought man its going to be so awesome to put Amazon inside the wallet, then this article came out :
https://www.thesun.co.uk/news/5004230/amazon-warehouse-working-conditions/

Im sure it will blow over, but its kind of disappointing to see a company with so much success be so greedy for profit.
I thought their warehouse workers made some money, but it says here they have tactics to hire people under minimum wage - similar to how the mechanical turks from AWS make .25 cents an hour...

[Rob Andrews]

@Rob, found an easier way to do it without the rpc call. I will just swap it myself so I just need a list of all the abbreviations used by biblepay and their corresponding names.

Edit: Added something similar to reftagger.
https://testnet.biblepay-explorer.org/block/9ab71b36d99342ccd3db656e7804e84eec501b67b66ed983d915c5eac3aea15e

Edit2: Found the abbreviation list, will add them soon.

Edit3: Everything has been added. Pushed it to the prod explorer.

Dude, that is simply stunning!  I like the spinner that comes up while its retrieving the verse also!
I figured you would find the book list in the code LOL.

This is really what cryptoenthusiasts are looking for when I said we should find features to add value to BBP.
I know its only 16 hours of your work now, but Im telling you in the future, these type of things will be the cornerstone of biblepay if we dont go through the great trib soon.  Once we have enough organic users, people will be all over the internet mentioning things like this and driving us up to 80MM-120MM market cap.

Now I need to step up and add some myself . 

Ill mention this feature in our other forum now and then you can talk about it when people reply....

Thanks!

[jaapgvk]

The masternode page is looking good and is pretty much done!

https://testnet.biblepay-explorer.org/sanctuaries

Awesome work Alex! Looking good

Looking at the masternode list, mine says 'NEW_START_REQUIRED' in your overview (84.29.208.33:40001). That's strange, because my masternode says 'ENABLED' when I call 'masternodelist' and my controller-wallet says 'WATCHDOG_EXPIRED'.

So I've got three different status-things going on with the same sanctuary :p I've been getting my payments and the both the sanctuary and controller-wallet are on the same chain:

Code Select Expand


22:40:29

getblockhash 53371


22:40:29

ad3302691447683831b4d4063211929960c4e3cb589e663119320979af1b2a21


What do you guys think this might mean?

[klondike]

1.starting masternode being few minutes for me between 45-100minutes
2.after offline msaternode,you will be still receiving rewards = its call falltime

[Rob Andrews]

Oh also if I may add, you may still receive rewards even if your masternode "dies" / is not valid anymore (up to 36 hours after it dies).

Yes, that masternode list looks great!   Well at least its pulling the view from the wallet, so that puts the onus on us here to figure the rest out regarding consistency.

Btw, did you ever figure out the exact hours elapsed when you stopped receiving payments?

I have a tad little bit of insight on the PRE-ENABLED flag.   If you blindly call masternode start-alias (as most people do) the command is sent over the P2P port (40001), reaches the actual masternode and the masternode logs something to the effect of "masternode sync data not synced yet" and no error is raised (and a log is logged on the masternode but only if debugmaster=true).  So yeah, its a nuisance, but no work was ever put into it because there is a workaround.  The workaround is you must first go to the masternode and type mnsync status and know that it only follows controller commands if mnsync status is 999.  So in real life, we basically just need to click on the peer height in your controller to see if the node is in sync and then issue the command 5 mins later.  Its just a pitfall we need to know about.

One other thing on this topic:  If the masternode made enemies with a section of the network (IE ddossed 3 out of 5 masternodes), it will no longer follow the same potential fork.  Thats probably what happened here when I shut down my vultr nodes, we lost 2 of 5, and a couple who were only peers of vultr started mining their own chain.  Their mnsync status is then different than the other masternodes (because their payment ranking is different), causing all kinds of potential problems.  So the expectation is, in prod, with over 100 masternodes we will be clinging to the same chain due to the supermajority being on the same sync height.

[Rob Andrews]

Awesome work Alex! Looking good

Looking at the masternode list, mine says 'NEW_START_REQUIRED' in your overview (84.29.208.33:40001). That's strange, because my masternode says 'ENABLED' when I call 'masternodelist' and my controller-wallet says 'WATCHDOG_EXPIRED'.

So I've got three different status-things going on with the same sanctuary :p I've been getting my payments and the both the sanctuary and controller-wallet are on the same chain:

Code Select Expand


22:40:29

getblockhash 53371


22:40:29

ad3302691447683831b4d4063211929960c4e3cb589e663119320979af1b2a21


What do you guys think this might mean?

Yeah, looking at Alex's testnet masternode list, something does look wrong....

Im showing you on my masternode list as enabled now (84.29.208.33).  First, you are right in that when you issue the command to start, the local wallet just changes the caption blindly.  However, the other values: watchdog_expired, Enabled, new_start_required should be network values. 

But looking at 45.76...64 and 45.76..42 those two are Enabled on my controller, my vultr, my other vultr, my dev machine but "Expired" in the explorer... Hmmmmm, explorer is synced though.  Thats strange.

Alex, what happens if you look at those 2 node statuses from the GUI?  Do they match the explorer?

[Rob Andrews]

Just checked my logs and saw a spam of invalid block headers. I also noticed that there hasn't been any new block since the 28 lol. My explorer somehow went on a fork. I'm going to resync it now.

Yeah, btw, I have some inside info on why some forks start to occur (at least part of the problem).  If we have say 8 masternodes, and lets say 2 are only connected via 1 node to the rest, if that 1 node gets ddossed, that masternode will have a propensity to create its own chain (especially with our low diff on testnet).

Now the smoking gun here is our recent fix to the biblehash itself makes it much more likely that those running 1062 are all producing the same hashes.  So, somehow we should probably make an effort to ask everyone on testnet to upgrade to 1062.

What I can do from my side is force an upgrade to 1063, and force a protocol upgrade (meaning everyone lower than 1062 actually gets disconnected).  It might be worth doing between Dec 2 and Dec 20th just to ensure we dont have a lurking problem.

Let me take a look at the retirement issue before monkeying with it.  I think we were close on that but not quite done.

EDIT: BTW, you may have to delete your banlist.dat before resyncing to bring back all nodes into your testnet node.

[Rob Andrews]

I decided to look at the peers I was connected to using getpeerinfo and I think a lot of them are on a different chain (with the latest block being 53062).
Could you have a look at that on your own nodes Rob?

Hmm, I see a huge problem in getchaintips.  We have about 30 prior forks due to all those bad headers.
I think if I make a release with a few testnet checkpoints we can eliminte 99% of that  problem.

For now, Im seeing 54088:

08:41:19

getblockhash 54088

ad4510d1c7fa0ca1cda93c4119581374612737ea41fa5e9e338c65ebd273308a


Alex, try deleting mncache.dat on your 3 testnet nodes and banlist.dat and chainstate and blocks and resyncing?


Ill work on adding a few checkpoints now so we can all clear out our chaintips problems.

[Rob Andrews]

I just deleted blocks and chainstates and it's resyncing right now (the testnet explorer is actually already synced. It just takes a few minutes for the mongo database to reindex everything).

Somehow my nodes never banned anyone.

I just checked and I also have ad4510d1c7fa0ca1cda93c4119581374612737ea41fa5e9e338c65ebd273308a for 54088.

Its possible my nodes banned you when you went on the fork originally (as you would be voting to not pay my 3 masternodes , thats why it gets so severe.  Your nodes say No Im not going to add a payee that I dont know about.  My nodes say you must pay these 5 nodes, in this order.

Alright I added checkpoints, and I counted 50 forks in getchaintips Before checkpoints.  Let me see how many we have now after checkpoints.

[Rob Andrews]

Oh ok. What is weird though is that I was still connected to 20 nodes and receiving bad headers before I resynced.

I'm now on the good chain and I am pretty sure I am connected to the same 20 nodes. (also isn't one of your node the seed node?). So it looks like I didn't ban anyone and no one banned me?

Yes true, but it is also possible my node.biblepay.org only banned you for 1-8 hours (IE one d-dos level 1 ban per bad header received) putting you on a bad fork and while we were looking at it its possible the ban expired.

Anyway I was going to say this is such a critical test, before Christmas, I think we really need to fix the chaintip issue and force a protocol upgrade to 70709, just to ensure we have a long span of uptime for all of our core masternodes.

Just a heads up everyone, I am writing the code to force a network upgrade on testnet only, so please be ready to upgrade as during the next upgrade, all the nodes will disconnect on each other if they are running a prior to 1.0.6.3 version.

It should be out in about 30 mins....

[Rob Andrews]

1.0.6.3-Mandatory Upgrade for TESTNET

Please all, in testnet, please upgrade to 1.0.6.3.

The entire network is down until we upgrade.

Building windows for controllers now...

[klondike]

how big will be traffic on VPS for masternodes?

[Rob Andrews]

how big will be traffic on VPS for masternodes?

Not much, masternodes only take up 10% more than bitcoin.

[Rob Andrews]

The testnet BX has been upgraded.

Success!

Upgraded all 3:

12:16:30

getchaintips


12:16:30

[
  {
    "height": 54194,
    "hash": "9a412d5c7faee2f5048a0dec4ba6ed45b81e595a834e43eef9c64a65d38700ac",
    "difficulty": 0.01934920419809971,
    "chainwork": "00000000000000000000000000000000000000000000000000002f6df8bc31f4",
    "branchlen": 0,
    "status": "active"
  }
]

Chaintips is clean!

Crossing fingers this trend continues til Christmas...

Still waiting for windows to finish compiling....

[Rob Andrews]

A couple more tips:
If your getchaintips is not clean, restart with -reindex flag, and resync.

Next, if your sanctuary list differs from Alex, delete your mncache.dat and restart.

=-=-=-=-=

Windows compile of 1.0.6.3 is out there now, feel free to upgrade controllers.