BGB

MEMBER
  • Content count

    44
  • Joined

  • Last visited

  • Days Won

    5

BGB last won the day on February 1

BGB had the most liked content!

2 Followers

About BGB

  • Rank
    Member

Profile Information

  • Country
    United States
  • Gender
    Male

Recent Profile Visitors

100 profile views
  1. test.grcpool.com is up and running with 20+ connections. i have another 15 windows nodes that have been up and working also.
  2. Is it me or has Einstein been removed from the whitelist? When I check the last superblock it appears to me it has been removed on the gridcoin client the pool is using. https://www.grcpool.com/project
  3. Something seems up I suppose. explainmagnitude doesn't show WCG for the pool client.
  4. Hi, I see a number of requests from various hosts with a number of different problems, some of these you may have already corrected.... In the most recent request from hosts to the pool: "terminal" is not authenticating correctly with the pool, this is likely a password error. "unitas" is not authenticating correctly with the pool, this is likely a password error. "slow" is authenticating, so it has the correct password in the client and looks like tn-grid is successfully attached "coresolo" is authenticating, so it has the correct password in the client and looks like tn-grid is successfully attached ... there of course are more hosts, the thing here is the ones with password problems, they should return back an an authorization error message I don't see any XML related errors on my end. However I do see a number of projects that are attached to the hosts with your personal accounts, That is okay (except I can see the keys), unless you wanted to research those projects with the pool. Then the projects need to be detached from your client first and then attached via the pool account manager. If you would like to discuss further, please feel free to email me at: admin@grcpool.com Thanks,
  5. If a second or more persons can be involved in this support, i'll throw my name in the hat. Is there anyone else out there that can fix these issues where the manual method is NOT working? I've been trying to reach RTM for several weeks, have posted in IRC, here (posts and PMs), reddit, elsewhere... the fact that there are SO MANY FORUMS involved is crazy. I do not feel like waiting months to regenerate a beacon and I have thousands of GRC waiting to be paid via POR. I put the brakes on all my machines because I figured I'd need to switch to a new account, but was then given hope, resumed research and now am losing hope again. Having no standardized support system and then the fact that only one person can apparently fix these issues makes it worse.
  6. Yup, I tried in conf and as an argument, no luck. I assume that the escrow for rain would need some parameters such as start time, end time, and project. Then it would be desirable to collect work completed only during the duration of the event for the award. I assume the current project rain uses magnitude for a project, but isn't limited to the event begin and end, which isn't ideal for events? I have noticed on gridcoinstatsu.eu CPIDs can be tied to GRC addresses. Would whatever methodology (assume it is something in neural net) be reliable enough to pay out rain based on it? So in other words, at the beginning of an event (and during for newcomers), the total work would be collected for team gridcoin researchers. Then at the end of the event, total work would be collected, then percentages would be calculated based on cpid with total work. Then payouts from the escrow would occur based on the percentages. Messaging/comment rules (or some other means) would need to be followed so pools could look at the transaction and determine where to send the award to. Did you try adding server=1 to the gridcoinresearch.conf file?
  7. I had started to work on this and make it part of the pool site, but I ran into a limitation regarding running multiple daemons on linux. It looks like I can't specify different -datadir (with listen=0) for different daemon instances. All daemon instances pull from the same datadir regardless of what is specified. Not sure if anybody else has seen this happen. However, windows seems to work as expected (but -server option doesn't work anymore). I can run the escrow wallet of course on the linux test box for example, but then need to setup apis for it, so it is more clunky that I wanted, but doable. I was actually thinking something like this recently. GRC needs an escrow service where projects can deposit funds and participants can be sure that the funds will get rained if conditions are met -- sort of like a reverse kickstarter. If you did it right, it could be a market where GRC BOINCers could go find projects offering whatever rates they're looking for, on top of the normal in-chain awards... If I had more time, I'd try to build this myself, but not likely to have that much time until late this year at the earliest.
  8. Researchers, I wanted to create an official thread for supporting grcpool.com. Feel free to also use the below methods to contact me for support... 1) facebook page: https://www.facebook.com/gridcoinpool/ (and good to follow for updates and pool information) 2) pool's email: admin@grcpool.com 3) sometimes the IRC as 'bgb': https://kiwiirc.com/client/irc.freenode.net:6667/#gridcoin Also just a couple quick bullet points about me: I started crunching on Seti@Home about 17 years ago before BOINC existed and haven't missed much crunching since then. I have been involved in cryptocurrency related projects for 5 years. I work full-time as a programmer (19 years) in the telecommunications industry.
  9. Hi, me too... I am having this problem since 28 March. Try to "execute beaconstatus" If no beacon exists, fully unlock your wallet and "execute advertisebeacon force" else you have to follow these instructions http://www.gridresearchcorp.com/gridcoin/DeleteBeaconInstructions.pdf and wait for RTMoney to get your beacon deleted as I do (the worst case scenario is to wait for 6 months to get your beacon deleted automatically ) After the upgrade I was seeing this problem. I fixed it by issuing a new beacon, then using beaconstatus to determine what public key it needed. Then going through conf backups to find a backup with that public key. Then updating the pub/priv key in the current conf file with the correct key pair. Then restart.
  10. It looks like we got the superblock and my test node beacons were accepted. Thanks for all that joined and helped out. Some clients looked like they were on a fork, so if you want to keep on test net, here is a current black hash: getblockhash 221744 : 7210e8b2fc8c7e92014331b0a75a3ff172e14fc2430fc488d678e0fde08b013d
  11. Hi, Is there something needed to get a superblock on testnet? Or is there just not enough hosts? I am running a few testnet clients. I have a few other connections and we are staking blocks and the chain is moving along, but there hasn't been a superblock since November. My main reason for this is I would like to have a fully functioning testnet pool in order for testing various things like apis, the voting, markets, or whatever comes along. I have a testnet pool setup, but of course until a superblock happens, I can't really do payouts etc... test.grcpool.com can be added as a testnet node
  12. I have received a couple inquiries about the pool working with Android, here is a short video on how to.
  13. I also went through these steps and verified it does work. I recorded it as I went through it. I'll voice over it early next week and put it out. Thanks for the info.
  14. I checked this out and see what you are saying, just seem three options available for account managers. I sent a note to the email listed for the app to see what kind of requirements or process might be needed to get it added. Thanks for bringing this up.