Nxt source code flaw reports

[vamdor]

- There are somewhere else some additional rules to make the scheme actually secure that I haven't found.

Scheme, proposed by BCNext, is a straightforward simulation of PoW. Each coin is just a small mining rig. Other PoS schemes work in other way and require workarounds based on PoW.

I don't think anyone can answer his concerns unless he's specific about what he's concerned about.

I am concerned about a single entity completely taking over the block generation.

I found one more line of importance that I didn't see originally: in line 288 the hash of a new block is only determined by the hash of the previous block and the pubkey of the account creating the new one.

Now I think I understand the thought process, but I would have preferred to read it from the creator in their own words. I still feel that this requires a formal proof that it can't be gamed (not even by a large enough stake), and it's far from convincing.

[1714670849]

1714670849

[1714670849]

1714670849

[Come-from-Beyond]

Now I think I understand the thought process, but I would have preferred to read it from the creator in their own words. I still feel that this requires a formal proof that it can't be gamed (not even by a large enough stake), and it's far from convincing.

Satoshi did publish his whitepaper regarding Bitcoin but 4 years later another guy found a flaw in his design (Selfish Mining). I doubt a formal proof will help a lot, but u could try to prove him wrong...

[vamdor]

Now I think I understand the thought process, but I would have preferred to read it from the creator in their own words. I still feel that this requires a formal proof that it can't be gamed (not even by a large enough stake), and it's far from convincing.

After 10 more minutes of thinking, I am pretty sure that if everyone plays optimally the ratio of blocks generated by a single entity or a group of colluding entities is not linearly proportional to their stakes. And I feel that this may just be one of the weaker statements and there may be bigger problems here.

The creators really have to disclose their research backing this PoS scheme.

[Come-from-Beyond]

Now I think I understand the thought process, but I would have preferred to read it from the creator in their own words. I still feel that this requires a formal proof that it can't be gamed (not even by a large enough stake), and it's far from convincing.

After 10 more minutes of thinking, I am pretty sure that if everyone plays optimally the ratio of blocks generated by a single entity or a group of colluding entities is not linearly proportional to their stakes. And I feel that this may just be one of the weaker statements and there may be bigger problems here.

The creators really have to disclose their research backing this PoS scheme.

Valid assumption. U could follow my way - try to create a model and run it. My results show that max difference in number of forged blocks between Alice owning 1M of coins and million Bobs with 1 NXT each is less than 1/1000 of the normalized base target.

[gsan1]

I wonder if the flaws are visible when doing a blackbox test
Or are this intern bugs that are not visible to the outside?

[Come-from-Beyond]

I wonder if the flaws are visible when doing a blackbox test
Or are this intern bugs that are not visible to the outside?

I'm not allowed to answer, that would be too easy

[gsan1]

I wonder if the flaws are visible when doing a blackbox test
Or are this intern bugs that are not visible to the outside?

I'm not allowed to answer, that would be too easy

Thought that 
The source code does not include the alias system. Is this why the last block I am getting is 22.000?
I thought it would go up to 30.000, because than version 2 started.

[Come-from-Beyond]

I wonder if the flaws are visible when doing a blackbox test
Or are this intern bugs that are not visible to the outside?

I'm not allowed to answer, that would be too easy

Thought that 
The source code does not include the alias system. Is this why the last block I am getting is 22.000?
I thought it would go up to 30.000, because than version 2 started.

Aye, u can't pass block 22001 coz of removed AS.

[ImmortAlex]

(2) and (3) are more interesting. The algorithms seems to be the straightforward PoS: From the previous block it creates a hash. Each second it creates a (hash('time elapsed since last block' ,  'own account key') * 'amount of coins on account') which it calls "target", and that determines whether the account has the right to create a new block or not. Additionally 'amount of coins' is zeroed out if the account has created a block within the last 1440 blocks.

I spent only around 30 mins reading the code, so at this point there are three options:
- There are somewhere else some additional rules to make the scheme actually secure that I haven't found.
- This is one of the purposefully injected bugs.
- The PoS is insecure and doesn't even attempt to address the issues that prompted the creators of other coins (such as peercoin) to also incorporate PoW to fix the shortcoming of PoS.

I'm looking through Block.verifyGenerationSignature() method now...

1. block.generationSignature is just 64 byte generated from prev block generationSignature and account's secretPhrase. This sig doesn't depends on anything else: it strictly defined for each block and for each account. Only lowest 8 byte (hit variable) used for comparision with target.

2. target is baseTarget * effectiveBalance * (block.timestamp - lastBlock.timestamp)
baseTarget = prevBaseTarget * (currTime - lastBlock.timestamp) / 60

If I understand everything correctly, with this formula we don't need to check hit<target every second. We know beforehand when we can generate every block, and can sleep until this time or until someone generate this block and we will need to recalculate hit and target.

What was new for me, is that target doesn't directly depend on time your previous generation. There's no "coin days" like in PPC or NVC.
That's why famous "You can generate next block in" is changing that much every time.

PS: someone tell me, am I blind, or there's no difference in if-else branches in this method?

[Come-from-Beyond]

PS: someone tell me, am I blind, or there's no difference in if-else branches in this method?

There is no difference.

[ImmortAlex]

