Nxt source code flaw reports

[FrictionlessCoin]

I finally discovered the flaw in the Nxt source code:

Here is the FAIR distribution that the Nxt folks are so proud of:



This is a graph of the original NXT distribution.  73 accounts.

Here are the numbers:

36742
1970092
349130
24880020
2867856
9975150
2690963
7648
5486333
34913026
997515
30922966
6650
44888
2468850
49875751  <-- Did he pay in?
49875751  <-- Did he pay in?
9476393
49875751 <-- Did he pay in?
14887912
528683
583546
7315
19925363
29856290
5320
4987575
5985
24912938
49875751 <-- Did he pay in?
2724712
1482474
200999
1476156
498758
987540
16625250
5264386
15487585
2684479
14962725
34913026
5033128
2916900
49875751 <-- Did he pay in?
4962637
170486123 <--- 170 million Nxt
8644631
22166945
6668388
233751
4987575
11083556
1845403
49876
3491
3491
9476
49876
6151
682633
49875751 <-- Did he pay in?
482964
4988
49875751 <-- Did he pay in?
4988
9144
503745
49875751 <-- Did he pay in? Yup, 50million each
52370
29437998
585375
9975150

[salsacz]

This is the FAIR distribution (100% proof of stake) that the Nxt folks are so proud of:
170486123 <--- 170 million Nxt

Looks like 9 guys have a lot of stake. 

170 mega account didn't belong to anyone, it was used for unclaimed coins, they were being given to their owners till 3 January.

This is a real and fair Nxt distribution, do not listen to his liar.

[Come-from-Beyond]

I'm not sure, bu I think there is one small bug, that might cause perfectly fine generated block to be rejected.

In one of the anonymous objects, there's following piece (which happens to be my favourite piece of code in nxt btw):

Code:

int elapsedTime = [b]getEpochTime(System.currentTimeMillis())[/b] - lastBlock.timestamp;
if (elapsedTime > 0) {

	BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
	if (hits.get(account).compareTo(target) < 0) {  // [b]FIRST[/b] check

		account.[u]generateBlock[/u](user.secretPhrase);

	}

}

Now inside generateBlock, there's following piece:

Code:

Block block = new Block(1, [b]getEpochTime(System.currentTimeMillis())[/b], lastBlock, newTransactions.size(), 0, 0, 0, null, Crypto.getPublicKey(secretPhrase), null, new byte[64]);
block.transactions = new long[block.numberOfTransactions];
int i = 0;
   ⋮
// fill in missing stuff in the block
   ⋮
block.blockSignature = Crypto.sign(data2, secretPhrase);

JSONObject request = block.getJSONObject(newTransactions);
request.put("requestType", "processBlock");

if (block.verifyBlockSignature() && block.[u]verifyGenerationSignature[/u]()) {

And in verifyGenerationSignature there is following check (in both blocks):

Code:

int elapsedTime = timestamp - previousBlock.timestamp;
BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
byte[] generationSignatureHash = MessageDigest.getInstance("SHA-256").digest(generationSignature);
BigInteger hit = new BigInteger(1, new byte[] {generationSignatureHash[7], generationSignatureHash[6], generationSignatureHash[5], generationSignatureHash[4], generationSignatureHash[3], generationSignatureHash[2], generationSignatureHash[1], generationSignatureHash[0]});
if (hit.compareTo(target) >= 0) {  // [b]SECOND[/b] check
	return false;
}

Now, notice, that in FIRST check, value of target will most likely be different, than in SECOND check
(because in FIRST check value of elapsedTime will probably be different than value of elapsedTime in second check... most times,
the difference will probably small enough, and SECOND check might pass, but not always...)

Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

[Come-from-Beyond]

Edit:  Hey... guess what?  I got the incorrect block notification as mentioned above... but it was a VALID block after all!!!

Can you comment on the above CfB?  ...just trying to understand...   thnx   

It's a minor issue. Keep forging. We'll fix it later.

[gimre]

Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

What?

Cfb, System.currentTimeMillis() is called twice in two different places, in even if in first case there was hit, in second one (in verifyGenerationSignature) there might be miss.

[Come-from-Beyond]

Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

What?

Cfb, System.currentTimeMillis() is called twice in two different places, in even if in first case there was hit, in second one (in verifyGenerationSignature) there might be miss.

Only if a new block was found while we were generating our block.

[gimre]

Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

What?

Cfb, System.currentTimeMillis() is called twice in two different places, in even if in first case there was hit, in second one (in verifyGenerationSignature) there might be miss.

Only if a new block was found while we were generating our block.

Let me rephrase that:

• there's a check if hit is lower than target (based on System.currentTimeMillis())
• then, there's a block generation
• then, at end of block generation, there's check in block sig is ok, and generation sig is ok
• in generation block check, there's ANOTHER check in hit < target based on DIFFERENT time than in step 1 (there's another call to System.currentTimeMillis())

