Topic: Gridcoin (GRC) - first coin utilizing BOINC - Official Thread - page 261. (Read 597344 times)

It's in my signature.
GAJVTf4JLxPwX8e3rq51jaJo2KMH6GrGDZ
Thank you anyway! My brain is waiting for programming queries 

Guys, if you are running Boinc, make sure to join team Gridcoin @ World Community Grid, the more working members we have, the higher we go in the rankings. You can add it alongside the other projects you are running.

Here is Team Gridcoin: http://www.worldcommunitygrid.org/team/viewTeamInfo.do?teamId=BBNGDQS832

Hey Slashka, post your grc address so we can send you some donations for your help.

Hi NobleBot,

Regarding the orphan block you found and "possible major flaw", don't worry -- you have to look at it from another perspective --  if you look at the larger pool statistics like burnsides pool for example (a scrypt mining pool) youll see quite a high stale rate, maybe 3% if I remember correctly.  It happens all the time, and makes you feel as though you have been cheated out of revenue but that's not the case, remember if you have 90 concurrent miners there is a high chance another miner can find the same solution.  The solution has to propogate the entire networks memory pool and the first client to write it to the chain wins-- you have to build in a 4% loss into your mining calculations-- also regarding integrity, the real analysis is what is actually contained in the official blocks on the net-- I get emails about people sending 50grc to each other  the grc always turns up somewhere; its either Not sent, or in a tx, and if you do a "getrawtransaction hexcode 1" you can see if the tx made it to the chain......  So the security is the same as litecoin-bitcoin.. but I do want to say, if we can ever integrate MySQL, we will then have the ability to query the transaction for you (along with every other Gridcoin user) and actually see confirms as they take place; etc; it would be excellent for auditing.  Right now, it is cumbersome to track all these things down.

Rob H.

Hi Grex,
You can build a Linux version if you look at the cryptsy thread on page 1 of this thread (the please add us to the exchange link) a guy named Roo posted the instructions for the build,
but please be aware that you cannot Mine on the latest Linux version since it does not have a CPUMiner-- its mainly there as a wallet for the exchanges etc.
Sergey is working on the CPUMiner now; but its a big project.

Thanks,
Rob H.

Hi Slashka,
Your running it in Wine in Ubuntu?  That's good to know; because our Linux guy is busy adding the cpuminer to the Linux version and Id like to give people some direction that have been left hanging.  Are you able to mine successfully using wine-Ubuntu?

Regarding programming, Ive been receiving a lot of volunteer e-mails to the contact address, which is great.  We had a project scheduled to port a thin client to Android.  I have a volunteer named "Lowkey Leesmith" who would like to start on that--- would you be interested in working on that with him?  PM me if your interested.  

Rob H.

That's nice! Don't think that I'm too intrusive, but contact me. I wanna help with development

Hi,

Don't worry, we'll fix the syncing issue first - MySQL would be a full 6 months out anyway, its such as drastic change.  I'm talking about replacing berkeleyDB altogether and moving to MySQL after it is provably working alongside berkeleyDB.

Regarding MySQL, first, we'll still have a memory pool for volatile transactions; that works fine; its used when someone buys a coffee with gridcoins and the tx is not part of a block.

Regarding scalability of MySQL don't worry about that, I have seen tables with 5 million rows,  with clustered indexes they work fine, and in this type of situation we're really only using the last 100 blocks at any given time; not a problem for an enterprise database to handle.  Not to mention we would have 30,000 copies of it all doing the work on each individual pc, so I think it would actually be more efficient than writing to locked files on the filesystem (ie the algos are already there to efficiently search for relevant data in contrast to searching the chain for data sequentially).

Regarding choosing MySQL, its free and strong enough to work without paying any royalties, and works cross platform.  It would allow database administrators who want to support gridcoin to get involved to write ansi-92 reports etc.

Rob H.

Yes its a great idea, Aysyr is keeping a wishlist of things (please add it Aysyr), and eventually we will make the block explorer allow clicking on txids' and we can add the boinc stats too.

