NXT :: descendant of Bitcoin - Updated Information

[Jean-Luc]

Download & run 0.4.9e, this fixed it for me.

In nextcoin.org is written:
"EXPERIMENTAL CLIENT (use with caution!)
Download: NRS 0.4.9e"

Is it ready for non-NXTdev-users, with some guarantee? ;-)

It seems to be fine for me, but then again really anything that's version begins with a 0 is experimental to me

0.4.9e should be more stable and with better performance and memory usage than 0.4.8. I labelled it experimental because I made a lot of code changes. But I haven't changed any business logic.

We don't have unit tests yet, and the way the code is structured it will take some time before we can add automated unit tests for a new release. My servers have been running 0.4.9e and mining with it for two days now, without problems, and in particular I no longer find them stuck on a wrong branch. But for testing transactions, the best I can do is try making a few transactions manually and see if it works.

[1715084616]

1715084616

[1715084616]

1715084616

[landomata]

Did anyone read this:

NSA building Quantum Computer to crack all forms of encryption


http://rt.com/usa/quantum-computer-nsa-encryption-100/

[laowai80]

Is it hard to implement 'send to alias' feature in the current javascript browser client? It'll be a while until other clients are released, so if it's only a couple of hours of coding, it'd be great to see 'send to alias' in the current browser client, and this would be a great PR feature for NXT too compared to bitcoin.

[gsan1]

Hey Nxtlers,

we released a NXT game at http://www.thenxtdice.com/ 
The game is fully raspberry-powered 
Just try it out and win some coins. And the best: Because the raspi is running 24/7 we help to support the NXT network against attackers 

[Jean-Luc]

whoever has access to it can examine your hard disk and find that password.

That cache can be perm. deleted with ccleaner or something similar to http://eraser.heidi.ie/ right?

If it does a secure erase, overwriting the file with random bytes, yes, in theory. Except for solid state drives you never know if what you are overwriting is really the original file location, because of the wear-leveling and remapping magic they do internally.

[Zahlen]

This makes the alias harder to remember though, which subtracts from the main purpose of aliases.

What do u prefer:
1. Send to 2587623823894059467
2. Send to John726
?

Would prefer sending to 2587623823894059467[check digits] when I need to enter the entire address and unable to use aliases, and sending to John, or John276, or any other alias of my choice when I can. If I use alias, I do so accepting the consequences of mistyping. I think most regular folks would also feel like this.

EDIT: On further thought, some regular folks would feel like this. Some would just be careless.

There are still 192 reserved bits in addresses right? Maybe can spare some as check bits?

We can't.

But if it's impossible at the protocol level, then maybe we can look at safeguards at the client level. Maybe clients can (at least have the option of) enforcing check digits for entering naked addresses.

[mnightwaffle]

http://postimg.org/image/djfsspw5v/

Except for solid state drives you never know if what you are overwriting is really the original file location, because of the wear-leveling and remapping magic they do internally.

ahh, I see

[Come-from-Beyond]

Would prefer sending to 2587623823894059467[check digits] when I need to enter the entire address and unable to use aliases, and sending to John, or John276, or any other alias of my choice when I can. If I use alias, I do so accepting the consequences of mistyping. I think most regular folks would also feel like this.

726 in John726 is the CRC-sum.

[NxtChg]

Would prefer sending to 2587623823894059467[check digits] when I need to enter the entire address and unable to use aliases, and sending to John, or John276, or any other alias of my choice when I can. If I use alias, I do so accepting the consequences of mistyping. I think most regular folks would also feel like this.

I second that! We need the same system bitcoin addresses have - embedded checksum, however simple. If it can catch even 1 in 256 typos it already will be a terrific addition! This means you only need 1 extra byte.

Remember, this is not only for typos, it protects against software/hardware/network errors and those happen too.

[nxtuser]

Please, do release the source of your vanity generator. I was about to warn people not to use it, because it is a closed source tool posted by a new user with 5 posts only. Can't be too paranoid after the incident we already had. Without the source, how does one know if your random prefix is really random?

The point of my registration on this board was to share the tool (thus low message count). It is indeed very unfortunate that there's been some hacking lately. I haven't released source code along with the binary because I was concerned it could've been repurposed into a password cracker.

Anyways, I've updated the tool with ability to search for an account number with given prefix and/or suffix and now releasing source code along with binaries.

Usage:
nxtvanitygen p<prefix> s<suffix> t<threads>

All parameters are optional. If no thread count is specified, tool will use all available CPU resources.