So what CAN happen, is that the time will be ok during FIRST check, but will be BAD during second one, so verifyGenerationSignature will fail.

It's not a big bug, and probably, it'll happen less times, than invalid signature itself, but still it CAN happen.

[BloodyRookie]

If hit < target1 in the first check then hit < target2 in the second check because the target increases if the elapsed time increases und thus target1 <= target2. So it shouldn't be a problem.

[ZeroTheGreat]

This is a real and fair Nxt distribution

Well, thanks for graphics, but numbers soon'll get old (I think distribution'll go even better, we're in 62-days old system). It'd be checked at picture.

[gimre]

If hit < target1 in the first check then hit < target2 in the second check because the target increases if the elapsed time increases and thus target1 <= target2. So it shouldn't be a problem.

Oh gosh, I somehow read the code in opposite manner. Feeling dumb now.
Thanks for clarification.

[perl]

Question of transparent forge

If I understand correctly:

The calculation to see if i can build the next block is make from all data in the last block?

All transaction include in lastblock impact scoring ?

I have ammount and public key for all nodes connected !

I can estimate the next account forge next block !


With this, I can make transaction for the next block with very good scoring for me for next lastblock

n-1 = last block forge
n = the current block in the forge
n +1 = The block I want to forge

1.) I predicted account that will forge the current block (n)
2.) I compute 100 000 or more transaction a include in the current block ( Transaction Alias per ex ).
3.) I choice best transaction need commited  for make scoring current block in the forge best for me
     Now ,  I am the person forge the next (n +1)
4.) return 2 or 1 if not success

[BloodyRookie]

No perl, the transaction data is totaly uncorrelated to the generation signature of a block.

[gimre]

With this, I can make transaction for the next block with very good scoring for me for next lastblock

n-1 = last block forge
n = the current block in the forge
n +1 = The block I want to forge

1.) I predicted account that will forge the current block (n)
2.) I compute 100 000 or more transaction a include in the current block ( Transaction Alias per ex ).
3.) I choice best transaction need commited  for make scoring current block in the forge best for me
     Now ,  I am the person forge the next (n +1)
4.) return 2 or 1 if not success

a) doing transactions will probably lower your chance for forging
b) I assume, you've meant, that someone ELSE forged block "n", if so, how are you going to predict, what was generationSignature for that block...?

[perl]

Ok for my, génération signature need secret .
Probleme as need one requirement ( I forge regular current block )


The id block use transactions for generated directly or not direcly (previousBlock) ?
If yes , probleme is present.


If account can forge the current block then account can make block for high scoring of next block


Resultat
If can forge one block  
I can forge next block

Fee on inject transaction is return by minning POS
And bonus, I have make free alias



And if blockSignature not include transaction.
I can inject transaction in block

[BloodyRookie]

No perl, the transaction data is totaly uncorrelated to the generation signature of a block.

[perl]

Is perfect for next question.

I can now forge next block with 0 Transaction.


You have two choice:
Get 0 Fee now
Or waiting for get fee

What your choice ?

[CIYAM]

You have two choice:
Get 0 Fee now
Or waiting for get fee

If you "wait" then you *lose* your chance to forge (timing is an essential part of the way it works).

[perl]

I lose what ? If not interested quality of network ? only interest by profit

I have not see in code check interval for discard block or account as waiting many more time necessary

Edit:Personnal i have interest by quality of network .And commit my reflexion and not used exploit ( not proved )

[CIYAM]

I have not see in code check interval for discard block or account as waiting many more time necessary

It may not have been introduced yet (the "transparent forging" stuff is being introduced one step at a time).

Basically though if you have your chance to forge but "delay" then you will be punished by not being able to forge for x blocks after.

[perl]

Not in place now
Is exploit is possible now
Actualy , not punish for make delay in forge block

Other exploit possible.


If forge current block.
I can add 32K transaction for create alias ( Max 255). I have return all fee when forge


You have not response for upgrade scoring for next next block