Topic: Nxt source code flaw reports - page 36. (Read 113369 times)

Difficulty to hack any of such accounts ~ 2⁷¹/numberOfAccounts of SHA256 operations.

Edit: U can't compare this to Bitcoin network coz there r no ASICs implementing Curve25519 yet.

This is not a solution IMO. 2^64 is "only" 18446744073709551616 addresses. If not already possible, it isn't going to take many years for someone to gain the ability bruteforce and store keys to all of these addresses and automatically empty any "new" Nxt account whenever it's "made".

Unless ofc I'm missing something. Do tell if I am.

This shows stability of the network, currently it's 63% (900/1440). We'll see ~100% when TF unleashes its full potential.

Because when you divide 1/2 you must not get 153722867000000000

C-f-B, do you know why we have 900 blocks per day, not 1440? This rate is stable for many days.
I'm trying to find some flaws in target/hit calculations, but have no good thoughts still.

If base target is 0 then blocks can't be generated. This problem can arise if u calculate 1/2 using integers.

I don't know the real case in Nxt. But if the 64-bit address is cut from 256-bit address, then it should be accepted. We can expand the address if collision takes place.

It's not a matter of garbage collections.
The problem is that NSR trust some numbers from outside. Dealing with OOME is not that simple...

I'm looking through the source, and have strong feeling that payloadLength can be easily ignored at all. Ignored and throwed out from protocol.
In generateBlock() local variable is used to check on MAX_PAYLOAD_LENGTH limit, than just set to corresponding block variable.
In pushBlock() it is used in checks in the begininng, but checks easely can be done later, on transaction checking.
In loading thread and "processBlock" request it is used to create ByteBuffer with desired size, but it's always better to use dynamic-sized buffer anyway, with some checks on max size.
In "getNextBlock" request it is used to limit response, but again you can calc it dynamically with transactions.
Elsewhere it is just readed from JSON and writed back.

From http://crypto.stackexchange.com/questions/9435/is-truncating-a-sha512-hash-to-the-first-40-characters-as-secure-as-using-sha1

Isn't this memory garbage collected?

https://bitcointalksearch.org/topic/m.4352067

All 256 bits r checked after the very 1st outgoing transaction is made.

1. They'll be unblacklisted after a short period of time.
2. They can't do that without providing valid blocks or being blacklisted.

Service Providers will solve these problems. Annual shrinking solves the problem of evergrowing blockchain.

We should use another fund for this, more decentralization is better.

Hey gang,

Any thoughts on this?  https://nextcoin.org/index.php/topic,2418.0.html

Right now it is 2³¹ blocks and 2³¹ transactions (due to internal structures, nonsense in perspective), plus usual file size limit (nonsense on any modern FS).

In NXT, I believe that there is a maximum blockchain size (meaning, it will never go beyond a certain limit) because of the way proof of stake works.

I agree the 64 bit address space is like the millenium bug of nxt. Someone can bruteforce all adresses and set up a script to automatically scan the blockchain and steal coins that aren't yet safe.

I know this has been discussed before, but I was never convinced by the answer and, after looking at the code, I'm less convinced.

The collision problem is a BIG deal.
In order to remedy it, we're assuming:
(1) We can detect it happening in the wild before a lot of NXT is stolen and/or no one exploits it to steal NXT (which has proven to be false as people have already stolen from NXT accounts with simple passphrases)
(2) There is no cost in changing everyone's address in the future to accomodate extra digits (which seems like a nightmare worse than Y2K that will cause NXT a lot of harm)
(3) There appears to be a race condition if two accounts get created that map to the same account number since there is no deterministic way to determine which one will actually get created, and it would actually be possible for both accounts to exist in different parts of the network until one gets overwritten by the other (granted this is an edge case)

It seems foolish me to promote NXT as a "cryptographic" currency when:
(1) It's using a hashing function that isn't even proven to be cryptographically secure (since as I pointed out earlier a subset of a hash is not guaranteed to have the same characteristics as the entire hash)
(2) It is using a 64-bit "hash", which is substandard with respect to security

What's the feature? To make it easy for NXT to be stolen?