Examples:
1. Search for accounts starting with "100" and ending with "001" using 7 threads
nxtvanitygen p100 s001 t7
[INFO] Starting search with 7 threads
[INFO] Searching for account with prefix "100"
[INFO] Searching for account with suffix "001"
[20] 10097471757607329001 : EtYAigzyvucocenbrl4TgrQnZQd
[20] 10003885613434887001 : Hap4Z3hiSUXmwcb71oaX4SA6lne

2. Search for accounts starting with "1337":
nxtvanitygen p1337
[INFO] Starting search with 8 threads
[INFO] Searching for account with prefix "1337"
[20] 13370655427675222059 : wyE3TKF1biEp8MQ9gF1yJEzvhr
[19]  1337321701037332552 : wyE3TKF1biEp8MQ9gF1yJEzvcu
[19]  1337265426018415968 : wyE3TKF1biEp8MQ9gF1yJEzvu6a

3. Search for accounts ending with "1337":
nxtvanitygen s1337
[INFO] Starting search with 8 threads
[INFO] Searching for account with suffix "1337"
[20] 17555624245168541337 : MLrIa0inNTbg1xEsX1Y6Q5d00o
[19]  4357874968632581337 : d7cf3etnKoQyZj5jClnb0rCaBL
[19]  2400089921591981337 : YfXTBQL1BZzCGUVjb0Z0dauGsla
[19]  1973134486410101337 : MLrIa0inNTbg1xEsX1Y6Q5d0bya

4. Just search for shortest possible account number:
nxtvanitygen
[INFO] Starting search with 8 threads
[20] 10338085328686616285 : OmMGRjBOMpShlfYMGFlBuPgja
[19]  4937369289318610888 : OmMGRjBOMpShlfYMGFlBuPgjd
[18]   629863575730409614 : OmMGRjBOMpShlfYMGFlBuPgjj
[18]   468107626643704710 : rctCFsNJU5WlLcdzoDXdhOd4b
[18]   220355335410294776 : OmMGRjBOMpShlfYMGFlBuPgjL
[17]    37716758511259142 : rctCFsNJU5WlLcdzoDXdhOd4P
[17]    31036511679475309 : OmMGRjBOMpShlfYMGFlBuPgjUb
[17]    30528851690106364 : OmMGRjBOMpShlfYMGFlBuPgjld
[17]    23063671801022467 : OLvwAaS8r244yFUCCjVkPzppXd
[17]    16132847436026631 : Kuj2No73oIIyqQ1sSZwXkmAmge
[17]    15844488120866410 : aycQzKqv8VwDly9bAnvJIrwcNf
[17]    14905054651945515 : rctCFsNJU5WlLcdzoDXdhOd4Nj
[17]    12782313021349671 : aycQzKqv8VwDly9bAnvJIrwcvl
[16]     8408041613508761 : aycQzKqv8VwDly9bAnvJIrwcJn
[16]     4055260369096446 : aycQzKqv8VwDly9bAnvJIrwcWt
[16]     2291473488286971 : OmMGRjBOMpShlfYMGFlBuPgjZz
[16]     1547187421785168 : aycQzKqv8VwDly9bAnvJIrwcyz
[15]      550469753637579 : rctCFsNJU5WlLcdzoDXdhOd4xR
[15]      412692226299035 : OLvwAaS8r244yFUCCjVkPzppXQb
[15]      190944096726430 : SedqAaKiWOme016JBddYCObdkNd
[13]        2511821714948 : 9MLNId7oWfs2aYcysRVibYKy99e

Few words on security: tool generates random passwords. They are constructed by combining 24-char random (per-thread) prefix and sequential suffix. Tool uses OpenSSL's RNG to generate that random prefix.

Also, it should go without saying but: PLEASE DON'T USE ANY OF THE PASSWORDS ABOVE AS IT'S NOT SAFE BECAUSE THEY ARE PUBLIC.

