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

I am not seeing the same exact problem, but I booted up 1.1.2.6 on my desktop, saw the same error, unable to sign cpid.
Then I did this:
sendtoaddress your_bbp_address 1

This flushed my wallet and did not throw an error.

Then I did setgenerate true 7
Then I did getmininginfo, and now I have solutions.

So Im heat mining now, please try that.

If anyone else has any issues with this, let us know so we can debug this.


Checking the pool, now my shares are counting without an error.

I don't understand this obsession with PoW difficulty. Difficulty goes up and down to keep the average blocktime as close to 7 minutes as possible. Since network hashrate changes and time to produce an acceptable hash is not guaranteed, you will see fluctuation of blocktime and difficulty. Ideally, you want the smallest gap between min & max time between blocks but this not possible with proof-of-work algorithm.

In our case from the apple standpoint, I think we would be OK, because BOINC does the research (and that activity should be construed as research not mining) but either way, the mother process BOINC, starts the threads for the research, while MIP's mobile wallet acts as a block acceptor and wallet.

But the main show stopper with running boinc on the iphone is no project supports the proprietary apple processor so boinc only works on the mac currently.  However this scenario could come up on the samsung galaxy, and we have a couple beta testers running biblepay-android and boinc currently on that device although I realize google doesnt have the clause yet.

Thanks for the post and the links.  So from what I can see, in both instances of the cheating that went on in those projects in that community, the user took advantage of an attack vector in which a vulnerability existed on the specific boinc project's server side, in the validation process, which made it possible to cheat on the actual result submission (IE it fooled the server into accepting the result of the workunit).  Another words they studied the traffic that is posted by boinc that allows the work unit to be solved and falsified it.  Note that there is no example of cheating outside of those few projects.  (Thats partially why we picked Rosetta originally, it was partially discussed in the swongle discussions when we were in testnet with cancer mining-  Part of the due diligence was to find a project that would be extremely hard if not impossible to cheat.  This is because if you look at the manual from Rosetta commons, the work you are doing is so complicated (it requires a 3mb database on the client side to refer to), with 300 scientists on the back end, I don't think its possible to falsify a low energy 'result' without doing more effort than the client does to compute the low energy result.  Also in both cases of the cheating note that the gridcoin user diluted their own project compensation - another words a report could have been written that showed a discrepency in task-turnaround/cobblestone-work, picking up the bad user.  In that case if that happened here we would have to disable the project and regroup.

As far as adding other projects, I feel we should stay focused with what we have now - these projects are related to our healing aspect (we picked Rosetta because it was based on potentially curing cancer), and WCG with their AIDS research.  Although I'm interested in using clock cycles for the benefit of humanity, I'm not interested in expanding our mining side into a volunteer computing platform, primarily because I would rather support a high quality project and maintain the healing aspect or facet of biblepay.  We have a lot of things to do on the roadmap, and one behind the scenes is investigating partners in the financial sector that also have some options for us in replacing proof of work with other cool cutting edge ideas (like analyzing financial markets etc).  

Apple announced changes to its policies to disallow mining on their mobile devices inside an app.

While this is largely targeted against scammy devs that build background mining into their apps, this clause concerned me:
3.1.5 (b) (ii) Mining: Apps may not mine for cryptocurrencies unless the processing is performed off device (e.g. cloud-based mining).

Google might take a very similar stance; if this is the direction things are moving, how do we see this affecting our goal of allowing unbanked mining on phones for people in remote areas without computers? It would be a real shame to lose that feature.

I cannot really tell you how to do it as I'm not that fluent in the workings of crypto when looking under the hood. However, I would strongly encourage the devs to really try to lock down ways to mitigate cheaters better than Gridcoin has done.

Collatz had to completely rebuild their site/servers/etc... because at least one Gridcoin user was cheating on a large scale  under one of their pools.
https://boinc.thesonntags.com/collatz/forum_thread.php?id=15#190
The responses from the Gridcoin team did not sit well with the community as it basically came down to telling the community to fix their projects and to not tell Gridcoin how to run theirs. Science was indeed affected and has to be re-ran. This event was the straw that broke the camels back and essentially caused Gridcoin to be banned from the Annual Pentathlon which is the largest competition in the BOINC world amongst teams.

Gridcoin users basically had coin stolen from them because of the cheater getting rewarded. I do not know if they ever resolved any of it as I don't follow their threads. Collatz lost the old forums that had a lot of the details in them.

And it appears that a possible cheater has appeared yet again at another BOINC project - http://gene.disi.unitn.it/test/forum_thread.php?id=216#1325

On a positive note, have you guys considered possibly adding GPUGrid to your list of projects? http://www.gpugrid.net/

I would be pushing to be late on the mandatory for June and wait for it - if it were not for our June 26th cascading superblock bug that gives us a black eye.

Anyway there is also the possibility that we release the token as a leisure - because exchanges don't need the token.  I'm focusing on this plan for now.  In this way we might be able to have our mandatory before the superblock bug hits, but it's already the 12th, and we need to test for a couple weeks and also give the exchanges 10 days notice to upgrade, so we might not make it anyway.  Let's see how testnet goes.