BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 451.

togoshigekata

full member

Activity: 1260

Merit: 115

Quote from: noxpost on May 31, 2018, 01:34:58 PM

Can't remember who is in contact with masternodes.pro but I see that we have been moved over to maintenance due to "internal server error" - not sure what all that's about, could have been the crash yesterday, but worth reaching out maybe. Does anyone still have a contact there?

I put in support ticket to them yesterday with instructions on how to clean the wallet,
they replied back, they said their debug.log reached 17GB in size LOL

noxpost

jr. member

Activity: 235

Merit: 3

Can't remember who is in contact with masternodes.pro but I see that we have been moved over to maintenance due to "internal server error" - not sure what all that's about, could have been the crash yesterday, but worth reaching out maybe. Does anyone still have a contact there?

noxpost

jr. member

Activity: 235

Merit: 3

Anybody still struggling with the explorers, try mine again:
https://explorebiblepay.com

It should be responding a bit better now....although if I see it getting flooded with programmatic requests, I may take it offline temporarily.

thesnat21

jr. member

Activity: 490

Merit: 4

Quote from: slovakia on May 31, 2018, 11:37:48 AM

thesnat21 i like more WCG then ROSETTA

Then ask IBM to get their butts in gear so we can access the data

sunk818

full member

Activity: 1176

Merit: 111

Quote from: thesnat21 on May 31, 2018, 08:44:52 AM

From this you could actually have less than 1 per bbp for large quantities since its >= 4%

Sorry, my minimum example was wrong. So, 4% is the minimum you need to stake? 1 RAC -> 4 BBP?

slovakia

full member

Activity: 770

Merit: 100

thesnat21 i like more WCG then ROSETTA

thesnat21

jr. member

Activity: 490

Merit: 4

Quote from: slovakia on May 31, 2018, 10:48:28 AM

Lichtsucher thanks

and whats with WCG? ROB?

Update yesterday said no change, we're stuck waiting for IBM to sort it out.

Some patience is required, lot of red tape at a big place like IBM

inblue

full member

Activity: 462

Merit: 103

Quote from: Lichtsucher on May 31, 2018, 10:00:13 AM

The problem is that iquidus isn't a great software, it handles problems quite bad. I'm just thinking about to setup the database new to get rid of these problems on my explorer.
But really, I don't like iquidus. But it was easy to setup.

Are these alternatives feasable?

https://github.com/bitpay/insight/

https://github.com/blockcypher/explorer

Though it looks like there is more work to set them up than Iquidus.

haladez

newbie

Activity: 19

Merit: 0

Quote from: togoshigekata on May 30, 2018, 03:39:11 PM

Wallet Crash wise, Id advise everyone having issues to Clean and Reindex their wallets:
https://www.reddit.com/r/BiblePay/comments/7nmvm8/how_to_update_clean_wallets/
and also delete debug.log file if it is large

Windows:
- Open File Explorer: %appdata%/BiblePayCore
- Delete blocks and chainstate folders
- Delete banlist, fee_estimates, governance, mncache, netfulfiled and peers .dat files
- Delete debug.log
- In Wallet do Tools >> Wallet Repair >> Rebuild index

I've tried that and it doesn't work unfortunately.

I have reinstalled it completely and still get this in the debug file:

Code:

2018-05-31 15:50:29 GUI: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

2018-05-31 15:50:29

************************
EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_16bad_lexical_castEEEEE
bad lexical cast: source type value could not be interpreted as target
C:\Program Files\BiblepayCore\biblepay-qt.exe in Runaway exception

slovakia

full member

Activity: 770

Merit: 100

Lichtsucher thanks

and whats with WCG? ROB?

noxpost

jr. member

Activity: 235

Merit: 3

Quote from: noxpost on May 31, 2018, 10:26:42 AM

Quote from: Lichtsucher on May 31, 2018, 10:00:13 AM

Quote from: slovakia on May 31, 2018, 09:32:56 AM

where is problem? thanks

The problem is that iquidus isn't a great software, it handles problems quite bad. I'm just thinking about to setup the database new to get rid of these problems on my explorer.
But really, I don't like iquidus. But it was easy to setup.

I'm sort of thinking the same - my guess is that it is poor indexing in the db that is causing the problem, but I haven't had a chance to look into it yet. I'll let you know if I find something first.

Hmm, Licht, have you checked your /var/log/mongodb/mongod.log file? Mine shows that I'm getting a frankly-hard-to-believe 3-4 queries a second. I'm sure I'm not set up for that load on the kind of machine I'm running on, and I find it hard to believe that load is legitimate. I can certainly scale up the hardware if there is a legit need, but I'm curious if it is just me seeing that.

noxpost

jr. member

Activity: 235

Merit: 3

Quote from: Lichtsucher on May 31, 2018, 10:00:13 AM

Quote from: slovakia on May 31, 2018, 09:32:56 AM

where is problem? thanks

The problem is that iquidus isn't a great software, it handles problems quite bad. I'm just thinking about to setup the database new to get rid of these problems on my explorer.
But really, I don't like iquidus. But it was easy to setup.

I'm sort of thinking the same - my guess is that it is poor indexing in the db that is causing the problem, but I haven't had a chance to look into it yet. I'll let you know if I find something first.

noxpost

jr. member

Activity: 235

Merit: 3

Quote from: bible_pay on May 31, 2018, 09:22:41 AM

Quote from: noxpost on May 31, 2018, 08:23:55 AM

I'm curious about something I'm seeing in the masternode list. There are a few occurrences of multiple masternodes (or at least multiple txsigs) that are utilizing the same BBP mining address. For instance:

BBgWqkMQJXNioAgmJ8ZtMFzL51DWEBVomy has 2
BAqBZkMieZfES9LkVgcMmMPv3E68tZt9G8 has 3
B6JwmtM8fg3AwJjaKCV62zhX8CtLgrK6um has 2

Is that ok? Shouldn't there be a unique address generated for each masternode? It seems like the payments would get spread out too much otherwise, due to the algorithm that processes payments not being able to tell that these are distinct if it utilizes the BBP address rather than the txid for payment decisions (but I admit, I haven't checked that code out). Anybody know how that works?

Thats OK, because we pay by VIN not by address. The payment votes are tied to the VIN and the VIN is tied to the payment address.

They apparently set them up without creating multiple addresses (like the guide shows).

As always, thanks for the quick and clear answer, Rob. Appreciated.

Lichtsucher

jr. member

Activity: 219

Merit: 3

Quote from: slovakia on May 31, 2018, 09:32:56 AM

where is problem? thanks

The problem is that iquidus isn't a great software, it handles problems quite bad. I'm just thinking about to setup the database new to get rid of these problems on my explorer.
But really, I don't like iquidus. But it was easy to setup.

slovakia

full member

Activity: 770

Merit: 100

all 3 explorers doesnt working

502 Bad Gateway
502 Bad Gateway
504 Gateway Time-out

looong response, miners cant find addresses,etc

where is problem? thanks

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: noxpost on May 31, 2018, 08:23:55 AM

I'm curious about something I'm seeing in the masternode list. There are a few occurrences of multiple masternodes (or at least multiple txsigs) that are utilizing the same BBP mining address. For instance:

BBgWqkMQJXNioAgmJ8ZtMFzL51DWEBVomy has 2
BAqBZkMieZfES9LkVgcMmMPv3E68tZt9G8 has 3
B6JwmtM8fg3AwJjaKCV62zhX8CtLgrK6um has 2

Is that ok? Shouldn't there be a unique address generated for each masternode? It seems like the payments would get spread out too much otherwise, due to the algorithm that processes payments not being able to tell that these are distinct if it utilizes the BBP address rather than the txid for payment decisions (but I admit, I haven't checked that code out). Anybody know how that works?

Thats OK, because we pay by VIN not by address. The payment votes are tied to the VIN and the VIN is tied to the payment address.

They apparently set them up without creating multiple addresses (like the guide shows).

bible_pay

full member

Activity: 1176

Merit: 215

Jesus is the King of Kings and Lord of Lords

Quote from: lilaj4de on May 30, 2018, 08:02:40 PM

Quote from: sunk818 on May 30, 2018, 07:46:02 PM

