Messages

3901

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

« on: December 08, 2017, 09:11:22 AM »

I will add something like that to my list.

I think the block solo mined are probably mined by big miners that:
1) create an account and configure all their miners to point to the pool
2) maybe have a loss of hash power because of the connection between the pool and their miners (I'm guessing it could make a difference at large scale)
3) pay the pool fees
4) have a botnet and don't want to mine on the pool for the reasons above!

I also updated the testing BX with a "preview" of what I'm doing. It's all still very early.

Edit: Reimage is taking longer than expected but should be available soon.

Right, Im with you, I can imagine someone who has 50 servers, who pointed to the pool and then dont maintain those boxes and they all keep solo mining.

Note : I do want to say, the pool scans back 11 blocks after every block just to make sure someone didnt solve a back block.  So the pool goes back and backpays for every block paid to it.

If you have a botnet, and you fall out of the pool those actually start getting signed by You.  So pool never keeps a block not its own.

3902

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

« on: December 08, 2017, 08:42:10 AM »

thanks for your time Rob ...

is any solution why masternode crashed to NEW START REQUIRED? im wrote more topics about it on DASH and ppl got still this problems,every day checking their masternodes....it can be nervous still checking if something is running ....
1MN working stable 4+days and 1 go to that start req: so i start MN from controller and run watchman ...
andy idea? thanks

It looks like NEW_START_REQUIRED is triggered if your node fails the POSE test.  That means it either fails to vote within 24 hours for itself, gets ddossed, loses its static IP or crashes.  Then the other nodes vote to boot your node from the team and requires a restart by the owner of the sanctuary to get back "in" the payment queue.  You lose payments until you restart the node - from the controller - not from the node.

3903

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

« on: December 08, 2017, 08:39:00 AM »

Hi Alex,
Not sure if you saw this post from Slovakia on the main thread, something to the extent of he believes the pool is stealing peoples blocks by hiding the blocks found, but it made me think of a potential enhancement to your BX.

If you label the MinersOfMen address and the Pool with pool.biblepay.org, then could you potentially make a "Coins Mined in Last 24 hours" metric and put it somewhere? Somewhere that is not hit every time, or, maybe you could cache it and put it right under the address in the richlist?  Another words whatever is convenient for you. (You can do exec getsubsidy height for nTip to nTip-202 when you call it then sum it and cache it for an hour).

Then we could have whoever reads it compare it to pool.biblepay.org coins mined on about page, and know they agree.

Then after that, all we have to worry about is why do we have 65% of the blocks solo mined?  Thats another important project.  Is there any way to see if the non pool blocks are going to random addresses? 

I have an idea that could thwart a botnet, but it needs to be tested in testnet.  I was thinking, if we took an element of proof-of-stake, Spending money to stake, and added it into POW, and required each miner to stake 1BBP while mining, it would make it almost impossible to not CPU mine (as the 1 bbp at stake would need to be added to the block).  Then we would need to require the 1BBP tx to never be older than say 60 seconds, so as to thwart any GPU or asic.  The problem is getadjustedtime() can be skewed up to 15 mins.  This is still a tough issue to solve.

 

3904

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

« on: December 07, 2017, 10:19:14 AM »

Just checking in - looks like everything is looking pretty good for the go live.
We beat our record, weve been in sync and masternode list up for 4+ days now.
The windows node has stayed in sync and MN list agreed with Nix node ever since I deleted those old .dat files!

I added a fake proposal yesterday and it looks like pool paid the necessary 5BBP to make it Live although noone voted on it yet, but I anticipate that to work for us.

Has anyone any consternations or last minute concerns?  Im actually going to have to notify CCEX soon to give them a 2 week notice to upgrade, start finalizing changes and things for our mandatory.

I believe the Amazon in-wallet product feature is going to go live also (for the US only) at Christmas.  That should be interesting.

On a side note, Im going to downplay the retirement accounts.  They will emit coins, but Im not sure how well we can support that feature.  Im a little nervous to go down the path of creating a trading infrastructure for them.  I might make a feature that allows you to trade your rBBP back into BBP (at the internal satoshi exercise rate) in the wallet.  Im thinking my efforts on Stratis may be more beneficial for us right now than to monkey with supporting a new in-wallet exchange.

3905

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

« on: December 06, 2017, 08:29:12 AM »

Running valgrind now. I will send you the logs if I see anything!

Edit: Also concerning the masternode list, I had this same issue with other altcoins where it was taking some time for the masternode lists to propagate and be refreshed/in synced. Assumed that there was a reason for that but never looked into it and just accepted it haha.

That is mainly why I'm displaying the masternode list on the BX for people to compare with what they have. I'm going well with the revamp of the BX and improving that page is def on my list.

Thanks a lot dude.
I have some further info regarding the masternodelist.
My windows box is the one that is not agreeing, so I deleted all the .dat files related to masternodes (mncache.dat, payment.dat, gov*.dat) and then restarted (note, you do not want to kill your chainstate or blocks in this case).  Then I waited about 20 minutes, and it synced to the same state the nix box was in (Note it was a 2 step sync: step 1 just populated the mnlist, with NEWSTARTREQ for everyone then it took 15 more minutes to pull the states of each node).  So apparently there is an issue where your local mncache view of the masternodes can get out of sync and the wallet is not smart enough to ask to kill and refresh that. 

