Nxt source code flaw reports

[jl777]

http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt has the outline of the NXT Whitepaper

It has a lot of holes, especially the technical details about how exactly the NXT protocol works at the detailed low level.

I am sure that the regulars on this thread can quickly beef up the missing details and do a much better job than what is there now. Much better.

I also think there are a few missing sections.

Often when I am stumped on a deep technical problem (like finding these injected flaws), I find that switching to english and writing out how it works clarifies things in my mind. Maybe you will get a flash of insight as you describe in detail in the whitepaper wiki.

Please help. I think the wiki magically calculates everybody's contribution and there seems to be some sort of significant bounty attached to this. This way, even if you don't find injected flaw, you can at least get part of whitepaper bounty.

James

[1715359078]

1715359078

[1715359078]

1715359078

[1715359078]

1715359078

[1715359078]

1715359078

[1715359078]

1715359078

[ricot]

So by design the founders have the ability to increase their forging chances 73-fold???
Then this currency is dead

They don't have this ability. Use math and u'll see why.

I already pointed out an attack using multiple accounts to increase forging because you only had to predict one forge before the money becomes valid. If it becomes valid right away, you don't even need to predict anything.
You can see before creating your block, which of the other founder's accounts will have the best chance at forging the next, and send the money there in the block that you are forging.
Should I do the calculations for you again that I already did?

Why aren't all accounts equal? (Bare the genesis account, of course)

[Come-from-Beyond]

Should I do the calculations for you again that I already did?

No need. We analyze the code without TF. With TF most of these problems disappear.

Why aren't all accounts equal? (Bare the genesis account, of course)

We needed special accounts coz in the beginning someone had to forge blocks. In ~5K blocks we r switching to next phase of TF when all the accounts r equal.

[ricot]

In ~5K blocks we r switching to next phase of TF when all the accounts r equal.

That's what I wanted to hear

[ZeroTheGreat]

I can't answer all the questions, coz this may reveal the flaw. Sorry.

4546: if (Block.getLastBlock().height - blocks.get(commonBlockId).height < 720) {

Should be >= 720, right? Other way network'll die with peers being stucked in second half of the first day: no next blocks'es requests. As I understood.

Upd: corrected line number.

[gimre]

I can't answer all the questions, coz this may reveal the flaw. Sorry.

4633: if (Block.getLastBlock().height - blocks.get(commonBlockId).height < 720) {

Should be >= 720, right? Other way network'll die with peers being stucked in second half of the first day: no next blocks'es requests. As I understood.

Certainly NOT. This is there to make sure we won't change "older" blocks

[ZeroTheGreat]

If we look at line 4633 (I was wrong about number in previous post):

if (!futureBlocks.isEmpty() && Block.getLastBlock().height - blocks.get(commonBlockId).height < 720) {

It seems like prohibiting deep reorg condition before "synchronized".

But 4546...

[Come-from-Beyond]

If we look at line 4633 (I was wrong about number in previous post):

if (!futureBlocks.isEmpty() && Block.getLastBlock().height - blocks.get(commonBlockId).height < 720) {

It seems like prohibiting deep reorg condition before "synchronized".

But 4546...

The same, this limits depth to 720 blocks.

[ZeroTheGreat]

So what's the reason? There was some deleted code?

Maybe

Stopping of generating blocks from height 20001 cos signatures'll stay unverified by condition?

1250:      boolean verifyGenerationSignature() {
1251:         
1252:         try {
1253:            
1254:            if (getLastBlock().height <= 20000) {

Why was answered undirect answer? It doesn't seem like a serious flaw.

[Come-from-Beyond]

So what's the reason? There was some deleted code?

Maybe

Stopping of generating blocks from height 20001 cos signatures'll stay unverified by condition?

1250:      boolean verifyGenerationSignature() {
1251:         
1252:         try {
1253:            
1254:            if (getLastBlock().height <= 20000) {

Why was answered undirect answer? It doesn't seem like a serious flaw.

Well, I can't answer some questions that r close to the injected flaws. But sometimes I don't answer the other questions so u can't find a pattern.

[ZeroTheGreat]

I see )

[gimre]

So what's the reason? There was some deleted code?

Maybe

Stopping of generating blocks from height 20001 cos signatures'll stay unverified by condition?

1250:      boolean verifyGenerationSignature() {
1251:         
1252:         try {
1253:            
1254:            if (getLastBlock().height <= 20000) {

Why was answered undirect answer? It doesn't seem like a serious flaw.

there is else block below. This (split into if<=20000) was probably done when alias system was added to the code

[ricot]

I just posted a proposal to fix the account number typo-problem over at the official forums:
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524 <- making NXT account numbers awesome!

What do you think about that?

[aorith]

I just posted a proposal to fix the account number typo-problem over at the official forums:
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524 <- making NXT account numbers awesome!

What do you think about that?

Looks good, waiting to see the code!

[ricot]

Looks good, waiting to see the code!

Just updated the original post at nxtcrypto.

[opticalcarrier]

I just posted a proposal to fix the account number typo-problem over at the official forums:
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524 <- making NXT account numbers awesome!

What do you think about that?

thanks for posting that there.  I went to the alt-client forum there and asked all the devs there who have done their own client to implement this.

lol think of the possibilities of vanity accounts with alphanumeric!  actually, probably not many.  the forward error correction would most likely prohibit most words from being used

[msin]

Nice work ricot, sounds like a great option.

[getfun12345]

The API "broadcastTransaction"  doesn't check the transaction is valid.
If attacker send a transaction with large size, the transaction will be broadcasted to all peers, and the network will stuck.

[Come-from-Beyond]

The API "broadcastTransaction"  doesn't check the transaction is valid.
If attacker send a transaction with large size, the transaction will be broadcasted to all peers, and the network will stuck.

It won't be broadcasted to all peers. Peers validate transactions.

[getfun12345]

The API "broadcastTransaction"  doesn't check the transaction is valid.
If attacker send a transaction with large size, the transaction will be broadcasted to all peers, and the network will stuck.

It won't be broadcasted to all peers. Peers validate transactions.

But the public node who received this huge transaction, will busy to broadcasting it, can't do anything else.
The attacker can cause more damage by using less data. Depends on the peers connected to this public node.