I still can't get my wallet to update, stuck on block 37294 using client version 1.2.0.1
I am running two other wallets without issue on the same machine so I don't believe it's a firewall issue.
Already have tried rebooting and relaunching wallet over and over.
Any ideas would be greatly appreciated.
-Brett
Topic: [SNRG] 🔥 Synergy 🔥 Cloud.Synergycoin.com Cloud Bot Now Live!! 🔥 - page 10. (Read 162188 times)
November 11, 2015, 06:03:36 PM
November 06, 2015, 11:12:26 PM
this looks interesting. Can anybody give me short introduction about synergy? Never heard of it. Did it have ICO or premine/instamine?
Originally POW which ended forever ago - approx 4300 blocks total (see ann) - now POS.Very innovative Dev and Team - always coming up with new twists.
Always under-promise and over-deliver.
Latest development is Trading bot that you can pay for only when you use it -
Pay 1 day use 1 day - pay 3 days and it is 3 consecutive days.
Payment in Synergy that is Burned - over 1000 SNRG burned so far.
Max. funding of bot is 30 days - If send over 30 days extra is burned - so don't .
More developments coming soon.
November 06, 2015, 05:09:19 AM
this looks interesting. Can anybody give me short introduction about synergy? Never heard of it. Did it have ICO or premine/instamine?
November 06, 2015, 03:27:34 AM
November 06, 2015, 02:44:42 AM
I just want to make sure those that are new to Synergy Cloud see this and understand that we make security a top priority. If you've got any questions, please feel free to ask. If it's too technical, I'll find someone to get an answer for you!
Enhanced API Key Encryption:
This update vastly improves password and API security. According to security best practices, passwords are not stored on our servers (and never were). Instead only the cryptographic fingerprint ("hash") of a password is stored. When a user logs in, the hash of the attempted password is calculated and then compared to what is stored on our server. To discover the password, an attacker can try to hash many different passwords to find those that match hashes stored on our servers.
To thwart this type of brute force search, we do not use a simple one-step hash. Instead, our new system stores the a hash of the password using a large number of cycles of a very computationally expensive hash, made more secure with a large 256 bit random salt. To get a sense of how long a 256 bit salt is, an example would be bb5d3f9c0e396c3f8884f24ec43a16a31e6139e4e10d44512c261fc305df427f.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
We use similar technology to protect API keys. We do not store the actual API key on our servers. Instead we store the encrypted version, using AES encryption, which is one of the strongest encryption algorithms available. We also do not store the decryption keys to the encrypted API keys anywhere. When a user logs in, the decryption key is generated dynamically from the user's password, using a key derivation method similar to the method we use to create the password hashes for login. Are the password hashes and API decryption keys the same? No. Just the method to generate them are similar in that they are created using numerous rounds of strong cryptographic hashing with a random salt. The random salts are different.
Finally, the salts are stored and the hashing is performed on a server remote from our database server, meaning that even if an attacker recovers the password hashes and encrypted API keys, they will still have to compromise the remote server to learn the hashing algorithm and salts. But, even in the highly unlikely event that they compromise both servers, discovering the hashes, encrypted keys, salts, and hashing algorithms, they will still be stifled by the need to brute force passwords under the burden of our very computationally expensive hashing system.
November 03, 2015, 11:57:41 PM
This is something that has been requested by a couple users, however, I personally feel some of the items we have on our list would be more utilized by the community.
"Some of the items"? Come on, tease us
I'd like to see some functionality be built around the staking of SNRG.
I miss Turbo Stake!
New Qt wallet looks good guys. Keep on delivering and Synergy will do well. I cant wait to see whats next.
November 03, 2015, 10:08:22 PM
Nice work here gents
November 03, 2015, 05:21:39 PM
This is something that has been requested by a couple users, however, I personally feel some of the items we have on our list would be more utilized by the community.
"Some of the items"? Come on, tease us
I'd like to see some functionality be built around the staking of SNRG.
November 03, 2015, 04:44:57 PM
Wallets have been updated with the latest logo and colors. Update to the new look today!
i update wallet to keep stake coins! thank you for update please keep going.
November 02, 2015, 08:21:03 PM
This is something that has been requested by a couple users, however, I personally feel some of the items we have on our list would be more utilized by the community.
"Some of the items"? Come on, tease us
November 02, 2015, 06:44:13 PM
Wallets have been updated with the latest logo and colors. Update to the new look today!
November 02, 2015, 04:15:46 PM
Any plans to try and implement arb function?
Would be interested as well on what the plan is for that function.
This is something that has been requested by a couple users, however, I personally feel some of the items we have on our list would be more utilized by the community.
I will not implement a manual arb functio,n so if we're going to do it, it needs to be done right which would take a decent amount of resources. Definitely something we'll discuss, but at this point we have no solid plans or timeline.
November 02, 2015, 03:58:31 PM
Any plans to try and implement arb function?
Would be interested as well on what the plan is for that function.
November 02, 2015, 01:34:58 PM
My wallet doesn't look like it's syncing up and I sent coins to it 10/28 and they still aren't there.
I have three connections currently.
Is there a new wallet since I downloaded this one last week or something else I need to do.
Any help would be greatly appreciated,
Brett
I have three connections currently.
Is there a new wallet since I downloaded this one last week or something else I need to do.
Any help would be greatly appreciated,
Brett
Hey Brett,
Can you confirm the number of blocks in your debug console matches what is in the explorer? https://chainz.cryptoid.info/snrg/
If you want to join Slack I can help you out in real time: http://www.synergycoin.com/wp-login.php?action=slack-invitation
-nextgen
November 02, 2015, 10:39:20 AM
I have been trying out the bot for a good week or so now.. I do notice at time my dust orders get an error, other than that pretty smooth. Any plans to try and implement arb function?
November 02, 2015, 10:31:27 AM
My wallet doesn't look like it's syncing up and I sent coins to it 10/28 and they still aren't there.
I have three connections currently.
Is there a new wallet since I downloaded this one last week or something else I need to do.
Any help would be greatly appreciated,
Brett
I have three connections currently.
Is there a new wallet since I downloaded this one last week or something else I need to do.
Any help would be greatly appreciated,
Brett
No new releases. I think you must restart your wallet or PC.
November 02, 2015, 10:28:01 AM
My wallet doesn't look like it's syncing up and I sent coins to it 10/28 and they still aren't there.
I have three connections currently.
Is there a new wallet since I downloaded this one last week or something else I need to do.
Any help would be greatly appreciated,
Brett
I have three connections currently.
Is there a new wallet since I downloaded this one last week or something else I need to do.
Any help would be greatly appreciated,
Brett
October 30, 2015, 03:41:04 AM
October 30, 2015, 03:38:32 AM
To thwart this type of brute force search, we do not use a simple one-step hash. Instead, our new system stores the a hash of the password using a large number of cycles of a very computationally expensive hash, made more secure with a large 256 bit random salt. To get a sense of how long a 256 bit salt is, an example would be bb5d3f9c0e396c3f8884f24ec43a16a31e6139e4e10d44512c261fc305df427f.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
This looks like the right way to do it.
Hmmmm....I wonder what hashing algorithm they are using?
It looks like they might be using scrypt from their last commits. Or why else make this commit at this time? I hope it's a lot of rounds.
https://github.com/Grandpa-Jones/Synergy/commit/df02c93105bc03772e9af58f6b80f6886cfb61e5#diff-31dd861cd0a6a9747cbc540ac1e3bf72R362
Code:
Value scrypthash(const Array& params, bool fHelp)
{
if (fHelp || params.size() < 3 || params.size() > 4)
throw runtime_error(
"scrypthash[force=false]\n"
"Theand arguments are strings, is an integer.\n"
"If [force] is false, thenbigger than 1024 trigger an error.\n"
"Returns hex of the hash sha256(scrypt(sha256(message, salt))).");
It is, of course, irrelevant that you or anyone has "discovered" the hashing algorithm we use. The security doesn't depend on an attacker's not knowing the hashing algorithm. It's good to keep as much secret as possible, but real security does not rely on keeping algorithms (or even the salt) secret. It's how you use them that matters.
The original implementation of the hashing algo we use was pure C# and was too slow. To make it faster, I used the C++ scrypt implementation already in the wallet code base and made an RPC call from it. We could have re-wrote the C# implementation to make it as fast as the C++ implementation, but there was no need. We have to have a wallet running anyway to do things like burn coins.
As usual, I have no idea what you are talking about, but it sounds great. Keep it up Grandpa!
October 29, 2015, 05:37:12 PM
To thwart this type of brute force search, we do not use a simple one-step hash. Instead, our new system stores the a hash of the password using a large number of cycles of a very computationally expensive hash, made more secure with a large 256 bit random salt. To get a sense of how long a 256 bit salt is, an example would be bb5d3f9c0e396c3f8884f24ec43a16a31e6139e4e10d44512c261fc305df427f.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
This looks like the right way to do it.
Hmmmm....I wonder what hashing algorithm they are using?
It looks like they might be using scrypt from their last commits. Or why else make this commit at this time? I hope it's a lot of rounds.
https://github.com/Grandpa-Jones/Synergy/commit/df02c93105bc03772e9af58f6b80f6886cfb61e5#diff-31dd861cd0a6a9747cbc540ac1e3bf72R362
Code:
Value scrypthash(const Array& params, bool fHelp)
{
if (fHelp || params.size() < 3 || params.size() > 4)
throw runtime_error(
"scrypthash[force=false]\n"
"Theand arguments are strings, is an integer.\n"
"If [force] is false, thenbigger than 1024 trigger an error.\n"
"Returns hex of the hash sha256(scrypt(sha256(message, salt))).");
It is, of course, irrelevant that you or anyone has "discovered" the hashing algorithm we use. The security doesn't depend on an attacker's not knowing the hashing algorithm. It's good to keep as much secret as possible, but real security does not rely on keeping algorithms (or even the salt) secret. It's how you use them that matters.
The original implementation of the hashing algo we use was pure C# and was too slow. To make it faster, I used the C++ scrypt implementation already in the wallet code base and made an RPC call from it. We could have re-wrote the C# implementation to make it as fast as the C++ implementation, but there was no need. We have to have a wallet running anyway to do things like burn coins.
Jump to: