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

[Rob Andrews]

Hey Rob, I'm modifying some things and I can now provide a dns seed node for mainnnet and testnet (should be available soon).

mainnet:
dnsseed.biblepay-explorer.org

testnet:
test.dnsseed.biblepay-explorer.org

Edit: just to avoid the confusion, these will be dns seed nodes so they will just crawl the network and give back a list fo reliable nodes to connect to! I "may" also provide regular seed nodes.

Thanks a lot alex, I added your two DNS seed nodes to ThreadOpenAddedConnections.  This is called once when the wallet starts and does a one shot add of normal DNS addresses (we have 4 now in here):
      AddSeedNode("node.biblepay.org"); // Volunteers welcome to run external nodes and we will add during future releases
      AddSeedNode("99.198.174.212");    //PlainKoin
      AddSeedNode("dnsseed.biblepay-explorer.org");  // Alex
      if (!fProd) AddSeedNode("test.dnsseed.biblepay-explorer.org"); // Alex (TESTNET)


So thats great, that should give us start up stability for new users who open the wallet in fringe areas.  Or in AWS for example.

Yeah, dont worry about the elaborate requirement of bitcoin-seed nodes - that requires running another seed server.  These DNS seed nodes should cover us for the foreseeable (foreseedable LOL) future. 

I tested your node (telnet dnsseed.biblepay-explorer.org 40000) and its working.  Will be in the next release.

Thank you for your support .

[Rob Andrews]

I received the Bible in the mail Tuesday morning and got it out today, Thank you Rob!

./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 XXXXX",
    "Details": ""
  }
}

Thats great buddy!  So do you guys think this will be a hit in prod?

I have not received any orders in the pool itself (IE BiblePay Storefront) for anything yet.

We can of course add more items to the list for Prod.... Of course it would be nice to have a popup with an actual picture in an HTML frame, but Id like to see how popular this feature is first.

It will definitely accomplish one thing if used:  market depth - as the sales would create volume on the exchange, and thats what we need for debit card integration.

[Rob Andrews]

On a good note, both my dns seeds are now up and running!

On a bad one, it looks like my BX went on a fork (stuck on block 55990 now). I'm restarting it now.

Yeah, I see the same problem you and Klondike have- my main test nodes stayed on the right chain with the masternodes, my controller win wallet just went on a different chain.  Here is the chain I show the enabled masternodes running on:


getblockhash 56000
0f1f17e9bb4e0889b81794708f9bb16908ba2c2b0f5e34dc033d7d2e3d03bc95

Regarding the question about prod, it depends on why this is happening.  Ill look at my windows logs and see if it banned the rest of the network.

EDIT:

Lets try to get to the root of the problem with this one.
On my windows node, if you want to see if you have similar problem, go to peers and take a look at the banlist.  I banned every peer.

This time Im not reindexing the chain, Im going to unban peers and see if it catches up.

[Rob Andrews]

Oh also, that crawler allowed me to see that we have 70709 running on mainnet, is that normal?

Wow thats great on the crawler, yeah, on 70709, yes, because the wallet supports some advanced rules.  I copied the prod rules to testnet first before doing this:

On testnet, the minimum required version is 70709, that ultimately forced the upgrade and instructs peers to hang up on peers with a lower protocol version.

On mainnet, the minimum version required is 70708, but it is OK to run a higher version.  After Christmas though, the mandatory would have something like "required minimum version 70709" in it (otherwise peers disconnect).

So thats OK for now.

Im working on the out-of sync condition, we need to get to the bottom of this thing.

I see that it occurred on block 54360 on my win node:

2017-12-02 00:10:19 IsBlockPayeeValid -- ERROR: Invalid masternode payment detected at height 54360: CTransaction(hash=2bbbb94c92, ver=1, vin.size=1, vout.size=3, nLockTime=0)


So basically the group of masternodes themselves did not experience this issue, but my win node refused block 54360.  I see that it did not create 54360.  Weve got to think of why did its view of payees differ from the main group (as this happened before the banned nodes occurred).  It banned every other node After this.

[klondike]

now what block is OK... im resync and my linux wallet sync with same block like controller wallet



Rob,which IP is your? exists any correct chain?

[Rob Andrews]

now what block is OK... im resync and my linux wallet sync with same block like controller wallet



Rob,which IP is your? exists any correct chain?

im 97.99.69, and the two 45.x.x's.

We have one shorter chain (block 56061) that seems to be the one with all our masternodes on it.

[Rob Andrews]

So, I have a small amount of info as to what is happening:


08:47:13

getchaintips


08:47:13

[
  {
    "height": 56794,
    "hash": "b6309b95902c56470ef27a4442df5db0860e1cc3854db230cb6ede10eef6d906",
    "difficulty": 0.01837265411190288,
    "chainwork": "00000000000000000000000000000000000000000000000000002f88fdc59002",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 56057,
    "hash": "6988dfa709707d99ae448da5984be132fdb7f13e274c00be9fb605f32dabac1f",
    "difficulty": 0.007104095844318024,
    "chainwork": "00000000000000000000000000000000000000000000000000002f80151d1740",
    "branchlen": 1708,
    "status": "headers-only"
  }
]

