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

BBP Pool:

https://www.bbppool.com/


I believe this is our method for brand new users who have no UTXO stake.

https://biblepay.ovh/
https://explorer.biblepay-central.org/ (though the accuracy is suspect)

I stumbled upon this article and wanted to share it "just in case":

https://coinvigilance.com/uquid-withdrawal-problems-possible-scam-alert-review/

Hello guys, just 2 quick questions.

1. The windows wallet (1161) constantly keeps itself unlocked after performing PODC updates. That somehow worries me a bit, I think this was an issue a couple of weeks (or months) ago and already had been fixed, but now it's back.

2. Is explorer.biblepay.org our current (only working) explorer? Because at least for my addresses it shows a lot of wrong transactions and completely wrong overall stats (total sent/received, current balance). For example my PODC address (BNetxsZfjyNfW73Kvsh5AYLHENpEHcR3qh) is shown to have a current balance of 8 million BBP (I never had anything close to this sum). The total sent/received is in the range of 2 billion BBP (). At least this could perhaps be explained by the PODC updates, although those do not show in the explorer.

They have ~11m bbp per cpid * 3 cpid's..

Yup. GRCpool added 10% RAC to Team RAC, so the blacklist is definitely gone. I saw a huge drop in daily PoDC payment.

200k RAC = 4M BBP. I don't know the daily figures, but I wouldn't surprised to see at least 10M BBP staked due the new participation by GRCPOOL.

Correct.

So Gridcoin as a team is no more blacklisted right ? We can get bbp and Gdc all together ?

I think we are OK in linux and mac, but windows is showing a quick window flash.  I can take care of the windows problem.

Will someone enter a github?

Thank you for checking it! This started a few versions ago, it was not there before.

I think you mean the background boincmd calls. We are currently using POSIX type call popen in Windows and Linux to shell execute, so they might have some weird behavior in windows. But I think I can replace them with Win32 shell command call to prevent this behavior.

I´ll check it.

As long as we can establish that there is no cheating in prod, then you can leave this message posted otherwise I vote to delete it since it is spreading FUD.

In windows, the shadow command prompts (they appear but no logging and messages) is a little unnerving. It can appear as malware like behaviour.

Oh OK, you were referring to the old POBH system last year- thanks.

So yes, I would not want to switch over to something that has any defects.

Trying to recall all the things we've been through: From July to September we were happy at first, and then when the diff skyrocketed, we tried to ensure PC's were mining by adding in some rules into the POBH that slowly increased the nonce over time (etc) - and then we were (slightly) exploited by the multi-wallet installs, and then finally the botnet (we think the Japan botnet), and then the upgrade problem (where the botnet refused to upgrade so we had to kick them off finally when the exchanges upgraded).

The BB2 address was and is still the orphan foundation wallet.  I don't remember any problems there; those coins were always liquidated every month for compassion.

But I agree, we definitely do not want to re-do any problems of the past.  The POG algorithm would have rewarded the givers by share weight, so I don't see the "same" problems being repeated again; however I am very cautious to jump and be a POG cheerleader unless it can be proven that it:  allows a 6 mil tithe cap fairly, and somehow slows down the ability for scripts to auto-tithe in an unfair way (IE take a higher proportion of tithes from the average person).

In the mean time, I'll go back to thinking about PODC early adoption also. 

Rob,
I send all from bug to the orphans, because its not a problem. We must work together...

We have still many bug, and in my opinion, better to refine than to constantly change.

Do you remember??

Quote from: bible_pay on October 01, 2017, 03:55:52 PM
Quote from: macko20 on October 01, 2017, 03:54:05 PM
BB2BwSbDCqCqNsfc7FgWFJn4sRgnUt4tsM is the Orphan Foundations wallet?
Yes, Happy labeled it labeled here:

http://biblepay.inspect.network/richlist

#39 on the list.

from 10k bug.

Few coins doesn`t matter, important is that the pool is working propably.





Yes It was many coin, when I saw a bug, you was angry. 10k blocks it was... You are still angry, but you can change 100 times scripts, and it`s not a problem....

Be patient....

Interesting - I am not aware of heinous bugs.

Rob,
Before you start combining with the new script, show everyone that you can finish the old without bugs

Let me do some testing.

First of all, the pool idea was quite capable of paying exactly the owed and accrued amount - on time - and in a scalable way.  The only reason I added the uncertainty principle is to prevent gaming the system on a particular exact day when the pool is empty - say for instance no one tithed, to allow one small group to tithe for a sure profit (as the predictable payment system would have resulted in a certain profit).  So, we introduced a 1/410 chance of a single tithe being included in a payment block.

However, since we have 205 blocks per day, that does not mean the system is not predictable over a one week or one month span.  In contrast to solo mining, where you do not know that you will solve a block in one month.

So even though you make these pointed questions as a trap, the answer is that if investor A tithed 100 bbp once, they would only have a 50% (205/410) chance of being paid THAT DAY for the tithe.  However, if Investor B tithed 10 times over 10 days, they would have had 4100 chances of being paid and therefore would be paid approx 3 times (yes, this is not guaranteed in such a short example, but statistically after a month of 12,000 blocks, we are reaching a 99% certainty that one persistent tither would be paid).  Meaning that Investor B would receive 3 payments (on average) in only 10 days - each of a higher value (depending on which of the 10 tithes were chosen).  This effect means that the pool system does pay regularly over longer periods.

If a malicious actor floods the pool with smaller tithes, they get more frequent payments, but each tithe has only a 1/410 chance of being included, and as the wiki shows, smaller total payments pay less % than one large payment (since they lose out on the exponential weight).  Its not gaming because the primary question at the beginning of the day is : Will tithing be profitable or not?  The question is answered depending on how many tithes are in the pool.  

So yes, if you want to participate for 30 days, you would know with relative certainty if its worth tithing each time you tithe and over the long run your results would bear that out.  Its the same as our difficulty level.  If the Dash difficulty drops below a certain threshhold, x11 miners jump in to try to solve a block, and pools jump in, but there is no guarantee the block will be solved - but the profitability level was enough to prompt the pool to jump in.  

The only thing I agree with in your summary is the "amount" of coins that would be liquidated monthly.  I am concerned that the number of coins tithed to the orphan foundation for mining should not exceed a certain threshhold.  For example, maybe if we could cap that at 6 mil tithes per month, then this system wouldn't affect our mission (or stray from the fundamental percentages).  I don't like the idea of liquidating more than the allocated charity budget per month in coins that were originally designated for mining.