I got another PoDC payment at 2:05 and now again at 17:41. 15 hour difference. Looks like BBP day was shortened today. Maybe due to PoW difficulty or lack of PoDC payment prior?

To participate in these distributions, should have a minimum value of biblePay? Or does the algorithm randomly distribute the Biblepay?

We assess your magnitude based on your BOINC RAC. We pay daily in our research superblock. So it is actually a relative daily distribution.

jaapgvk

full member

Activity: 574

Merit: 104

Quote from: thesnat21 on May 31, 2018, 08:44:52 AM

Welp I was wrong

From the code, this appears to be the grids.

From this you could actually have less than 1 per bbp for large quantities since its >= 4%

4-10% = 10%
11-20% = 20%
21-30% = 30%
31-40% = 40%
41-50% = 50%
51-60% = 60%
61-70% = 70%
71-80% = 80%
81-90% = 90%
91-100% = 100%

I think trying to break it down to BBP makes it a bit more confusing than it needs to be.

simple formula to calculate %:

(RAC * 20) / Stake BBP, and basically round up to the next 10%

Code:

	if (dPercent >= 4 && dPercent <= 10) 
	{
		dOut = 10;
	}
	else if (dPercent > 10 && dPercent <= 20)
	{
		dOut = 20;
	}
	else if (dPercent > 20 && dPercent <= 30)
	{
		dOut = 30;
	}
	else if (dPercent > 30 && dPercent <= 40)
	{
		dOut = 40;
	}
	else if (dPercent > 40 && dPercent <= 50)
	{
		dOut = 50;
	}
	else if (dPercent > 50 && dPercent <= 60)
	{
		dOut = 60;
	}
	else if (dPercent > 60 && dPercent <= 70)
	{
		dOut = 70;
	}
	else if (dPercent > 70 && dPercent <= 80)
	{
		dOut = 80;
	}
	else if (dPercent > 80 && dPercent <= 90)
	{
		dOut = 90;
	}
	else if (dPercent > 90)
	{
		dOut = 100;
	}
	else
	{
		dOut = 0;
	}
	return dOut;

Thanks for looking into this.

I made the last chart on http://wiki.biblepay.org/Distributed_Computing, but I'm not an expert with numbers, so if you think there is a better way to represent the staking requirements then please be my guest. The wiki is open for anyone to contribute

slovakia

full member

Activity: 770

Merit: 100

explorers working bad
https://www.biblepay-central.org/en/ working bad

any progress with this fix?

thesnat21

jr. member

Activity: 490

Merit: 4

Welp I was wrong

From the code, this appears to be the grids.

From this you could actually have less than 1 per bbp for large quantities since its >= 4%

4-10% = 10%
11-20% = 20%
21-30% = 30%
31-40% = 40%
41-50% = 50%
51-60% = 60%
61-70% = 70%
71-80% = 80%
81-90% = 90%
91-100% = 100%

I think trying to break it down to BBP makes it a bit more confusing than it needs to be.

simple formula to calculate %:

(RAC * 20) / Stake BBP, and basically round up to the next 10%

Code:

	if (dPercent >= 4 && dPercent <= 10) 
	{
		dOut = 10;
	}
	else if (dPercent > 10 && dPercent <= 20)
	{
		dOut = 20;
	}
	else if (dPercent > 20 && dPercent <= 30)
	{
		dOut = 30;
	}
	else if (dPercent > 30 && dPercent <= 40)
	{
		dOut = 40;
	}
	else if (dPercent > 40 && dPercent <= 50)
	{
		dOut = 50;
	}
	else if (dPercent > 50 && dPercent <= 60)
	{
		dOut = 60;
	}
	else if (dPercent > 60 && dPercent <= 70)
	{
		dOut = 70;
	}
	else if (dPercent > 70 && dPercent <= 80)
	{
		dOut = 80;
	}
	else if (dPercent > 80 && dPercent <= 90)
	{
		dOut = 90;
	}
	else if (dPercent > 90)
	{
		dOut = 100;
	}
	else
	{
		dOut = 0;
	}
	return dOut;

Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 451. (Read 243386 times)