Knowing identity of carlos allows credible legal threat to stop his nonsense. He doesn't care about actually running a coin, so your protection doesn't work. People will still get scammed and then might blame NXT.
If you want to legally prohibit people from redistributing and using your code in other projects, copyright law already does that. Open source doesn't mean anyone can use it if you have a copyright notice on the code. This no difference between software and images copyright. Simply add on top of every source file: /* * Developer : Developer Name ( example@example.com) * Date : xx/yy/zzzz * All code (c)2014 name -- all rights reserved * You may not use, copy, or distribute the code without written permission from the developer * */ Yeah it's as simple as that. That makes it illegal to use the code without developer's permission. This actually is the most restrictive form of license you can release your code under. According to this, every time your code is called or executed you need written permission from the developer. The mainstream open source licenses are what you want to be considering; as they have well thought-out mechanisms to permit your code to be useful yet restrictive enough to prohibit exploitative uses. "According to this, every time your code is called or executed you need written permission from the developer." Not everytime. Jus once. If the developer has offered the permission to use it with Nxt project, that one time written permission is enough. |
|
|
|
I always liked the idea, but the problem might be that users will pick those combinations that are easier to remember and there goes your entropy.
You can generate the words randomly for the user! Use this Electum's dictionary https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.pyor make your own with easy words 12 random words from this 1626 word dictionary gives you 128 bit entropy. |
|
|
|
Knowing identity of carlos allows credible legal threat to stop his nonsense. He doesn't care about actually running a coin, so your protection doesn't work. People will still get scammed and then might blame NXT.
If you want to legally prohibit people from redistributing and using your code in other projects, copyright law already does that. Open source doesn't mean anyone can use it if you have a copyright notice on the code. This no difference between software and images copyright. Simply add on top of every source file: /* * Developer : Developer Name ( example@example.com) * Date : xx/yy/zzzz * All code (c)2014 name -- all rights reserved * You may not use, copy, or distribute the code without written permission from the developer * */ Yeah it's as simple as that. That makes it illegal to use the code without developer's permission. |
|
|
|
If you are able to work fulltime on NXT, PM me how much NXT it would take and what you will be able to do if you were working fulltime on NXT.
I'm very tempted! My primary skills are math and teaching. But I'm not in academia. I can code, in C/C++/Python. But I'm a hobbyist coder, I just do my own thing, never worked with a group of people before. I can write, but I'm not formally trained in writing. I can help out with the wiki, keep old articles up to date, write new ones. Samples of my work: http://wiki.nxtcrypto.org/wiki/How-To:VerifySHA256 http://wiki.nxtcrypto.org/wiki/How-To:GenerateStrongPasswordI need to think more about it. What is everyone looking for? EDIT: I agree, we need a new sweetheart girl to repost  I disagree with your "How-To:GenerateStrongPassword" Correctly spelled words (no capitalization or misspelling) are much easier to rememberr and they are stronger password (as long as the words were chosen randomly) Just 10 random words like this: "mouse dog right sun computer search pizza run religion water" correctly spelled with spaces (no caps), would be much easier to remember and easy to type. Moreover these kinds of pass phrases are very strong. Lets assume that these 10 words came from a simple 3000 word dictionary. Even if the attacker knows all 3000 words in that dictionary, the entropy is still higher than 115 bits 3000^10 = 5.9049e+34 If you make it 12 words, it would be have higher entropy than Ed25519 (public signature system used by Nxt).  |
|
|
|
I would like to get some feedback about the password generator that I just implemented in NXT Solaris. Secrets consists of 64 characters from the following set of characters: ['a'..'z','A'..'Z','0'..'9',' ','''','!','"','#','$','%','&','(',')','*','+',',','-','.','/',':',';','<','=','>','?','@','[','\',']','^','_','`','{','|','}','~']. 97 different characters. Entropy should be: 97^64 = 1,423609878848517298732088475247e+127 => 422 bit (Is this calculation correct?) To create the secret, I use the RAND_bytes function from openSSL. The seeding is done automatically in the openSSL library through OS-based seed initialization. I was thinking about doing the seeding myself by asking the user to move the cursor or hit on the keyboard, but from what I read about the openSSl implementation, I fear that I might get worse results than with letting openSSL do the seeding. Why not implement Electrum's word based seed? If all clients have the same implementation, the seed could be used on all clients. The advantage to Electrum implementation is that it's easy to type and memorize, and 12 words give you 128-bit entropy. |
|
|
|
I can compare only Nxt and Ethereum:
1. Nxt is simple (for casual programmers), Ethereum is hardcore (for hardcore programmers). I think most of coders will choose Nxt if noone creates a simple Ethereum Contract Creation Kit.
2. Nxt can process 1000s transactions per second (coz of absence of scripts and Transparent Forging), Ethereum can't process too many transactions but they r much richer. I think these platforms would go on par if Nxt didn't have Transparent Forging. With TF Nxt will win.
3. Nxt has fixed supply of coins, Ethereum will be inflationary for a long period of time. Ordinary people prefer non-inflationary currencies.
4. Nxt is 100% PoS, Ethereum is PoW + PoS, so the latter is not so "green".
These r just a few points that came to my mind.
Please stop trying to talk up Nxt at every opportunity in this thread. You forgot to mention Nxt is vulnerable to nothing-at-stake attacks, poorly implemented in Java (known for security!), you can't store anything in an offline wallet, and the currency is owned by 71 people who sell it to everyone else. Just get real if you want to talk things up. There is nothing wrong with Java as programing language. Don't confuse programing language with Java Applet that is a web browser plugin It's much easier to write secure software in Java than C and C++ |
|
|
|
Someone make a new MaxCoin.. not making it scrypt is just plain stupid. This coin is for botnets and asic farms.. nothing else. Move on.
Also it's ASIC resistant so it won't work on any of the currency asics. Nonsense. There is no reason to believe SHA 3 is ASIC resistant http://keccak.noekeon.org/Keccak excels in hardware performance, with speed/area trade-offs, and outperforms SHA-2 by an order of magnitude. See for instance the works of Gürkaynak et al., Gaj et al., Latif et al., Kavun et al., Kaps et al. and Jungk presented at the Third SHA-3 Candidate Conference." SHA 3 was designed by the creators to be efficient in hardware. |
|
|
|
|
0.03 BTC
9c2a3de0134abfdb206d3d127426d6cee7eb560b602d07c87d7959af176030ab
|
|
|
|
1 - N application Hub
Lead developer: Nexern
Status : in progress
EST : January 26
January 26 came and gone, with no update to this date |
|
|
|
- people using weak passwords
Oh, I remembered what I wanted to ask you, CfB: what do you think about key stretching? Would this protect users with weak passphrases? What will protect users would be if the client (by default) creates a very strong (but easy to memorize and type) password that the user must retype in the "next screen". The user should have the option to override that and create their own password, but by default the client should create one for them Electrum style. Just copy the word list and code from Electrum https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.pyElectrum 12 random word passwords are very strong, easy to type, and easy to memorize If anyone has never used Electrum, just download the portable version https://electrum.org/download.htmland rum it first time and see how it creates 12 word password ("seed") on the first run. Something like this should be integrated with a client. |
|
|
|
|
This is stupid. SHA 3 has no advantages over Sha 2. SHA 3 can be implemented even easier (with faster hash rate) in hardware.
|
|
|
|
There is official site where you download the official softwares from the developer.
If you don't understand that 2 ^64 is small number for 2014 security demands, then you need more help than I can offer
This proves that 2^64 is safe - http://en.wikipedia.org/wiki/Wheat_and_chessboard_problemNow, prove me wrong. 64-bit is not considered secure. 56 bit DES was broken in 22 hours in 1999. 64-bit would be 256 times stronger but we are in 2014 now I agree that it depends on how fast curve25519 can be performed. SHA 2 has specialized ASIC hardware due to bitcoin mining popularity so the bottleneck would be curve25519. If it was just SHA2, this thing http://www.butterflylabs.com/monarch/would break every single unused account in database in less than one year curve25519 part will slow this down, and I don't know how fast curve25519 is on GPUs/CPUs |
|
|
|
|
There is official site where you download the official softwares from the developer.
If you don't understand that 2 ^64 is small number for 2014 security demands, then you need more help than I can offer
|
|
|
|
...We are actively trying to educate people of the risk of not having any transaction associated with an account....
so just dont let it sit like that
If you are doing it actively, then good, but I found out about it only in this thread. I have been to official site. Saw nothing about it on main page or in their forum. |
|
|
|
What you fail to understand is that in order to brute force an unsecured account requires not only SHA asics, but also curve ASICS, which there are none of now. but like as has been stated many times for you already here, this is intentional; to allow 'mining' of lost NXT in the future.
Really? How on earth would you know if these are "lost" coins and not someone coins who has been saving them for say his grand kids? |
|
|
|
How is weak security a "feature"?
It is made on purpose. That's bad design. It should have been at least 80 bits. That would have made bruteforce 65 thousand times slower. What site? NXT is decentralized, there is no official site for it. No, there is "official" site where you can download the official software/client. The network is decentralized. Have you any math for how fast it can be done? Or are your words a fantasy? No, it's not a fantasy. 64-bit is 2^64 and that is not a strong enough number in 2014 against brute force -- especially where off line attacks is possible (like wifi password or truecrypt container). 64-bit is good for online accounts (like gmail) where brute force is detectable. Instead of idiotically defending it, you should demand that Nxt developers increase the security to 128-bits |
|
|
|
Break DES in less than a single day
Is there any DES in NXT? Or do you think that all 64bit crypto are the same? It''s irrelevant whether algorithm is DES or BBC or NBC or ZZZ ... the attack is brute force. Given NXT uses SHA 2 for hashing, and SHA 2 has zillion of custom ASIC hardware (due to bitcoin mining popularity), the attacker only needs to brute force first 64-bit of SHA 2 hash. This is not good for Nxt if there is a large scale successful attack that successfully starts stealing from unused accounts with money in it. That will be real real bad publicity and kill the project. |
|
|
|
|
Show Posts
