Forum Replies Created
I checked using Norton’s URL tester and it said it was unrated, see screenshot attached. We will drop them an email and give them a follow up call on Monday morning to double check and find out what is happening.
Hey everyone thanks for your comments. I agree the sooner we can get to ICO the less risk there is of regulation coming in or investor sentiment shifting. As a project we only get one shot at ICO and this has to raise the funds to build a project/company/development team/marketing traction, pretty much everything. So it’s pretty important to the long-term hopes for this project that we raise the maximum possible amount to give us a war chest for the future.
Some of the development we are doing now is essential to the ICO process. The solidity contract and web3 integration for example are required to sell tokens at ICO and integrate with exchanges afterwards so users can trade their tokens. Other things like the database migration are harder to justify because it’s something we don’t need to do right now and it’s all on the back-end so users/investors can’t see any changes to the platform. They are important though because the last thing we want to do is start marketing again, have the project take off and not be able to handle the increased volume, or worse have security issues when the token hits exchange.
I think there’s a balance to be made with getting the project ready as fast as possible and also not rushing it to the point where we go to ICO and aren’t ready. Right now in the UK it’s 8am on a Saturday and the core team are all working which makes me proud and confident that we are doing everything we can to push this project forwards as efficiently as possible.
This is a good point. Someone else suggested that investors would be more inclined to purchase a token that is priced below $1 usd because some don’t take the market cap into consideration.
We could potentially increase everyone’s holdings and the market cap by 100x and decrease the cost x100 at ICO. So everyone’s holdings in the project would be the same they would just hold 100x the tokens but the same percentage of the total supply. It would be fairly easy to do from a technical point of view, would need to check out the legalities of changing the whitepaper.
Anyone else have any thoughts on this?February 5, 2018 at 10:02 am in reply to: Can both self and publisher mining possible same time #5451
1) yes this is fine if you have a website with the publisher code on you can also self-mine at the same time if you wish.
2) you just wont earn anything because it will be a duplicate user. So you can have the publisher code on a website because the visitors to that website will be different users and will earn JSE for mining. If you try and mine on your own website there wont be any benefit.
3) If it’s the same user then whichever publisher site was visited first will be credited.
The hash rate is actually capped on the self-mining platform. We could increase this up on either the platform or the desktop app but there wouldn’t be any increase to miners earnings because it would be the same for everyone and there is still just a fixed amount of JSE tokens to share out each day.
I am hoping that the desktop app will make it easier for users to run in the background while they are working/surfing the net without having to worry about an additional tab/browser window. There’s some other things we are going to be looking at as well such scheduled mining and so forth so you can turn it on/off at certain times of the day with the desktop app.
The main benefit to users will be convenience rather than increased earnings from higher hash rates at this time.
There’s a few things you can do to increase earnings. If you have a website then you can install the publisher code and get visitors to mine on your behalf. The other option is to promote JSEcoin with your affiliate link. You can get affiliate links from the referrals page on the platform. This way you can earn JSE by helping promote the project to new users.
Did you guys get this sorted? One thing I wanted to mention was that mining doesn’t work from within an iframe. This is to prevent cookie stuffing type mining fraud or attempts to hide the privacy notification with a 1 pixel iframed site.
Assuming the code is still on the site and the website visitors are still visiting then you should still be receiving rewards. Could you try logging out then logging back in to the platform to see if anything has come through?
If you are still having problems send us an email at: https://jsecoin.com/support/contact/
Include the website your code is placed on and the email address you used to register with or your jsecoin userID and we will take a look at your account and help from there.February 2, 2018 at 10:51 am in reply to: What is your Hashrate (max and current) and CPU model? #5414
We haven’t actually tested much on desktop linux environments. To be honest I would have expected linux to perform better. The only thing I can think of is that the browsers are originally built for Windows and tuned to that environment as 99% of users are on that O/S. Then they are ported to linux and lose some performance because the browser wasn’t originally designed with linux in mind. This is just a guess and nothing more than speculation. It could also be that Linux is just more restrictive on the per tab CPU allocation or the amount of resources it allocates to individual processes. I love Linux and have been playing with it since I was a kid, we also use it on all our servers, so it’s certainly not anything we are doing here to restrict the hash rate on the linux operating system.
Hi just an update that this should now be fixed. It was caused when we removed the global listener for the currentBlockID variable and didn’t update the API accordingly. It’s now fixed and providing the real-time blockID.
I checked back through our git repository and there wasn’t any major updates that would affect earnings 10 days ago. Could you send me the link to your site where the code is placed via the contact form at https://jsecoin.com/contact/ and I’ll take a look and see what is going on.
Followed up with Kaspersky again yesterday 11/01/2018 05:18:
Just following up on this as we haven’t heard anything back since the 27th December 2017 and we are still getting user complaints about our site being blocked by Kaspersky. Additionally we have now been whitelisted after review by bitdefender if this bares any influence.
OK this is done. The API documentation has been updated with the new mining function.
I’ve also built an example script to check the mining rewards and latest balance: https://jsecoin.com/misc/checkmining.html
If anyone wants to try this you need to get your API key from the platform’s “Settings” page and set the API access level to at least “1 – read access”.
You can download the source for that file if you want to modify it or use it for reference here: https://jsecoin.com/misc/checkmining.zip
Hope that helps.
I moved the socketio connections to the load servers which also handle the publisher connections to try and balance the load. When I did this I tried to add a variable to state whether the connection coming in was a self-miner or website visitor. I think there’s a bug in this code and it’s not counting the number of connections correctly. Working on it now.