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

If u catch blocks from genesis block then yes, more and more traffic will be required.

Yes, I'm failed with elementary math

It returns 365 blockIds everytime, so when one year will pass, milestone ids will be one for each day.
So we have more or less the same response for "getMilestoneBlockIds", but longer and longer for each "getNextBlockIds".
Are all rest assumptions correct?
I see a lot of unnecessary traffic, every second.

The logic of this code is as follows:

1. We ask a peer for milestone blocks.
2. We find the most recent milestone block that we know about.
3. We ask next blocks after the milestone one, until we see an unknown block.
4. We download all next blocks.

Gap between milestone blocks is increasing each day, but we'll never need to ask for a lot of ids. Usualy we need only 1 request for milestone blocks and 1 more for next blocks.

I'm lurking through code that tries to sync blocks with other peer. I mean thread started at line ~4463 (I call it "loading thread").

It requests "getMilestoneBlockIds". Peer process this request with code

If I not fail with elementary math, this code returns about four blockIds for one day. So day by day this request moves more and more bytes through network.
What for?
Note: list is in descending order, first block in list is last block in blockchain.

Take a look back to loading thread code.

This code executes only if peer has higher cumulative difficulty, so it's last block never match with our's. So even if we're not in forked chain, common block will be about six hour ago. Or about 360 blocks ago.

So next request to peer will be "getNextBlockIds", which submissivelly returns about 360 blockIds. Many bytes! If we're not in forked chain, chances are very high that only one or two last ids are interesting for us.

But what if we're forked too deep? Take a look at this check:
We're not interested in very low common block anyway!

If my assumptions are correct (and I no failed in elementary math), it's better to:
1. Limit "getMilestoneBlockIds" request with sending lower height of common block.
2. Send 1st, 2nd, 4th, 8th and so on blockIds from the top down to lower height, in response to this request. Or use some other principle, but assume that latest blocks are more wanted most times.

Am I miss something?

I think CnB wrote up a brief description of each flaw, and then hashed the text.  This way, he can verify that he, in fact, knew what the flaws were from the beginning.

This is like sending yourself a letter today, predicting what will happen in 2014.  You can validate your predictions in 2015, if you have an early-dated post mark on the letter.

To prove that we don't cheat by saying "No, this is not the flaw that we injected".

I'm pretty impressed that no one has found an injected flaw yet. Great job hiding them!

I was rereading the initial post and realized that I don't understand what's the point of the SHA256 hashes in it.

FYI, this is actually how Satoshi Dice sends semi-instant payouts.  They include your payment as part of the reward-- if you try to double-spend, their transaction back to you is invalidated, when your transaction is invalidated.  Likewised, if your TX ends up in an orphaned block, their payment will subsequently be part of an orphaned chain.

So... semi-instant transactions are possible under certain circumstances.

If the block with T1 is orphaned then the block with T2 is orphaned too.

I have a question regarding referencedTransactions. ReferencedTransactions are used so that a transaction gets only confirmed when the other transaction is already confirmed.

Okay, lets say I am creating a transaction T2 which has T1 as referencedTransaction. T1 is in the latest block, so T2 gets confirmed in the next block. What if the block in which T1 is in a fork chain and gets orphaned later? T1 gets added to the unconfirmedTransaction list. Now it could be that the deadline is expired and the transaction gets lost. T2 is in the main chain and is confirmed. So the referencedTransaction scheme does not work in that case?

Why are you on here bitching about everything? What is your angle?

You aren't helping fix the issues. But there are a gang of people who are. So the issues will be fixed. Meanwhile go find something productive to do with your life please.

Just in case. 640 Kb 100 chars is enough.

Peer.analyzeHallmark():


"markHost" request:


"decodeHallmark" has same check too.

Why there's check on 100 chars long? Host (peer.announcedAddress, wellKnownHosts too) can be any hostname, why do you limit it?

Hi are you new to crypto or you just created a new account here ?

Some of these are probably duplicates by now, but here's my 2 NXT:

• The entire source is implemented as a single file with lots of inner Classes. To enable distributed development this should be decomposed to at least one file per Class. This is especially true for Curve25519, which just added more clutter when merged into the same file.
• The genesis block is hardcoded into the source. Generally static data resources should be packaged separately as some sort of format that can be easily restored when requested.
• Why are hex strings used for serializing binary data to and from JSON over the wire? Other encodings such as Base64 would save on bandwidth and overhead of the protocol.
• What is the benefit of using unsigned longs for most of the ids? In particular the accounts. Although the hash is giving 256bits of output, 192 of them are being truncated and ignored in these cases.
• One barrier toward wider adoption of NXT is the requirement for whole numbers for amounts and fees. So far the code appears to have all of those values as ints or longs which would make transitioning to a divisible NXT difficult.

Lastly, have you guys thought about providing unit tests or using quality analysis tools like FindBugs, Checkstyle, or PMD? We're going through this at my day job right now, and I have to say early in the process is the best time to try set such standards.

Yep. I got it. Thanks a lot!

@klee: what you are doing for the community is superb.

I don't have such measures to support the development but I am working on a website, that allows all students and stuff of my university to load their CampusCard with NXT. The whole concept is not totally clear right now, because it depends on the alias-system.
but anyway it will include a local exchange €<->NXT.
In the future I hope there also will be anonymous paybacksystems, that allow users to exchange their paybackpoints to NXT.
I think cryptos are very suitable for anonymous paybacksystems and massadoption would be facilitated.

Received?

No, only when opening an account that has no public key associated to it that you can do this. If the account doesn't exist yet (has not received any transactions), then the operation should fail.

actually the difficulty thing doesn't work like that, you can't just generate a block with a high difficulty, because with the private keys you, as the attacker, have available, the block would have to have a timestamp far in the future and so will not be accepted by the peers. (i've already explained the little loophole in there that is caused by a slightly wrong implementation a few pages before here, look for anna gaining 7.5% more forges )