Thats all I know so far guys , anyway, I have an IT issue that is on fire so I will be back asap as soon as I can, have a good one.

3906

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

« on: December 06, 2017, 07:40:49 AM »

Thank you for your help! I've banned all except the ip's in your list.

@admin: Thank you for the clarification. But the strange thing is that I already updated to 1.0.6.3. and was also mining with my sanctuary, and that there was only one chaintip when my setup was like that (see my post from a page back).

But when I tried it again a day later I got the huge list of chaintips I posted. So one day everything is fine and the next there were a lot of chaintips.

I'm reindexing as I speak. But a lot of times then I try './biblepay-cli -testnet getchaintips' biblepay seems to exit and I have to start up again. Maybe I need to do a clean install in the next couple of days, because something doesn't feel quite right with my installation right now...

I dont think its your machine; I see that getchaintips does silently exit on my windows box.  My linux box has less chaintips and finishes the command.

(Although on a side note, I remember seeing a bitcoin getchaintips, and it had a huge amount of tips, so now, I do  not actually think the tips are a problem, as long as we stay on the main chain, but I have to confirm that.  If thats the case, I can modify the command to clean the blockindex while it runs and discard chaintips older than a few hours).

However I would like to fix the code, Alex can you help with valgrind?    Can you see if your getchaintips exits on any of your boxes and if so run it while valgrind is running?  I need to get around to installing valgrind on my gitian machine.

I see one other issue.  Although it looks like we are staying in sync now that we have the diff > .10 in testnet, I see something that I believe Slovakia was mentioning: the windows controller does not have the same masternode list, but its in sync.  I cant fathom how that can be, as Sentinel on the dash side only runs on Linux.  meaning that we are not doing anything special by having windows controller wallets and Nix Watchman.  Ill check into that.  Although it appears to not be hurting anything at the moment, its definitely a nuisance.

3907

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

« on: December 03, 2017, 07:07:30 PM »

Code: [Select]

}
jaap-ubuntu@jaapubuntu-HP-Pavilion-dm1-Notebook-PC:~/biblepay/src$ ./biblepay-cli -testnet getchaintips
[
  {
    "status": "valid-fork"
  }
]

Does this mean there are a lot of forks?

There were a lot of forks before we made 2 changes:
- We realized the masternodes were not hashing, so there was a propensity to fall off the masternode chain, now they are hashing
- The version prior to 1060 had a bug that Alex found that we corrected that could have caused most of the forks

In your case please start with the -reindex flag and let it rebuild, then getchaintips should be clean.



After that, lets run for a few days and see if the masternode list stays ENABLED and getchaintips stays clean....

3908

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

« on: December 03, 2017, 08:01:54 AM »

same block
ID:999



and after few hours when i checked in /src getinfo my my masternode on testnet actually crashed biblepayd stopped running= same case like few days ago Alex,jaapkg,me

this things must be fix when you want to run MN

"and after few hours when i checked in /src getinfo my my masternode on testnet actually crashed biblepayd stopped running=

"same case like few days ago Alex,jaapkg,me"


First let me address the statement above - if you want to be a testnet tester then I need higher quality info from you.  Info like what Alex is sending me.
You say above the phrase "same case like a few days ago".

First of all, I dont know if you are referring to the One crash Alex received which he has not gotten back again on and he has valgrind, or being out of sync.  So I cant really even reply properly.  But I do want to say just because your two nodes with mnsync status shows 999, you cant make the assumption the node list is synced yet.  The local watchman database has to populate also.  Id wait 24 hours after mnsync shows 999 then look at the list.

3909

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

« on: December 03, 2017, 07:57:27 AM »

next bug: im set sending 500k via DASH tutorial:did REQ 500k and tried send 500k and get this meesage

Thats not a bug; dont make the assumption user errors are bugs.
I see you selected too many inputs.  If you want to spend your masternode escrow, thats One VIN, not a megabyte of inputs.

3910

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

« on: December 02, 2017, 03:52:35 PM »

built 2 MN in 1 controller wallet: and working stable 

where is tutorial for this?on wiki i see nothing http://wiki.biblepay.org/Create_Masternode

You have to enable coin control, and deliberately unlock the escrow

very important question which doesnt exists on wiki tutorial:
you sending 500k bbp from 1 win wallet to 2nd wallet and this transaction is TX:1 ... cos before i sent alwayss 500k to linux VPS and didnt work....

thanks

need fix this
1.controller shows totally bad info about ENABLED MN... in VPS when i masternode listing,shows different things
2. my 2 vps shows diff things about maternode-list and status about others masternodes



uff,where is bug?

See if both VMs have the same best block hash.... First....

See if both vms say mnsync status 999 first...


Regarding relinquising a masternode, I dont understand the problem... Weve talked about it here a few times.

3911

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

« on: December 02, 2017, 12:36:04 PM »

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.

3912

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

« on: December 02, 2017, 09:50:37 AM »

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

3913

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

« on: December 02, 2017, 09:07:57 AM »

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.

3914

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

« on: December 02, 2017, 08:55:39 AM »

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

3915

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

« on: December 02, 2017, 08:54:03 AM »

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.