I'm currently looking at the syncing issues first-- have observed that all of my non seed-nodes sync correctly -- but my seed node with over 100 connections has an issue every 12 hours; and cannot be resolved without deleting the blocks folder.  I am trying to find the root cause.  At this point, I'm going to make a feature that tells the wallet to delete 100 blocks before its last confirm and automatically resync, and hopefully if we release that feature the group will be able to tell me if that works without restarting the wallet.  If it does we may uncover the problem or build that in to the code to automatically execute that when it happens.  

I also have a suspicion that a large number of non gridcoin-qt nodes are connecting to the seed nodes; that would require a global port change; we'll try one thing at a time.

Thanks,
Rob H.

Hey, Rob. This is great news! But I'm afraid of using mysql. Why? Now all clients are stucked on loading block chains. The performance depends of hdd speed mostly. Though, in my opinion, it will fall with including database. May be a wrong comparison, but that's why all high load projects put popular query results in cache.

Hey guys,
Been extremely busy, lots of emails coming in to the contact address, and finishing up v1.0 of the integrated miner -- the wallet is still compatible with cgminer, reaper, guiminer and gridcoinminer however.

The integrated miner has a "sleep" function only designed to be used if we ever implement the network sleep algo allowing segments of the network to sleep; still being discussed on cryptocointalk; no resolution. 

Just as an FYI, the gridcoinminer was developed to sit out during a non-eligible hash block; the function is not turned on and still in the discussion phase.

Regarding future pools, since a detached pool could undermine the security of gridcoin obviously we don't want that, so for now, we are focusing on ways to make the current integrated pool robust enough to handle 1000 users.  Its scalable enough to do 100 as-is without a code change.  We have a plan that can allow it to scale to 1000 users by turning on the hourly wallet consolidation feature (requires a release) and I believe that will allow us to operate for a year or so as long as we keep growing.  In the longer term we would need something a little better (only necessary if we have more than 500 pool miners), and I personally think the answer is adding MySQL support to the coin -- with a database integrated into the coin, we could then do the cool things to this coin that would make it supportable from an IT standpoint and allow the larger features to be added; for example in the current state, its extremely hard to add new tables of data (such as guid-poolminer-payment-confirm) and a database like MySQL would allow us to do that and support the code.  So in summary, I think for pool mining over the next year:

1) Use the integrated miner until we reach 100 users (we are at 33 already)
2) Release a patched version of the wallet that switches to daily payouts, supporting up to 1000 users. 
3) Over the next year, add my-sql to the coin
4) After that is debugged, add pool mining to the database
5) Enjoy a stable, provable integrated pool with close to unlimited scalability and features

Rob Halford

No, you do not need boinc, you can use the wallet by itself. Did you get the latest version? If you want linux you have to contact Gridcoin, the developer, he will give you one.

Did you specifiy in gridcoin.conf where boinc is installed and the boinc data folder ?

I'm ready to write an exchange site in a couple of days, but all I need is a linux version of a gricdoind (daemon version), because I can not find what source are responsible for compiling it.

BTW, is it necessary to install boinc to use wallet only? Because I have no connections to network a long time

Ok,

I spent one day of mining on wrong blockchain as I didnt follow up this forum daily.
I want to thank to Aysyr who alert me about new client version.

But is it really that hard to add alert message to client:
"Caution, you are using old version. Update now!"


It is nice we have matrix-style wallet, but this feature will be much more practical.

Thanks for the reply, TribalBob.
I was referring to the feature Gridcoin developer Rob put in for the specific "cpumining" feature of Gridcoin. In another word, paying out GRC corresponding to the daily BOINCs earned. I think that is a very good way to award native BOINC workers.
So far I have only seen many 0.08 trickling out of wallets, not sure when there will be payout.

Gridcoin isn't really designed for cpu mining, for Gridcoin your cpu should be used for BOINC then you want to use your GPU for Gridcoin.

If you use your cpu for Gridcoin you will get reduced rewards as either your hashing speed will be reduced by BOINC or, if you decide not to run BOINC, you will only get 5 GRC for found blocks.

What is your cpu hashrate like...?

Do you guys know when "cpumining" starts to pay out GRC?
Have been cpumining for some time now.
Will be great to see the BOINC credits get accounted directly.

If you still have problems please paste the output of %appdata/roaming/Gridcoin/debug.log