We have two chains : 56061 and 56794.
Heres what is funny about it:  The shorter chain has the masternodes synced on it and in agreement, but less chain work.
The longer chain has more chain work (notice its diff is .01 while the masternode chain is .007).  So the controller wallets pick the chain with more work, because thats part of the active-chain setbestchain rule, however the masternodes have banned those nodes already and prefer their own chain (primarily because of our rule to enforce sanctuary payees in a ranked list, which is part of Dash).

So its kind of interesting that the only way out is for me to blow the chain away and resync.

My question is, if we had the prod chain where obviously all the miners would be mining, and diff would be 10,000 instead of .01 will we stay synced on the chain with the most work in prod?  It SOUNDS like we would, but ..... lets keep thinking about this.

[Rob Andrews]

Ive got an idea to test fixing this.  Lets all turn mining ON on our masternodes.
Lets get the diff up above 2.0 on our masternode chain... and then see if we stay in sync....

EDIT: I do see a possible reason that started this.  On TestNet its OK to mine on an out of sync chain with no peers.  On Prod you have to have a synced chain and peers with you.  So thats a huge difference.  Technically, the controller wallets are missing 3 things:  They are synced to best height, but mnode data is NOT synced (that requires masternodes, and mnsync status 999), and they banned every masternode peer.... 

So this does sound like an important exercise for us.  Lets try to fix the sync manually on the non-conforming peers, reindex those, and drive the diff up on the masternodes.


Then regroup for 10 more days and see if we can break the stay-in-sync record (I think thats only 3 days long LOL).

[klondike]

then all is gone with my masernode+controller wallet?  im on 56799 bigger chain ...
and yes... my VPSlinux was on low chain and my controller is on bigger chain ... very interesting ...

how can i fix it now?

[Rob Andrews]

then all is gone with my masernode+controller wallet?  im on 56799 bigger chain ...
and yes... my VPSlinux was on low chain and my controller is on bigger chain ... very interesting ...

how can i fix it now? ill try to ban all bigger nodes and allow all your MN nodes

Try starting with -reindex, and while reindexing ban any peer with a block height higher than the small chain.

Im mining on my 3 masternodes now - diff > .10 so far...

Once masternodes advance 700 more blocks it will be a moot point, but lets hope we stay in sync after we get this back.

Alternatively you can just shut off the nodes on the long chain and wait a day and turn on tomorrow with an empty chain.

[klondike]

yes,.super..... on VPS and WIN i added bad IPs to banlist and resynced: working!!!

now my masternode immediately ENABLED 
xx.xx.xx.106   vps
xx.xx.xx.58     home controller
now starting testing

now try running 2nd masternode to 1 controllerwallet

Robinho: can i ask,dont know this thing=  when i will be have in controller-wallet (1,550,001 BBP) and rewards ill be receiving: can i to withdraw any BBP from this controller wallet? the balance can not fall under 1,550,001 BBP?

thanks for this question...

[Rob Andrews]

yes,.super..... on VPS and WIN i added bad IPs to banlist and resynced: working!!!

now my masternode immediately ENABLED 
xx.xx.xx.106   vps
xx.xx.xx.58     home controller
now starting testing

Robinho: can i ask,dont know this thing=  when i will be have in controller-wallet (1,550,001 BBP) and rewards ill be receiving: can i withdraw any BBP from this controller wallet? the balance can not fall under 1,550,001 BBP?

thanks for this anwer...

Yeah on a side note, I see my controller wallet synced as soon as it saw the masternode chain was .11.  Interesting.  Im hoping that was the problem, knock on wood.  The wallets are designed to sync to the chain with the highest diff (IE the most work).

Anyway lets talk about the escrow now.

During the third week of December I plan on poring through the code and updating any code required for the mandatory for Us and for c-cex.  Obviously one thing is the higher sanctuary escrow requirement.

Lets say you have one controller with 4 million BBP in it, and you decide to start two masternodes.  That means you will dedicate 3100002 BBP over two transactions for the investment of two masternodes leaving 899.9K spendable.

The wallet has code in it that will lock the 3.1MM escrow so that it wont be spent by you under normal circumstances.  For example if you attempt to  spend it, it will balk at you and never select those coins , therefore you cannot spend more than 899.9K.

IF you want out, and you want to relinquish your rights to one of your masternodes, you have to do this to spend it:
You have to enable coin control, and deliberately unlock the escrow (by selecting it) and then deliberately spending the selected escrow.  Once even 1 BBP of it is spent, that particular masternode will never work again until new escrow is set up for it.  Once the escrow is disturbed to no longer be "1,550,001" the rewards stop....

[klondike]

otherwise:

i have in my masternode 2M BBP and when i will be want send 500k controller wallet disable my request?

[Rob Andrews]

otherwise:

i have in my masternode 2M BBP and when i will be want send 500k controller wallet disable my request?

Just re-read what I wrote and then try it in testnet.

And then practice withdrawing as a masternode.

[jaapgvk]

I can only see one chain on both the sanctuary and controller-wallet:

Code Select Expand


19:31:52

getchaintips


19:31:52

[
  {
    "height": 56217,
    "hash": "5262f5c3a5f4dd6b233d4882aa84ab17a02cc9aced5cee1be6ad8aeccc5bc84b",
    "difficulty": 0.410893199744191,
    "chainwork": "00000000000000000000000000000000000000000000000000002f916df1cc2f",
    "branchlen": 0,
    "status": "active"
  }
]