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

My MN is actually on a 512 MB RAM instance. And I don't have biblepay-qt nor the dependencies for it, because I installed only CLI. Is there any other way to record crash logs?

Also, now that you've mentioned it, those clock delays in seconds are almost exactly: 1 hour, 2 hours, 4 hours and 9 hours. Hmm, what could be the meaning of that, or what are they trying to achieve with that?

No other way to achieve crash logs- even if you ran with all the switches (instantsend=true, debugmaster=true, masternode=true) etc, would not guarantee that line that caused the segfault would be in the log.  The only thing in the log is what we write to the log.  However valgrind intakes its pointer to the line of source before executing each line, so it is really the only effective way.   

The time attack could be either a) to try to connect and slip a proof-of-work block in that has been pre-hashed on a supercomputer, (because they have the luxury of doing it over time), or b) to try to offset the GetNetworkTime() function - to adulterate it, to bring us as a network forward or back so they can inject a sttring of blocks to make money on their own fork.  We have NTP protection for past & future, of up to 10 minutes, but it relies on the network average time being correct, thats why we hang up on nodes who are off by more than 300 seconds.

Hi, I set up a MN on a Vultr instance (all exactly the same as in the instructions in http://wiki.biblepay.org/Create_Sanctuary_2) and everything went apparently fine.

However

$ ./biblepay-cli masternode status
{
  "vin": "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
  "service": "[::]:0",
  "status": "Not capable masternode: Masternode must accept connections from outside. Make sure listen configuration option is not overwritten by some another parameter."
}

I set up the firewall with rules as in the instructions, and did not create another extra firewall group at Vultr dashboard.

Any ideas for troubleshooting? Thank you


EDIT: just in case:

$  ./biblepay-cli mnsync status
{
  "AssetID": 999,
  "AssetName": "MASTERNODE_SYNC_FINISHED",
  "Attempt": 0,
  "IsBlockchainSynced": true,
  "IsMasternodeListSynced": true,
  "IsWinnersListSynced": true,
  "IsSynced": true,
  "IsFailed": false,
  "MasternodesEnabled": true
}

EDIT 2: ok it was my fault, for some reason I had "listen=0" in conf.

Now it says "Not capable masternode: Masternode not in masternode list"

I understand that it's fine now and I have to wait a few hours to get it listed, don't I?

thanks again!

EDIT 3: now it says "Masternode successfully created", but controller wallet still says "PRE_ENABLED". I will wait few hours more and see...

Haha, great to see that you've solved your own problems

Yes, I think the MN will be enabled soon.

Haha, great to see that you've solved your own problems

Yes, I think the MN will be enabled soon.

There is always a first time for everything my friend.

There is always a first time for everything my friend.

Very true, I learn every day

Is there  a reason the MN payments have plummeted?  I understand there is a variation based on time to solve the block, but when PoDC came about, the payments and timing issues seemed solved for the most part.  Yet today, the MN payments seem more than 10% below what the average had been and are trending towards to an under 4000 / payment level when before they were trending to a just under 5000 / payment level.  There is not a lot of data to look at yet, so maybe I'm getting ahead of things, but the root question is has anything been changed in the last two or three days that would impact this or am I just hitting a run of poor luck?

Is there  a reason the MN payments have plummeted?  I understand there is a variation based on time to solve the block, but when PoDC came about, the payments and timing issues seemed solved for the most part.  Yet today, the MN payments seem more than 10% below what the average had been and are trending towards to an under 4000 / payment level when before they were trending to a just under 5000 / payment level.  There is not a lot of data to look at yet, so maybe I'm getting ahead of things, but the root question is has anything been changed in the last two or three days that would impact this or am I just hitting a run of poor luck?

https://bitcointalk.org/index.php?topic=2388064.msg34061945#msg34061945

Don't know if this is a definitive answer, but it's what I think is the case.

Yes I saw this explanation after asking here.  First, I've not seen this much variation in blocks in a long time, so it is a bit disconcerting.  My personal node has, in the last four-ish weeks (Mar 8 - Apr 6),  had a high of 5001.71, low of 3355.39.  But the only two below 4000 I've ever had both happened in the last four days.  Since it seemed like the overall block timing was pretty close to 205/day then I would suspect most of the blocks were close to their target times.  By my math by the stated formulas, (20K blocks, reducing by 1.5% compounding every 30 coin days, so at 39192 we are in the middle of the 5th coin month, and should therefore have a target (max) block reward of 18,826.73, of which according to http://wiki.biblepay.org/Economics, 38.5% should be given to Sanctuaries.  That would mean the target reward would be 7248.29.  These numbers certainly don't reflect that.  And so the question becomes, is the Economics page out of date and if so, what are the true percentages.  Digging through the code, it wasn't clear to me at first glance where the code thought we should be, but I will dig a little further.

Second, is there a way to reduce the block reward variability.    Measures of central tendency are Mean: 4736.79,  Median 4881.04.  So the 3355.39 block was only 70% of the Mean, and the 5001.71 block was only 105% of the Mean.  That is a pretty wide difference but to have that big of drop from average with only a slight bump from average, leads me to think we might gain some ground by stabilizing the low end.

Finally, I still see masternodes getting back to back rewards, which for the long haul, evens itself out, but could be frustrating for new users who don't get to benefit from the law of averages.  But this does not coincide with the statement that the "longest waiting Sanctuary" gets the reward.

If we are aiming at the investor market, having less variation in the rewards would, to me, be a very important thing.