PS: someone tell me, am I blind, or there's no difference in if-else branches in this method?

There is no difference.

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

[FrictionlessCoin]

I wonder if the flaws are visible when doing a blackbox test
Or are this intern bugs that are not visible to the outside?

I'm not allowed to answer, that would be too easy

Because you did not do any black box testing.  The code is not designed to be testable.

[Come-from-Beyond]

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

Maybe

[Come-from-Beyond]

Because you did not do any black box testing.  The code is not designed to be testable.

U already said this a few pages ago. Any new info?

[FrictionlessCoin]

What was new for me, is that target doesn't directly depend on time your previous generation. There's no "coin days" like in PPC or NVC.

No coin days,  so miners can game the system since with what they call 'transparent mining'  they know beforehand if it is there turn to mine,  so they can move around their coins to the miner that is going to get its turn.

So to game this system, you have a bunch of say N miners and then you have a balance of M that you move around to the miner that will be mining next. So effectively you get N*M more profitability.

[FrictionlessCoin]

Because you did not do any black box testing.  The code is not designed to be testable.

U already said this a few pages ago. Any new info?

Still waiting for the spec. from your folks.

Quit acting like you know anything because clearly this exercise is just a farce to get people to analyze your code for free.

BTW... may be you can show a glimpse of the test code that you used to test this system.     I am betting that you don't have anything to show,  so you actually won't have a response to this request.

[Come-from-Beyond]

Still waiting for the spec. from your folks.

Quit acting like you know anything because clearly this exercise is just a farce to get people to analyze your code for free.

BTW... may be you can show a glimpse of the test code that you used to test this system.     I am betting that you don't have anything to show,  so you actually won't have a response to this request.

As I said upthread, create a special thread for that and post link here.

[ricot]

I've got a bit of an issue with the following part:
When getting blocks from another peer, you only look at them if the cumulated difficulty is higher than what you have (which is as expected) AND the last common block of the both of us is less than 720 blocks away from my latest known block.
First problem: 720 is a really arbitrary number. Why that one?
Second problem: (and that's the bigger one )
Suppose, I had the chance to generate a block, but I didn't. After some time, someone else generates a block and the blockchain moves normally.
Now I generate my (valid) block in secret and also generate 720 more blocks with a (smaller) network of accounts. (In the same time the "real" blockchain could be quite a bit longer)
Now it's time to wreak a bit of havoc on the network:
Suppose I have access to one of the hardcoded peers of the client. (Maybe I hacked it or I'm just a malicious admin, or I told people to use my server when their client doesn't sync, etc...)
Now I get a request from a "victim", asking for my cumulativeDifficulty.
I reply with the cumulative difficulty of my forked blockchain.
If the client already got most of the "real" blockchain, he will just ignore my response and think I'm just not up to date, can't influence that guy.
If the client is new and doesn't know the "real" blockchain (or just an older version of it), it will get all the blocks from me.
If the client now asks another "valid" peer for his cumulated difficulty, the peer will give him a higher number, but the response (i.e. the "real" blockchain) will be ignored, because the forked blockchain was forked more than 720 blocks ago.
The "victim" doesn't see anything wrong, there are valid blocks, valid transactions, all looks pretty ok. (There are some invalid transactions because the transaction fees all went into my accounts because I forged all the blocks in my forked block chain and other accounts might not have enough balance anymore, but that shouldn't matter here)
The "victim" now is happy to have a synced client, and sees his wallet with a plausible amount of money and starts forging blocks himself.
These blocks get accepted by all nodes in my forked blockchain, and the "victim" nodes get blacklisted by nodes that have the real block chain.
Now to the problem of making the forked blockchain look legit by replicating most transactions that happen on the real blockchain (and vice versa):
From the pov of a victim node, the real node doesn't get blacklisted instantly (i.e. there is no "else blacklist" to the "if common diff < 720), so the victim will continue (at least for a while) sending transactions to the real network.
Further, with the (few or even single) nodes under my control, I can find out, which peer is on which blockchain and forward transactions appropriately without being blacklisted.
Now we have 2 (kindof) separate networks, that function in parallel and cause a lot of confusion. And I got 720 blocks of fees and some alone-time to do some transactions.

What did I miss?

[FrictionlessCoin]

Still waiting for the spec. from your folks.

Quit acting like you know anything because clearly this exercise is just a farce to get people to analyze your code for free.

BTW... may be you can show a glimpse of the test code that you used to test this system.     I am betting that you don't have anything to show,  so you actually won't have a response to this request.

As I said upthread, create a special thread for that and post link here.

As I suspected,  no tests.  Thank you for the confirmation.

[ImmortAlex]

What was new for me, is that target doesn't directly depend on time your previous generation. There's no "coin days" like in PPC or NVC.

No coin days,  so miners can game the system since with what they call 'transparent mining'  they know beforehand if it is there turn to mine,  so they can move around their coins to the miner that is going to get its turn.

So to game this system, you have a bunch of say N miners and then you have a balance of M that you move around to the miner that will be mining next. So effectively you get N*M more profitability.

Mmm... Can't understand, why I need to move my M coins from one of my miner to another?
Transparent mining just allow me to give transaction fee to desired account, if it is on mining.