Topic: NXT :: descendant of Bitcoin - Updated Information - page 1906. (Read 2761645 times)

I strongly consider that support your presentation is much better then spend coins to all this "please-give-me" 's I see in this thread.
And I wonder why your request has almost no reaction among Nxt holders...

sorry guys but I have to go    ...will be back soon....Nxters are making history today

I would if I knew how to reproduce this situation.

Oh, please! 8 bits out of 256-bit address? 3% increase. There's probably much more bloat than this already in the system.

It can even be 4 bits. Anything. A single party bit is better than nothing.

The NXT system will not be treated seriously if it can send money to an arbitrary number without any checksum at all and this money will be locked forever!

You simply won't havee a chance to reach 30.000 tps with this design

Although there will be a new client soon (hopefully) such a bug shouldn´t be left in the current client. Can´t you try to debug it CfB?

Right. Code that sends money is very simple.

I disagree. We r moving to 30.000 tps goal, every ounce of performance is important.

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.

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.

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?

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.

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.

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.

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

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

@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?

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

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 s t

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

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.

726 in John726 is the CRC-sum.