Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  • Time Online

    22h 35m 26s

dblanch256 last won the day on November 10

dblanch256 had the most liked content!

Community Reputation

146 Excellent Reputation

About dblanch256

  • Rank
    Active Member

Personal Information

  • Gender
  • Location
    New Jersey
  • Country
    United States

Donation Wallet Addresses

  • Gridcoin GRC Address


  • Operating System
    Windows 10
  • Processor
  • RAM

Recent Profile Visitors

1,452 profile views
  1. What would happen if I had two versions of my wallet running simultaneously on different machines? I'm assuming "nothing good", but I'm curious.
  2. @Michael Goetz wrote: Those APs that were found are not anonymous by design. Someone found them, but all I know is that someone in grcpool found each one, and neither my system nor your system has any record of who found what. Yet I see what appear to be detailed host stats in BAM including credits and RAC by host. Does this mean that individual hosts are visible to projects? IOW, pool membership aside, if I found a prime as a "regular user", would your project know which one of my machines returned the winning result? If so, solving the "pool anonymity" problem would seem to require little more than matching hosts to users--something the the project side might be unable to do, but perhaps the pool side could--at least in theory. Or is there still a broken link in my reasoning?
  3. THE IMPACT OF TRADING VERSUS HOARDING In a recent poll, the vast majority of respondents said "I don't sell my GRC". Yet it would appear that at least some people do--in significant quantities (15k at a time): Someone else claimed recently that "brisk trading is essential to any coin's success". I wouldn't expect GRC to be immune from pure speculation, but I'm wondering which activity (hoard or trade) contributes more to the coin's ultimate success? Moreover, is this even a well-framed comparison? Perhaps I'm just imagining a conflict were none exists ...
  4. Bogus account.  Content removed by SysAdmin.

  5. Bogus account.  Content removed by SysAdmin.

  6. Bogus account.  Content removed by SysAdmin.

  7. Bogus account.  Content removed by SysAdmin.

  8. Bogus account.  Removed by sysadmin.

  9. First, thank you both for taking the time to respond! I really appreciate it. OK, I see my a major mistake in my mental model now which Michael mentioned it in a prior post. I had thought the pool was only functioning as a "pass-through" (e.g. a big team) was therefore not filtering tasks but only grouping credit into team stats. As I noted before, prior to joining the pool, SETI was able to react to me as collection of hosts each with differing capabilities. It didn't seem to care that I was also a member of a team. For me that represented optimal behavior--I got a mixture of task sizes and was free to run whatever sizes I wanted. When you say short GFN tasks yield very little credit I'd imagine that some of this could be explained by short tasks having an increased transport/overhead-to-processing ratio. That effect wouldn't be unique to any particular project. I read somewhere that BOINC (or was it a single project?) took the reported processing times from multiple users for each task and assigned credit based on the lowest reported time. The incentive for redundantly assigning tasks was a defense not only against cheating, but also against innocent mistakes resulting in corruption of the result. More generally, I'm trying to understand to what extent does BOINC enforce ground rules, versus simply providing a generic toolkit from which project designers are free to use in any manner they wish. For example, if I created the "DaveWorld" project, I assume I would be allowed to: (1) Define the objectives and scope of the research. (2) Award any type and number of badges I wished. (3) Orchestrate special contests. For the sake of BOINC and its own reputation, common sense suggests I would not be allowed to: (1) Bait the RAC Hounds by offering x10 credit of other projects for comparable work. (2) Refuse participation to any individual or team based personal prejudice. (3) Manipulate the credit model to discriminate against any sub-group of users, teams, pools or hosts (see (2)). (4) Install special back doors to enable only my close friends to rack up outrageously high RAC/credit totals (see (2) and (3)). (5) Downplay (or even ignore) basic task security if I regard the cost of a few fake results as an acceptable price to pay for x2 or better productivity gain. Did I get these right? Did I miss any significant weakness? I don't think the pool itself seeks user-anonymity--because they publicly publish user stats. More your likely that this problem is a byproduct of basing their work on CPIDs in order to coordinate with both BOINC and the Gridcoin wallet. To credit real users, as you say, sounds like not only more work for you, but also for our pool admin. I think you have a valid concern. Our admin could probably identify the user if asked, but as far as I know there is no automation to support that. Well there will always be some people who demand anonymity, and won't participate (in anything) without it. Does PrimeGrid ban them? Seems to me if they don't want the credit, they shouldn't get the credit. I'm surprised that bothers you. People have turned down being Knighted, forgone credit for charities and even declined Nobel Prizes. Lastly (I can't remember) do you give give credit to their real name "Ronald P. Hedgefund III" or their user name (BigusDickus)? If the former, I tend to agree. If the latter, I don't see it as much of a loss to anybody. I suspect nobody knew exactly "what problems it would cause". Again, I'm mainly interested issues, as identified by PrimeGrid from which we should be learning as we plot our future development. My own experience with PrimeGrid was, prior to The Rift, uniformly positive and definitely a cut above that with other projects. PG was better run, had more work units, and seemed extremely will suited to the BOINC model. So when this partnership "blew up" I was both personally frustrated and concerned more broadly for how similar issues might manifest in other projects. That remains my core concern. To quote the Dalai Lama, "When you lose, don't lose the lesson." In your experience, are anonymous results are more suspect? I could certainly support some level of resistance based on that concern. But I don't know whether that's a general concern shared by other BOINC projects or not. Interesting. Again, if you think it's "just wrong" for no real person to claim a co-credit, I'd point out that in other walks of life people do it all the time (generally without resentment from the beneficiaries). For example, when was the last time you heard a hospital administrator say "I'm proud to announce we received 12 million dollars to today. Unfortunately, the chicken-shit donor refuses be identified so we have no idea what name to put on the new leukemia wing." [I'm getting a bit fried--if you couldn't tell. I should really go now. But I repeat my thanks to both of you for clearing up much of my initial confusion over this.] DISCLAIMER: I'm not qualified or sanctioned to speak officially for Gridcoin. My views are strictly my own. My objective is simply to learn as much as possible from all of the players involved, whose valued time I fully appreciate and whose input I'm sincerely grateful to have.
  10. It was just the grcpools, not Gridcoin itself ... If I truly mischaracterized you policy as discrimination when it wasn't, then I certainly do apologize. Frankly, I'm still trying to wrap my head around it. Based on very limited experience with SETI, I had assumed that all BOINC projects were "user-blind" with respect to task delegation. If they aren't, it potentially undermines the whole point of assigning credit and forming teams in the first place. That said, I don't want or need projects to be host-blind. I think that serving tasks which are best suited to each host is a worthwhile feature. SETI must have automated it because the project would initially feed me a mixture of cuda42 and cuda50 jobs just long enough to determine which ran the best on my hardware. Furthermore, the mix would shift whenever I made hardware upgrades. I never questioned or took offense to it because it seemed logical, and to our mutual benefit. So if that's all you're doing, I don't have an issue with it. But I'm not sure what distinction you're making between teams and pools. Are they not both merely collections of individuals? I didn't realize you coordinated task types through our pool administrator. What about being in a pool necessitates this? Why not let the users decide for themselves what task types to run? Is that not feasible? I don't buy the "loud fan" argument because it's too general a characterization of the user base. Some of us prefer loud fans if that's what it takes to generate more output. If you can tell me in simple terms why interacting with our pool required you (and our admin) to predetermine task types, I'd really appreciate it. [Meanwhile, I'll try to get some clarification of same on our side.] Finally, there is the matter of tone and maybe semantic confusion. It did not go over well with us to be informed that we had mounted a "DoS attack" on your project. I think I know what you meant, but that's not what you said. The word "attack" implies a deliberate attempt to sabotage your enterprise. Not that it might not have appeared as such, but by the time you wrote to us you clearly knew better. Maybe we should have apologized for scaring you (not sarcastic--this is me trying to walk a mile in your shoes). Obviously that was not our intent but that doesn't mean it didn't happen. But when you followed up with "many of us don't want you in our club anyway" that was the beginning of the end as far as we were concerned. C'mon--as a SETI member, I didn't want SETI.USA either (or any other goliath team) because all they did is make my contribution look smaller by comparison. [But I eventually got over it.] OK, now for a final attempt at some balance. We need BOINC projects, but not necessarily yours. You need contributors, but possibly not ones with unique requirements like us. You're concerned about cheating, but so are we--for different reasons, but to an equally passionate degree. I give you credit for admitting that cheating was present in projects long before we came along. Aren't we (as the larger community) more likely to discover cheaters than you? After all, there are thousands of us who following your project and arguably have more to lose than you do from cheating. Again, I'm not a Gridcoin admin, developer or even close, so please look to others in our organization who can speak officially because I can't. "I just know what I read in the papers--er, forums." I think you've over-estimated us as a threat, but I think we overestimated our value to you (hubris?) If I were you and charged with keeping the wheels turning, I'd seriously consider trading a quarter of my user base for some peace of mind too. You own user poll seems to echo that sentiment, although I didn't see a summary. Did your poll include an actual yea-or-nea tally? With respect to troubled relationships in general, it is often the case the neither party is to blame. More likely it is simply a "bad match" of goals and priorities. You have yours, we have ours. I see now that we (or at least I) misconstrued several of the statements you initially made due to not having the "inside track" on all of this. I both regret and apologize for that. But I did come away from this with a much better personal understanding of the larger issues herein, and I thank both you and our own admin for that. -- Dave "Sex without love is an empty experience. But as empty experiences go, it's one of the best!" -- Woody Allen
  11. Good point. There was also a separate charge for currency conversion. What would you recommend as an alternative?
  12. THE PURSUIT OF EQUITABLE DISTRIBUTION FOR BOINC CREDIT Like many of you, I participated in BOINC before there was Gridcoin. Actually, before there was BOINC. I worked SETI tasks, period. I was attracted by the revolutionary idea that idle PCs could be put to better use, and sensed it had enormous future potential. Evidently Berkeley thought so too. They separated the monolithic SETI project into an application layer and a generic transport layer. That transport substrate was named BOINC, and opened the door to run a multitude of Embarrassingly Parallel Programs (EPPs). For that reason I regard BOINC as even more disruptive than SETI--and that's saying something. But even with the arrival of dozens of new projects, I stuck with SETI. It was familiar, and I enjoyed racking up more credits than 75% of the countries on this planet. Then one day something odd happened. Providing only a fuzzy explanation concerning "other projects", SETI RAC was radically reduced--across the board. From what I could tell, this was an attempt to discourage a new breed of member--the RAC Hound. RAC Hounds didn't care which projects they supported, they were looking to maximize their RAC (and hence total credit) and were steadily migrating to projects which awarded the most credit for the least work. Of course, this is a simplification but you get the idea. So the sudden reduction I saw in my SETI credit was part of a larger effort to "normalize" credit assignment among all BOINC projects. But I'm not convinced that effort was entirely successful. When I joined Gridcoin I began to experiment. I quickly realized that my hardware was simply a better fit for some projects than for others. I realized that the very concept of "equal credit for equal work" was trickier than I had at first thought. I still believe that some form of credit for proportion work is fair. I'd be very disappointed if a BOINC project gave credit for mere "hours" of work regardless if the time was from a smartphone or a Cray. And I do think it's fair that folks with better floating point resources earn more for projects which rely heavily on those types of calculations. That said, I really don't know if BOINC has continued in it's quest to level the field. Judging only from the grcpool data, there are still wild variations in assigned credit among white-listed projects. The good news is that Gridcoin assigns a fixed amount of magnitude over the entire white-listed project set which acts as a counterbalance to everybody rushing to a single "fat" project. Still, I wonder if BOINC management, such as it is, has any say over how individual projects choose to award credit. Gridcoin aside, I can imagine a scenario within BOINC where hyper-inflation could erupt as each projects seeks to expand their member base by offering ever-higher credit. Thankfully, there will always be BOINC members who put substance over style. They prefer projects whose work they believe in, regardless of what they "pay". I suspect that describes many of us in Gridcoin. But I still wonder how free (or not) each BOINC project is to "mint its own credits" without regard to any external standard. Your view? Any and all comments welcome.
  13. Well, I'm seeing the results of using it now, and I view it as solving a major problem--little or no incentive to run a wallet more than occasionally to collect a reward. As more of a minnow than a whale, I rely on DPoR for 98% of my income. Contrary to other claims, the wallet is not a "light process" on my machine. It occupies a 1 GB of my memory and services 40-50 network connections, both of which cut into my production rate. Prior to this change, it was very tempting to do what so many larger earners were doing--fire up the wallet only long enough to claim rewards. Now, with the 4.0 version, I'm no longer conflicted. I earn a steady 10 GRC (even in the pool) by keeping my wallet up, which I think was the motive here. Thank you for incentivizing the desired behavior. This solution is clearly superior to simply expecting people to "do the right thing--even if it hurts". I think the elevated network weight I'm seeing has already validated this change.
  14. Perhaps (actually a nifty tongue-in-cheek response). Still, I think we could do without loaded language like "stupid". It sounds arrogant. I'm with you. Do we have a target date for DWP? I'm still reeling from the PrimGrid fiasco. You unloaded on them pretty good, but IMHO they deserved every word of it. Claiming they had a "DOS attack" even after they clearly knew better means either (1) They don't know what the phrase means, or (2) We were talking to the wrong guy, or (3) Their user base genuinely resented us contributing more than their top 2nd through 8th teams. I'm still burned by the suggestion that they gave us "second rate jobs" which I took to mean that by "sieving" full time we were merely laying the groundwork for other teams to actually find primes. If this is actual "task discrimination by team" that alone makes them disreputable in my book. Quick guess. From the standpoint of any BOINC project, we are like the flea who thinks he owns the dog. Yes we are a top contributor to most projects we join, so you would think we have some clout. But looking for "the lessons" which might be extracted from the PrimeGrid experience, I see the potential for similar rebuttal from other projects who might see our "reasonable requirements" as just one more headache for themselves. I don't doubt the veracity of your suggestions. But I'm trying to envision a broad approach to all BOINC projects so that in the future we won't have to fight these battles one project at a time. I assume you agree--at least in principle. Again, sounds really good. Do we have a timeline for this? It would be nice to "have this in our pocket" before we even join new projects. Does any precedent exist from other blockchain enterprise? I assume we're not the first to face this issue. For example, it's not like Bitcoin is going to bow to my request that my transaction history be removed. [I could be waiting for a long time for that to happen.] Is this law targeting only specific kinds of "personal data" (e.g. email addresses, CPIDs, etc)? Does it even matter whether the aforementioned "personal data" is encrypted? Access seems to apply at a general level (they do, or they don't). But as I think we discovered with PrimeGrid, when the access is both big and bundled, we leave ourselves open to accusations of assault on servers. I think maybe you had noted that we might not really need as much as we were sucking down from them. If true, that seems worth changing before future projects have a chance to resent it. I thought BOINC's recommend approach to cheating was to use redundant task distribution. I know that BOINC itself supports it, and it sounds pretty bulletproof to me. I assume it's up to each project whether or not to use this feature since it dilutes productivity. Also, I don't know if every project places equal emphasis on defeating cheats. PrimeGrid might be an extreme example by suggesting that one bad result could invalidate years of work. [Yeah, right.] Well, I've always been interesting in prime numbers. Maybe I could start a new BOINC project for that--NonDickPrimeFinders? 😉 That would be easier for me to understand if I knew the trade-off costs and future risk. For example, what if the US were to adopt similar measures in the near future? Without a pre-emptive plan, how vulnerable would we be then? If there's a reasonable way to "get out in front of this problem" I'd definitely support it. Nicely delineated! Thank you. Could you please give me a rough idea of what we require of them to "apply for whitelist status"? I had naively assumed that we just bestowed that on them. I thought they simply had to qualify for it--I didn't realize they had to apply for it. Again, I'm trying to see it from their point of view and what factors might incline them to ask "why should we bother"? Of course, we dangle the prospect of free help in front of them. You would think that would be enough, right? But if we learned anything from the PG fiasco, I think it was that not every project is seduced by that alone--particularly when, from their standpoint, we have "special requirements" which they perceive as simply adding to their administrative workload. [I'm not even going to raise the "jealousy issue" which was represented prominently in their wacky user poll.] Meanwhile, I focus on helping new members as part of a small group called The Shepherds. Together we provide the best initial support possible (orientation and starter coins) to folks who simply need an initial toe-hold. Many of our "alumni" have leveraged our help to become major players, and in turn have given back to others even more help than they first received from us. I find that very encouraging. Let me conclude with gratitude that we (you) are seriously exploring the above issues. I have reaped great personal satisfaction from being a member of this community and this forum which is only possible because of people like you. I have no misconceptions about being able to debate on your level, but I'm eager like to learn as much as I can. Thank you for your time and consideration! -- Dave
  15. Please forgive my ignorance, but could somebody please tell me who (or what) this is? User: CharityEngine1 This page shows research Gridcoin DPoR Reward, PoS Interest and Transactions History with Boinc CPID 14c2130aabb4176a0d3351cd136bbaa4 Here you can view some estimated numbers on reward, etc. Below is a Transaction History related to the connected Addresses. User Details Beacon Status: advertised about 9 hours ago @ 1425358 Neural Network Share: 15.04% Estimated Minted/Day: 4,756.02 GRC Time Since Last Reward: 3 minutes, 48 seconds ago Estimated Research Owed: 12.55 GRC

Cryptocurrenytalk Logo


News, information, and discussions about cryptocurrencies, blockchains, technology, and events. Blockchaintalk is your source for advice on what to mine, technical details, new launch announcements, and advice from trusted members of the community. Cryptocurrencytalk is your source for everything crypto. We love discussing the world of cryptocurrencies.



Important Information

By using CRYPTOCURRENCYTALK.COM, you agree to our Terms of Use.