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

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.

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

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?

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

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.

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.

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

Maybe

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

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

There is no difference.

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 hithit 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?

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

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.

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

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

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.

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.

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...

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.