Jump to content

Michael Goetz

MEMBER
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    3
  • Time Online

    2h 58m 54s

Michael Goetz last won the day on November 12

Michael Goetz had the most liked content!

Community Reputation

19 Good Reputation

1 Follower

About Michael Goetz

  • Rank
    Member

Recent Profile Visitors

72 profile views
  1. In theory, with some work, the pool cuold figure it out, and tell the users. But that's potentially a lot of work on their side. But that only solves half the problem. Telling the users is fine, but we also need to report the (larger) AP sequences, and most primes, to outside entities. That could in theory be done manually between our admins and the pool admin -- and, in fact, was done for a handful of large and significant primes found by the pool. But that can't use our automated prime reporting system, and simply is not scalable. For this to work, it would require significant programing on our end in addition to whatever were to happen on the pool side.
  2. You got it backwards. :) It's not that people *want* to be anonymous. When you are in a pool, you're anonymous whether you want to be or not. The BOINC project doesn't see you, it only sees the pool. If I don't know who you are, I can't name you as the discoverer. Yes, PrimeGrid does permit people to be anonymous if they want to be, but it's a very, very rare occurrence. Maybe one prime every couple of years is reported anonymously. It's not so much anonymity (which could be a good thing) as it is a complete, inadvertent, and unintentional loss of identity. Definitely not a good thing. 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. You guys were losing out by participating in the pool. You got your credit, and your Gridcoins, but you forfeited your discoveries. Finally, no, I don't consider anonymous discoveries to be any sort of threat. My concern is that you guys were missing out.
  3. That's a problem, yes, but that's nowhere close to the biggest problem with running GFNs (or LLR or AP27). Let's say a pool user found a prime. We don't know who the actual user is. We can't give them credit, either on our site or at T5K. So now we either need to report all those primes anonymously, or figure out a way to get that information from the grc pool administrator. Assuming that information is available, it's a lot of manual work for both us and the grc pool admin, or both sides having to write a lot of new code. It's far from "plug and play", and I'm sure you don't like the idea of the primes being anonymous and you not getting recognition for finding the prime. Chances are, even the prime finder would never know he/she found a prime. It's far from ideal. I much prefer to give people credit for finding primes. I don't like seeing them reported anonymously. Long tasks, high power, problems with prime reporting. All three of those are avoided when the pools run sieves. Is it ideal? I don't think so, but PrimeGrid didn't create the pools, and nobody asked us beforehand what problems it would cause. Running sieves solves those problems. (You're not the first pool, and, no, the earlier pools didn't ask us either and they had the same problems.) Real life example: AP Before you switched grc pool #1 to run just sieves, those AP sequences were discovered. Our server sends a PM to the user when you find an AP. The user is "grcpool", not the actual real life user. There's no way now to determine who actually discovered those AP sequences. I don't like that. Do you? Remember, you guys set the pool up. We had nothing at all to do with it. I wasn't even aware of those essentially anonymous AP discoveries until a few minutes ago.
  4. Individual users are free to run whatever they want. Pool *users* don't get to pick which tasks they run -- the pool *administrator* does that. When you join a pool, you cede control of what tasks you're running to whomever is running the pool. Some computers are not suited to some types of tasks, and some users may not want their computers running some types of tasks. For example, we have some very long tasks. If a user runs his computer only a few hours a day, and it's a very slow computer, he may put in months of computation, only to have the task time out and receive no credit (or grc). That's not in the user's best interest, and it's not in PrimeGrid's, either. With the pool, the user has no control over what tasks he gets, so he has no ability to avoid getting inappropriate tasks like that. This is why we tell pool administrators to select only the easiest tasks. It would be nice if our server could figure out how fast each individual host is, and then send it appropriate tasks, but that's much easier said than done and not really practical. PrimeGrid's possibly unique in that not only do we have a lot of different tasks, but they vary in length from minutes to weeks. We also have tasks that are more punishing on computers than any other software out there. It's literally the same code that overclockers use to stress test their computers. I wasn't kidding about the fans -- the power draw can be extreme and not everyone enjoys having their computer imitating an over-caffeinated hair dryer. With many BOINC projects, it doesn't matter a whole lot if you get task A or task B. At PrimeGrid, it matters a lot. Forcing people to run tasks that their computers can't handle, either because of their speed or hours of operation, would not be fair to them. If the pools ran the bigger tasks, that's what we would be doing. Forcing people to run the high powered tasks is equally unfair to those who don't choose to run them.
  5. It was just the grcpools, not Gridcoin itself, and it applies to all pools, not just yours. It's the same tasks we assign to new users who haven't selected their own tasks. These happen to be the tasks with the most credit. (Self explanatory.) They also are amongst our shortest tasks. (Important when there's a mix of everything from Skylake-X through Atom CPUs.) They are also the tasks that generate the least amount of heat. (Unexpectedly loud cooling fans tend to make people leave the pools and never come back.) This change was done in coordination with the grcpool administration. Actually, all I did was make a request. The pool administrator made the changes. Hate me if you wish for other things, but this I did because I felt it was in everyone's best interests. Yours were not the first pools, and we learned the hard way that assigning "all tasks" to pools doesn't work well.
  6. I would prefer that you funnel your requests and suggestions through the core devs. That's not, however, the only reason I did not respond to your suggestions: Gridcoin Poll: PrimeGrid Whitelist Poll Details for Gridcoin Poll PrimeGrid Whitelist Poll. Created 2018-10-30 17:47:44; Ends 2018-11-13; Running for 2 weeks We're not going to devote any time or resources to this if you're uncertain if you want to move forward.
  7. I did not mean to attack nor threaten anyone, but I am sorry if my words were interpreted as such. As it turned out, I had inadequately educated myself and therefore had some of the facts wrong. That is what I apologized for. I saw what I thought was a serious security flaw in the way Gridcoin operated, and was explaining that this was a much more serious threat than what you seemed to be concerned about. This was relevant to me because Gridcoin collectively was making requests of PrimeGrid and myself in the name of security. To me, this seemed ridiculous because there was what appeared to me to be a far more serious threat that you were ignoring. It seems we weren't really communicating very effectively! I'm glad we got that straightened out. I do have a question for you. I've been working behind the scenes with some of Gridcoin's developers for several weeks. You're not one of the people who have been in contact with me during this process. If you don't mind my asking, who are you, and what is your role here?
  8. Thanks, but there's no need to thank me. I was wrong and that was the least I could do.
  9. Yes, you may have me there -- I don't claim to understand the staking process as well as perhaps I should. Based upon reading the description, staking is a function of probability and time, correct? With enough patience to wait for the stakes to do whatever it is they do, wouldn't this work? If I'm wrong, then I do apologize. (And I'll do so on my forums as well.) Am I wrong about this?
  10. Seriously? I'm pointing out the flaws in the system. That's commendable in my book. The entire "cryptocurrency based on BOINC credit" paradym is fatally flawed because it demands that you place complete trust in people who have no vested interest in maintaining Gridcoin's integrity. Can you trust me? If we're talking reality and not hypothetically, yes, you can. But how do you know that I'm telling you the truth? The best reason to think I am indeed trustworthy is because I am talking about this openly. If I wanted to steal from you, I wouldn't say a word. You really don't have any way of knowing what's happening inside any of the other BOINC servers, however. Once you monetized BOINC credit, you created an incentive for anyone -- including admins -- to cheat. Don't try to blame me for the system you created.
  11. Nah, I think of myself as more of the "Get off my lawn!" type of irrational human. Unknown? Really? As I've said before, your system is not, and never again will be, permitted to have users' computers access our server (outside of the BOINC API), due to this having been used to launch a DDOS attack against PrimeGrid. Whether done through malice (which it obviously was not), or through incompetence (really the only other option) does not matter. It was done, and therefore it could happen again. You completely lack the credibility to insist it could not happen again by virtue of the undisputed fact that you let it happen once. That's why it was instantly shot down. It boggles the mind that you would think I -- or anyone else -- would have any other sort of response. Well, I suppose I could have told you to F off and that you'll never be allowed anywhere near PrimeGrid again, but I didn't. So keep your damn computers off my lawn. The three servers are fine. The barbarian hordes (that's a metaphor for the computers, not the people) stay outside the gates. Is it really so hard to understand the "why" here?
  12. It seems to me that the only ideas for improvements involve having multiple users' computers access our server outside of the BOINC framework, which is precisely what caused the DDOS. I will never allow that to happen. Repeatedly asking for it merely reminds me of when my kids were three years old. I didn't like having to repeatedly say no to the same question then, and I like it even less today. Was there some other suggestion that I'm forgetting? My memory's not as good as it once was, so perhaps there was something else.
  13. Forum posts aside, the ONLY real issue here is your request to have hundreds or thousands of computers read from our stats directory, even if it's for just a small file. Given that you've collectively demonstrated an utter lack of technical competence by allowing the DDOS attack to occur, there's no way I'm going to allow you to have multitudes of computers access the system for the purpose of gathering statistics again. It's unreasonable for you to ask for it. I've made it clear, more than once, that this is completely unacceptable to me, is never going to happen, and you should stop wasting your time and mine by asking for it. I don't care how it's phrased, or modified, or whatever: it's not going to happen. If that for some reason makes it impossible for you to continue to use PrimeGrid, then just say so, and we'll go our separate ways. If not, then you guys know what you need to do to get the interface working again. Get it done, turn it on, and everyone will be happy. You've had the credentials to access the stats for a couple of weeks now. Either way, this conversation is pointless, no? Either do it, or don't. The ball's in your court, and has been since the middle of September when I first notified you of the problem. I'm not standing in your way. Everyone else who needs the stats has had no trouble getting them. Despite my belligerent tone on this forum (which is due to the frustration of having to keep saying "NO!" to the same unreasonable request over and over again), I've pretty much bent over backwards to help get you going again. So what's it going to be? Are you in, or are you out?

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.