Topic: 🌟🎲🌟 MoneyPot.com - page 35. (Read 119056 times)

JPR I literally just stood up for you and came to aid in your defense. I said I didn't understand his reasoning of why he was attacked / hacked and I verified that your script is not causing the hash issue. Notice nothing in there did I mention anything of you taking a 20% cut from jackpot winners right off the top.

Regarding your hash errors, I personally told you on numerous occasions how to fix the issues on your site. Additionally, I explained to you that we were working on a correction to the issue on our side as well.

At the end of the day MoneyPot is merely a service provider. It is up to YOU, the application owner to design and develop YOUR applications. You need to hire developers and stop relying on others to fix your application issues.  I understand you may have trust issues, and thats fine. Im happy to review your developers work to make sure there is nothing shady in there, but we at MoneyPot will NOT build your application.

You really need to stop bitting the hand that feeds you...

Additionally, I wouldn't view Bit Exo as a competitor. We are a family. A referral on one application could easily turn into a user on another. You should know that.

ok if you understand his reasoning then please explain who would have an advantage if our users will not win and are hindered to win by a loser bot?
we ?
Moneypot?
all other apps who had hash errors like bit exo?

as far as I know Jroc posted in his thread he fixed the invalid hash error and he was so kind to help us to fix the invalid hash error for one of our games just to test if the fix works and only then to apply it to all our other games. no one from MP helped us to get rid of this annoying invalid hash error

BIG THANK YOU to a competitor owner and coder who took the time to give us a fix.
Hats off JROC the owner of Bit Exo

I didnt quite understand his reasoning myself. Just offered a solution and reasoning to why he could be experiencing hash errors.

So, you believe that even with a hash error, you may have had a bot betting unknowingly for you if two or more browsers were running?
(Of course you would have had to had activated them, so you would have known, but the thought is you were cheated out of bets?)
Little confused on the thought of what might be happening.

My main confusion in reading everything is how you thought you were cheated when you believe you were hacked via router or other method.
Was a wallet taken or remote malware installed (cryptolocker)?  You mentioned screen shots - Were you taking screen shots or you believe a hacker was taking screen shots.

You mentioned why it would have been a coincidence.  Easy.... A hacker having installed a JRAT isn't going after your machine instantly.  He is waiting/watching for you to be idle or in the background searching for wallet.dat files and logging your signins with websites.  Once he see something (money), he goes after it.  A hacker could have been in your system long before you lost anything and once he got what he wanted, he started messing with you (closing files, deleting, moving the screen, opening your CDRom drive.)

I am sure you ran fulls scans on the computer by now and fixed the hacked router (password / firmware / etc).

I have looked at JPR's code. There isn't anything shady in there regarding cookies / sessions. He isn't preventing anyone from hitting the jackpot as just last week there where 3 separate occurrences, one with a completely new user.

JPR's application is handled completely in the front end, so it lacks the basic ability to control state outside of a browser session.

Cookies, Sessions, and Flashes

Cookies, Sessions and Flashes are three special objects that Rails 4 gives you which each behave a lot like hashes. They are used to persist data between requests, whether until just the next request, until the browser is closed, or until a specified expiration has been reached. In addition to different temporal concerns, they each solve slightly different use cases, covered below.

Cookies
Cookies are key-value data pairs that are stored in the user's browser until they reach their specified expiration date. They can be used for pretty much anything, most commonly to "bookmark" the user's place in a web page if she gets disconnected or to store simple site display preferences. You could also store shopping cart information or even passwords but that would be a bad idea -- you shouldn't store anything in regular browser cookies that needs to either be secure or persisted across browser sessions. It's too easy for users to clear their cache and/or steal/manipulate unsecured cookies.

To work with cookies, Rails gives you access to a special hash called cookies, where each key-value pair is stored as a separate cookie on the user's browser. If you were to save cookies[:hair-color] = "blonde", you'd be able to pull up your browser's developer tools and see a cookie on the user's browser that has a key of hair-color and a value of blonde. Delete it using cookies.delete(:hair-color).

With each new request to your server, the browser will send along all the cookies and you can access them in your controllers and views like a normal hash. You can also set their expiration dates, for example using syntax like cookies[:name] = { value: "cookies YUM", expires: Time.now + 3600}.

upon the cookie expiring which was set to 3 mins i believe on his site at the time! could one of these options of been possible with such code?
https://github.com/ScottHamper/Cookies/blob/fb16989d25cb2631f9065ff3c8de049b53bee02b/src/cookies.js
cause if thats the case what do we do from here?

investment looks good so far but i have there really little money.. im worried to put more now

So it was possible that one or more tabs could have been auto betting with such hash activating without the bot stopping?

The hash error is not explicitly caused by JPR. The hash error is a result of the API and the way an application handles sessions and API calls. Each session is assigned a hash in the API. When create a browser tab, the possibility exists where it will overwrite the other hash creation. This can be mitigating by an app owner if they explicitly check each has before a bet and generate another one.

There is another example of where this may happen, though I do not think it relates to this particular case. Sometimes a user may experience an invalid hash error if an APP owner returns a response to the user before the full API process has had time to process. Generally it happens in sequential rapid bets. We are working on a solution to this issue in V2.

Recently we have had a spike of hash errors and we are working on increasing our applications throughput. If you have any questions, do not hesitate to reach out to me.

If you experience this issue, clear your browser cache or login / logout.

Whether I am an expert or not, I do believe I am competent enough to understand whatever allegations you make–if you are able to present them clearly and concisely, which you have not done.

Instead you have presented broad accusations without any evidence or even specifics to back them up. You can continue to be dismissive of and insulting towards the people trying to help you, but it will not help your situation.

i think the experts can look into what i presented and if they have question they can address me thanks for your concern but im sure they can ask if they have question about the info i presented!

ericwrestle27, could please describe in a single, detailed comment how you think JackpotRace is cheating players–or whatever it is you allege to have occurred?

Your comments so far are very hard to follow and do not give the impression that there is any merit to your claim.

also the link i sent was edited and has two deletons the parent seed probably better to see if it is possible to manipulate anything.
https://raw.githubusercontent.com/ScottHamper/Cookies/84f0b4ed2a22cddc5c54347ff7066775299dab43/tests/spec/cookies-spec.js

so basically with cookies expiring while lotto was on autobot would there have been a devolpement of a hash error on the lotto that was running?

thought u said had jroc fix it ...

From what i experienced was when i opened another lotto tab it would have a hash error so i would resolve that and in turn if i refreshed the other browser i would have a new hash error and it would keep circulating like that so everytime i would clear one a new one would form in previous browser and in turn it would be betting still but had a hidden hash error so couldnt hit. that was my first theory then when looking into the site i saw that code and thought from what i could understand that the when it returned the string we would start hitting again the when i expired we wouldnt.

how and why did you think this? please explain

thought u got that handled..today

could you please explain the hash error thingy in connection to your hack? I have no clue

could this code effect that error when you still had it either purposely or accidentally.