Nxt source code flaw reports

[SenorHombre]

17598701460244014577

anyone got some NXTcoin as donation for you newcomer :-)

thanks alot for considering it. I know I am late for almost all giveaways. did not find any :-(

[gsan1]

The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method.

Could you follow me?  

//EDIT: This attack would only be possible in 0.4.7e because now a block contains the hash of the previous one (and not only the id).

No , the 64 bytes are taken from the hash and the hash is calculated from all the bytes we got from getBytes(). It is not the first 64 bytes of getBytes().

Yeah.. I mixed that up..

[Come-from-Beyond]

I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

Btw, we have 100'000 NXT bounty for fast JS-implementation. Look at https://bitcointalk.org/index.php?topic=345619.msg4345122#msg4345122 plz.

why js not java? bounty still open?

We want to create an HTML client that signs transactions locally.

Bounty is open, one guy already posted a script but it's too slow.

[Come-from-Beyond]

I am on it but I think it will a lot slower than you want

We'll choose the fastest and will pay part of the bounty then.

[gimre]

why js not java? bounty still open?

two words: thin client

yeah I thought so, but still curve will be needed on the server, and something tells me it can be done better than current one...

[Sebastien256]

Not sure if its logic flaw, but somebody could simply change initial allocation in genesis block to give themselves a lot of NXT.

We have seen a case of altered client already, so changing genesis block's hardcoding and hypnotizing jean-luc into signing it as the official release, would be an obvious but effective way to steal a lot of NXT

James

True, that's why noone knows who Jean-Luc is.

Maybe he is BCNext!

Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian.

I'm not entirely sure who is who or whether all three are one, but that makes it more exciting

Come-from-Beyond is BCNext, and Jean-Luc seems to be another guy. Perhaps all those three are one guy.

Jean-Luc writes english with french syntax, like many french speaking native people (I am). I'm confident that his mother tongue is probably french with very high probability. It is not the case with CfB. I do not see french syntax in CfB writing. That is my analysis. Maybe I'm wrong, but...

[Come-from-Beyond]

Jean-Luc writes english with french syntax, like many french speaking native people (I am). I'm confident that his mother tongue is probably french with very high probability. It is not the case with CfB. I do not see french syntax in CfB writing. That is my analysis. Maybe I'm wrong, but...

And what about BCNext's style?

[rlh]

Jean-Luc writes english with french syntax, like many french speaking native people (I am). I'm confident that his mother tongue is probably french with very high probability. It is not the case with CfB. I do not see french syntax in CfB writing. That is my analysis. Maybe I'm wrong, but...

And what about BCNext's style?

Come on... we all know the truth.  BCNext, Jean-Luc, CnB, Fuseleer, RealSolid, Coinhunter, Gavin, satoshi, BitcoineXpress AND rlh are all the same, very-schizo multi-personality.

Sorry... I couldn't resist.

[Come-from-Beyond]

Come on... we all know the truth.  BCNext, Jean-Luc, CnB, Fuseleer, RealSolid, Coinhunter, Gavin, satoshi, BitcoineXpress AND rlh are all the same, very-schizo multi-personality.

Sorry... I couldn't resist.

[instacalm]

Jean-Luc writes english with french syntax, like many french speaking native people (I am). I'm confident that his mother tongue is probably french with very high probability. It is not the case with CfB. I do not see french syntax in CfB writing. That is my analysis. Maybe I'm wrong, but...

Code:

gpg: Signature made Tue Jan  7 20:16:43 2014 CET using RSA key ID 3BF9ED80
gpg: Good signature from "Jean-Luc Picard (Lead Developer of The Nxt Generation) <jlp666@yandex.ru>"

Jean-Luc Picard is a Star Trek Character. The way JLP, BCN and CFB write is each a style of purpose -- in my humble opinion. Welcome to the Matrix. It may be one, it may be two or it may be three. Who exactly knows... build ur own opinion .

[Come-from-Beyond]

It may be one, it may be two or it may be three...

...or even four.

[klee]

BCNext told in the NXT original thread (in the OP I think) that he is a known forum member.
Hmmmmm...

[minusbalancer]

The whole "futureBlocks" branch of code doesn't work because of the bug.

We should update the commonBlockId once we successfully push the block.
If we will have the "futureBlocks" it will roll out all of the newly added blocks (if any) because of non updated currentBlockId.
Then it will try to add the "futureBlocks" and will fail again. So at the end the whole block chain will be rolled back and peer banned.

It's at line 4570 and further.

[Come-from-Beyond]

The whole "futureBlocks" branch of code doesn't work because of the bug.

We should update the commonBlockId once we successfully push the block.
If we will have the "futureBlocks" it will roll out all of the newly added blocks (if any) because of non updated currentBlockId.
Then it will try to add the "futureBlocks" and will fail again. So at the end the whole block chain will be rolled back and peer banned.

It's at line 4570 and further.

Thx, I'll look at that.

[minusbalancer]

With the published code no one will be able to generate any block ever.

In getEffectiveBalance() we do have the check for the account age of 1440 (blocks).

Since at the beginning of the functioning the system all of the accounts had 0 age, none of them will be able to generate the block.
No blocks generated => no age increase.


 

[Come-from-Beyond]

With the published code no one will be able to generate any block ever.

In getEffectiveBalance() we do have the check for the account age of 1440 (blocks).

Since at the beginning of the functioning the system all of the accounts had 0 age, none of them will be able to generate the block.
No blocks generated => no age increase.

Accounts listed in genesis block can generate blocks, their age is not analyzed.

[minusbalancer]

With the published code no one will be able to generate any block ever.

In getEffectiveBalance() we do have the check for the account age of 1440 (blocks).

Since at the beginning of the functioning the system all of the accounts had 0 age, none of them will be able to generate the block.
No blocks generated => no age increase.

Accounts listed in genesis block can generate blocks, their age is not analyzed.

Agree.
Then we do have the other bug - outgoing transactions are not deducted from the "genesis" created accounts while calculating the effective balance.

Edit: incoming

[Sebastien256]

Jean-Luc writes english with french syntax, like many french speaking native people (I am). I'm confident that his mother tongue is probably french with very high probability. It is not the case with CfB. I do not see french syntax in CfB writing. That is my analysis. Maybe I'm wrong, but...

And what about BCNext's style?

Relative to BCNExt, I don't know. I believe he is not english native, Im pretty sure of that. I did not see any clear french syntax in his writing like in Jean-Luc post. Note that I know Jean-Luc refer to Star Trek, but I still believe he might be french native, but maybe other latin base language have similar syntax to french, so my interpretation might be wrong. I know that english is not latin based. Here are some latin based language: Portuguese, Spanish, French, Italian and Romanian. There are others.

By the way, keep up the good work, what you all are doing is amazing. Really!

[ricot]

With the published code no one will be able to generate any block ever.

In getEffectiveBalance() we do have the check for the account age of 1440 (blocks).

Since at the beginning of the functioning the system all of the accounts had 0 age, none of them will be able to generate the block.
No blocks generated => no age increase.

Accounts listed in genesis block can generate blocks, their age is not analyzed.

Agree.
Then we do have the other bug - outgoing transactions are not deducted from the "genesis" created accounts while calculating the effective balance.

Edit: incoming

Correct, at the moment they can transfer money to the account that will have the highest chance to forge next...
I also checked in the decompiled 0.5.3 code, same bug.

Nice find!

Unfair advantage for the founders, please fix

[gimre]

The whole "futureBlocks" branch of code doesn't work because of the bug.

We should update the commonBlockId once we successfully push the block.
If we will have the "futureBlocks" it will roll out all of the newly added blocks (if any) because of non updated currentBlockId.
Then it will try to add the "futureBlocks" and will fail again. So at the end the whole block chain will be rolled back and peer banned.

It's at line 4570 and further.

Thx, I'll look at that.

I disagree. I don't think it's wrong. I think these situations are simply exclusive. That is, there can't be both: new blocks added and futureBlocks added.
(I was claiming this here: https://bitcointalk.org/index.php?topic=397183.msg4406466#msg4406466)