Cryptography is one area where it is better not to reinvent the wheel and not to try to come up with homegrown solutions.
You mean like BCnext did ?  He used sha256 and curve25519, he didn't write his own. |
|
|
|
great job, nexern. However, I agree with the guy who criticized the design: Is it a big deal to change it on default to something more appealing - today's designs of UIs tend to go more to a "light" direction meaning little opacity, brighter colors, corresponding fonts etc. Would that be possible? Would be worth the effort coz it's way more appealing to sceptical Average Joe  yes, this is possible of course and very easy too. since the whole gui is powered by pure code and doesn't use common gui widget's the advantage of this approach is, besides the compact size, the flexibility. the skin can be changed in any direction. when done i can add a bright color scheme in block explorer style, which is not so offensive. but as said, the scheme can be edited by the user at any time if desired. changing e.g. the button style from current flat to bordered/raised can be made by changing just one value. best now is to finish the hub. let's talk about the visualization right after. I prefer my screen dark, don't like staring at a light bulb all day. Please keep the dark theme as an option even if not default. |
|
|
|
marcus03, nexern, minusbalancer if you won't agree on a key stretching algorithm soon, I'm gonna pick one for you and then insist a burning bush told me it's the best one.
Is http://wiki.nxtcrypto.org/wiki/New_Address_Format up-to-date? Edit: There are alternative approaches on this page. Can you decide for a solution, present it and then ask for acknowledgment? Edit2: My take on the alternatives: -Alphabet: Scheme 2 -Prefix: Allow use of "NXT-" prefix. Let clients decide if they show it. If user inputs an address longer than 17 character and it starts with "NXT-" clients will now that this is a prefix, so users can input addresses with and without NXT- prefix. I think NxtChg was talking about the password key stretching, not the address format. My opinion is that we should stick to a standard, tested and reviewed algorithm, such as PBKDF2 indeed. Cryptography is one area where it is better not to reinvent the wheel and not to try to come up with homegrown solutions. |
|
|
|
- I want to add database persistence, which will be a major new feature, before releasing 0.6.0.
Database? What is that dabase going to be used for? I am a bit confused, is it not all in the blockchain? Yes, but the blockchain itself now needs to be stored in something better than serialized java object files. |
|
|
|
"DEBUG: Error in block generation thread java.lang.NullPointerException"
You need to include at least the first few lines of the stack trace that follows this error message, else I can't do anything about it. |
|
|
|
why not 0.6?
Because: - 0.6.0 is not stable yet - the code is pretty, but it has no new features relative to the tried and tested 0.5.x series - I want to add database persistence, which will be a major new feature, before releasing 0.6.0. I am actually done with the refactoring and plan to start working on the database persistence now. Having to wrestle with the guaranteedBalance bug and release 0.5.11 slowed me down a bit, so I expect 0.6.0 to be ready some time next week. Unless other emergencies appear. |
|
|
|
Can someone answer me this:
If i forge a block, can someone else see my IP then?
Or lets phrase it diffrently. I need to run a node to forge, is my account number connected to the forging IP?
Could someone please answer this?I was discussing this with a friend and we came to the conclusion that this would be a huge security concern if it is indeed so. The IPs of nodes that forged blocks are NOT recorded in the blockchain. Also, when your peers receive the block that you generated, they don't know that it was you who generated it, because your node also broadcasts blocks it received from other peers. However, an adversary who monitors all your internet traffic (your ISP) could possible deduce that it was your node that generated a block based on traffic analysis. It is possible to run Nxt over tor if you want to completely avoid that risk. To do so, assuming you have tor running on localhost at port 9050, add the following system properties to your start.d/nxt.ini file: -DsocksProxyHost=localhost -DsocksProxyPort=9050 This will force outgoing traffic to use tor as a socks proxy, but jetty will still listen on all interfaces and accept connections that didn't come over tor. If you are behind a router or firewall, this is not an issue, if not, edit the jetty configuration files (start.ini) to limit jetty.host to localhost. Also, if you are using tor, you cannot share your address with other peers that want to connect to you (because what they see is the tor exit node IP), so you should disable shareMyAddress in web.xml and not set myAddress there. It is like being behind a router without being able to set up port forwarding. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Release 0.5.11 http://download.nxtcrypto.org/nxt-client-0.5.11.zipsha256: 2157335852e7b5013229f5b73f5f156b1b72a116f8625fc73d4de80a0f7ffa11 Change log: Fixed performance problems in getState, getEffectiveBalance and getGuaranteedBalance. The getGuaranteedBalance calculation now uses a different algorithm and may in some cases give different results than the 0.5.10 guaranteedBalance calculation which had some bugs, so it is advisable that everyone upgrades to 0.5.11 to avoid the risk of a fork. Fixed a bug with setting the public keys of accounts that forged blocks without having any outgoing transactions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJS6hPPAAoJEFOhyXc7+e2A4JIQAJCid4K4z+07zVSXIrNdjC+7 B/9riaqdXL6pNhbuXRFqmFazJb2LQfw2CHDxiYujqOzQr9lfYDkJSaSa8tpY1seY ZxMhzq2OcIcvp2KFuiueq25GNuWxAj/2Ctjm8Cco4SvzhXrK10JpOWgGexFN1ZHX VDGgZiNheLwqYMqcfouVtPlNAR0l1hu26pUqw3zFUfRFWxfc7lIJZmj3uBJXdLxw HSLEosCHtME7J2GL526rtpvY1PwNBJszrd6ustSRfevLY6JyAYj8yoqpbPfsc/r5 PEEQlPw0RUAWsaW+r2V7zXHKGtpyLWaI84MyHIpSZKsGZuWcDqXXDLGQxIE6sm1a /mJgewfU63mxym+LA+M+fEg57xtry+YldOrwyv8AATfANsusXX/A50gG/CHdqBDF m4nUKlWjeXfDhrwxjE2ZVnwSO7pPYrvnEkw9LxvKF4sv0LfCFKDdhNsgDfLPEQp8 mWy0WfIiraz5QDkDf1JKBJM+1tRJWwBuNY1Z4nHZwsVPO0cf6aXOg52qP63sIe98 CgR6xVn8S2xhhyUMFluJcfldQA0vMr2dNAnt9eTjUykDpS0VHNcW54RSpQZxE0Z6 WT0xSCvknUB86N7BzatZz27BtCSieC+MWn3KrQvofB6wbW9OMXuTjFTuBxMoMD1H 9fZmQKaXviyVQ8C9ci/H =plAW -----END PGP SIGNATURE----- |
|
|
|
Error: [2014-01-28 12:34:48.426] DEBUG: Error in block generation thread
java.lang.NullPointerException
You use the return of the function without take care of the return value! Nxt.blocks.get() can return invalid value like here. Yes, and I see nothing wrong with that. This is what exceptions are for. If a block that should be in the Nxt.blocks map is no longer there, something is wrong and there is no point in trying to continue. What would you do, ignore the missing block and pretend all is fine? See that little DEBUG notice on top? If debug output was not enabled, the end user would not even see the exception. Because it is caught at a higher level, and the block generation thread just skips the current iteration and starts over. No it's because you use an language more resistant that's you can't have security problem. (With gcc 4.8 and modern CPU you can have same security with C++ code).
Now I see where you are coming from... |
|
|
|
Anyone else get VERY SLOW responses from the API? I use it on http://nxtra.org faucet - which now loads very slowly since updating to 0.5.10 - any ideas? Edit: never mind, redownloading the entire blockchain seems to fix this issue. Edit 2: actually, as soon as it comes to block 51xxx it starts to massively slow down again... Anyone experiencing the same? Same here. It's unusable after block 51.000. I have to stop developement on my client until this is fixed. I am aware of the problem, I will have a fix later tonight or tomorrow. I need to know the precise definition of guaranteed balance before I can provide a fix. I wrote an alternative implementation of Account.getGuaranteedBalance(), but it is giving me different results than the original getGuaranteedBalance() which CfB wrote. While trying to track down why that is, I found a few things in getGuaranteedBalance() that don't make sense to me, but I don't know which are bugs and which are a part of the Transparent Forging design. I cannot continue with that problem until I know how exactly it is supposed to work. I am waiting for a response from CfB. In the meantime, I will continue my work on 0.6.0. |
|
|
|
Anyone else get VERY SLOW responses from the API? I use it on http://nxtra.org faucet - which now loads very slowly since updating to 0.5.10 - any ideas? Edit: never mind, redownloading the entire blockchain seems to fix this issue. Edit 2: actually, as soon as it comes to block 51xxx it starts to massively slow down again... Anyone experiencing the same? Same here. It's unusable after block 51.000. I have to stop developement on my client until this is fixed. I am aware of the problem, I will have a fix later tonight or tomorrow. |
|
|
|
Is there a lock in 5.10 in editing any *.html files in webapps? I always add a new title for the wallet (address of my site) and it wasn't possible to launch the client after this.
If there is, it's pretty smart of them! No, there is no such change. The difference between 0.5.9 and 0.5.10 is extremely small, just a few lines of code related to the bugs mentioned in the changelog, nothing more. It is nonetheless important that everyone upgrade to 0.5.10. |
|
|
|
got a error with NRS 0.5.9, don't know whether it is a bug.
DEBUG: Failed to analyze hallmark for peer geodreieck.redirectme.net
No, this is not a bug. Ignore. The peer geodreieck.redirectme.net has a malformed hallmark and is being blacklisted because of that. |
|
|
|
"So the Klee’s crew and Jean-Luc joined the dev team and started with refactoring the java binaries." It is not Klee's crew and Jean-Luc, it is just Jean-Luc. And obviously, I am refactoring source code, not binaries. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Release 0.5.10 http://download.nxtcrypto.org/nxt-client-0.5.10.zipsha256: 9cbe87450f6ed23f8cb881026e44dcee46108101c0de0d40989cbd6215ce233a Change log: This is a bugfix release. All users of 0.5.9 and earlier should upgrade. Fixed a bug in Transparent Forging. The fix will take effect at block 51000. Users who don't upgrade by this block will be left out on a fork. Fixed a minor bug in peer weight calculation. Progress report: The refactoring of 0.6.0 is going well. The Nxt project now consists of 86 java files instead of 1. I will proceed to work on persisting blocks and transactions in a database some time next week. I do not plan to release 0.6.0 until absolutely necessary, because it does not contain any new user visible features and at this point is likely less stable than the 0.5.x series. Urgent bugfixes and new API's, if needed, will still be added to 0.5.x. Any Nxt clone projects that have been eagerly awaiting the 0.6.x series, so that they can benefit from my refactoring work for free, will have to continue waiting, while we make progress. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJS4VdaAAoJEFOhyXc7+e2AMvcP/3/9NX99c370ByMoFgd+odnI k24C1wWIACHAKEENGt4iWGx7FRqgoM3t6nAF4blVjl0aOqkNJNYoID1kx1LWDpuN Emjncb7aMSmasDzN7YAz5x0d5sdBi7k1wEVv9iyBkmxvMot/tcTfhcX6pEwMunPF FBxJC3YQ76MLcOMeJsfwLC+Vofsq/jEhbk5bf2i5XVrH/gjbc19sK3VXUmUQ4Eb0 qvv0YQJc0vIgGBHUHfvePUD9LWyXNGIkweWwADVburAYbhjVWT+jJ4ZSDh16S6VV hZTnEQvkXTjKK+AD7OZSnvY+Fpu8k+gkqFgR3tagNyfoO3iIQ/oEhHY/3PXxrvk0 +N3tYlayjBk00LcCOIaWbyws7MpxNp2fAiQEsKUTKfjPnj6OOgII9fTNCLcoKFcN ql3iupT9i1jGEbwAfAthNCQ/unlQh8moqRAHcpxLu/ioZBLfzFz5XRkhBUrtTjz3 fIkVEgWwS4Ch1oJh8j5N9rmdvUvxOoyjmFsYm0fLf1NzAmwaegMPiXDXiXUFqYTj BDNzgtNRXXtA+4NpoaJvajsnpy1VP5/9BA+CpdBIy17c566TFuiQt8zwp+YRZA6o cu9Zx79r4JZzJ4Q+i5eMXQ7v1IzzIAtBfYRfOBScvVY8Q8/LLn4isjgszFLbT7H1 1lge4xfvtVD3fJY8j46Y =CYXu -----END PGP SIGNATURE----- |
|
|
|
V0.5.9 Client got error after two days running. [2014-01-20 09:33:45.146] NRS 0.5.9 started successfully.
[2014-01-21 22:00:51.223] Re-scanning blockchain...
[2014-01-21 22:00:57.832] ...Done
[2013-01-22 10:19:34.646] DEBUG: Error sending JSON request
java.io.IOException: Error writing to server
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Sou
rce)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Sou
rce)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown So
urce)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at Nxt$Peer.send(Nxt.java:3595)
at Nxt$Peer.send(Nxt.java:3556)
at Nxt$7.run(Nxt.java:6301)
This is completely safe to ignore, just some network connection error. I already ignore most of those in the code, but they are usually more specific, haven't seen a generic IOException thrown so far. |
|
|
|
Got following output with 0.5.9: 2014-01-21 15:07:30.351] Generated an incorrect block. Waiting for the next on$
[2014-01-21 15:10:38.931] Re-scanning blockchain...
[2014-01-21 15:12:32.665] Generated an incorrect block. Waiting for the next on$
[2014-01-21 15:12:33.853] Generated an incorrect block. Waiting for the next on$
[2014-01-21 15:12:37.437] ...Done
Is this normal behaviour? Yes, and it is great that it no longer spits out a whole bunch of errors while doing the rescan. |
|
|
|
Are you against the ID of a special alias with @ in the front meaning it's bound to a the account id?
Hm, u shouldn't ask me, decide urself. Well, I am for it.. But it's you guys (devs) that have to implement it :-) Please enter it as a feature request in Jira, but I will not have time to look at those soon. I am in the middle of the 0.6.0 refactoring. |
|
|
|
Looks good. I just wanted to point out, the official packages I make are generic, and I only ever use Linux to develop and test them, there is nothing windows specific about them... |
|
|
|
|
Show Posts