You can grab latest binaries (Windows only) here: https://mega.co.nz/#!sZ8j3CTL!O20atwe7U058_BJORo-3jzKn1LpsWmaVAs_xgmj4tBI (use 64-bit version if you're on 64-bit OS)
Source code (and VS 2013 project; you'll have to take care of OpenSSL headers and libs yourself): https://mega.co.nz/#!5E1wnCDI!Z062LkiZK9xJjpMKevNRjnvgfThr4d_eXbBS1gtQwnk

If you find the tool useful and/or fun please consider sending few tokens of appreciation to account number 86533079761. Thanks

[Come-from-Beyond]

Would prefer sending to 2587623823894059467[check digits] when I need to enter the entire address and unable to use aliases, and sending to John, or John276, or any other alias of my choice when I can. If I use alias, I do so accepting the consequences of mistyping. I think most regular folks would also feel like this.

I second that! We need the same system bitcoin addresses have - embedded checksum, however simple. If it can catch even 1 in 256 typos it already will be a terrific addition! This means you only need 1 extra byte.

Remember, this is not only for typos, it protects against software/hardware/network errors and those happen too.

Agree. Someone should add this into client. Everything that can be done on client side shouldn't be implemented in core.

[wesleyh]

@CFB - I'm using the api to send money (via my nxtra faucet) - I get back a transaction ID. However several times this transaction doesn't actually happen. How can I know the transaction failed or do I need another approach?

[wesleyh]

Would prefer sending to 2587623823894059467[check digits] when I need to enter the entire address and unable to use aliases, and sending to John, or John276, or any other alias of my choice when I can. If I use alias, I do so accepting the consequences of mistyping. I think most regular folks would also feel like this.

726 in John726 is the CRC-sum.

Well if someone registers all possible typo's of that alias you can still send to another account by mistake, right? So crc seems useless unless it's enforced for all aliases. Perhaps with some kind of pre-text: crc:john726

[jl777]

What about displaying information about the destination acct and getting confirmation from the user if he wants to send to an acct with the basic info profile, eg. acct size, days old, number of aliases, aliases, etc

This way, we easily avoid sending to an invalid address as that would show up as an empty acct. We could still do it if we wanted to so we can fund new accts.

Won't always know for sure that it is the right acct, but if we knew that the destination acct had a specific alias then we actually would know in that case. Certainly when we are transfering between our own accounts, we would recognize things like NXT in acct.

James

[Zahlen]

Would prefer sending to 2587623823894059467[check digits] when I need to enter the entire address and unable to use aliases, and sending to John, or John276, or any other alias of my choice when I can. If I use alias, I do so accepting the consequences of mistyping. I think most regular folks would also feel like this.

726 in John726 is the CRC-sum.

Yeah, I know what you mean. And the client can (have the option of) enforcing only CRC correct aliases. If I'm forced to choose only between 1) and 2) (like a bad democracy ), I would choose 2). But ideally, I want to choose 3), the way I described. And client is the way to go for 3).

EDIT: I like jl's idea! Computers should always be assisting humans with info like this.

[NxtChg]

Agree. Someone should add this into client. Everything that can be done on client side shouldn't be implemented in core.

And what if one of the nodes gets messed up? Like it probably did in my case? Memory leak, corrupted memory, HDD failure, whatever.

With checksum, other nodes will reject transaction, even the node itself can self-verify this way.

It's also unreasonable to expect this check to be willingly implemented in every client - this must be a requirement on the very basic protocol level.

Adding 1-4 bytes won't hurt much.

[Come-from-Beyond]

@CFB - I'm using the api to send money (via my nxtra faucet) - I get back a transaction ID. However several times this transaction doesn't actually happen. How can I know the transaction failed or do I need another approach?

Just rebroadcast the transaction if it's not confirmed (broadcastTransaction API call). In most cases transactions r ignored coz of incorrect time. Adjust computer clock, only +15 sec in the future is allowed.

[marcus03]

Agree. Someone should add this into client. Everything that can be done on client side shouldn't be implemented in core.

A checksum feature implemented in the client lowers the chance that the client messes something up.

As far as I understand, the request for a checksum was made because ppl were experiencing a problem where money was sent to accounts that they did not enter.

So, you seem to assume that the cause of the problem can not be in the core?

[Come-from-Beyond]

Well if someone registers all possible typo's of that alias you can still send to another account by mistake, right? So crc seems useless unless it's enforced for all aliases. Perhaps with some kind of pre-text: crc:john726

U can say that ur account alias is John/726. The soft will know that numbers after "/" is CRC. U, guys, should just devise a good way.

[lr127]

But if it's impossible at the protocol level, then maybe we can look at safeguards at the client level. Maybe clients can (at least have the option of) enforcing check digits for entering naked addresses.

NRS API can be changed without breaking backward compatibility.
Inside can be stored without check digit - as before. And take / give out only with check digit.
NRS & clients must check this, not client only.
First time to use the old and new version of account number together, developers need time to change their apps.