Nxt source code flaw reports

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

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.

I had thought this was Proof of Stake,  so the bigger the stake of the miner, the bigger the reward.

[Come-from-Beyond]

First problem: 720 is a really arbitrary number. Why that one?

Just a magic number.

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?

That's right. Without Transparent Forging this indeed should isolate part of the nodes. But this is not an injected flaw.

[ricot]

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.

He does have a point:
When it's your turn to generate a block, you can include a transaction to one of your other accounts. The receiving account could be the one that has the highest chance of generating the following block (because you can calculate that beforehand). If you fail, you didn't loose anything. But you do increase your chances of generating blocks. This could be a big problem!

[ImmortAlex]

I had thought this was Proof of Stake,  so the bigger the stake of the miner, the bigger the reward.

The bigger the stake of the miner, the bigger the chance to get reward, and reward is transactions fee.

[Come-from-Beyond]

But you do increase your chances of generating blocks. This could be a big problem!

Actually not, add some math and u'll see why.

[vamdor]

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.

No, we can't. Someone in the chain up to our expected block may fall off the network and not publish their block, changing everything afterwards. (if I understand the system correctly)

On the other hand if we can, then it's possible to "mine" an address 1440 blocks ahead and grab a block. Also if only one or two users stop participating in the next 1440 blocks, we can adjust our "mining" algorithm for that too, especially if we do some data mining to see which accounts are "reliable block generators" and which are not. And this may actually be a problem with enough users playing greedily and optimally.

[vamdor]

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.

Instead of running simulations I did the math and the effect is much smaller than I expected. For example someone having 33% stake can get up to 36% of the blocks if the rest of the network are many small non-colluding participants.

[ricot]

But you do increase your chances of generating blocks. This could be a big problem!

Actually not, add some math and u'll see why.

Ah, I see, because you subtract the amount I got in the last block, so I'd have to wait a block and that kills the odds...


But to my other issue:
If you can setup plausible looking fake nodes so easily and cause a blockchain split, users will loose trust in the system...
Why is that 720 block limit even in place? without that, this angle of attack couldn't happen...

[Come-from-Beyond]

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.

Instead of running simulations I did the math and the effect is much smaller than I expected. For example someone having 33% stake can get up to 36% of the blocks if the rest of the network are many small non-colluding participants.

Could u post ur math plz?

[ImmortAlex]

No, we can't. Someone in the chain up to our expected block may fall off the network and not publish their block, changing everything afterwards. (if I understand the system correctly)

Yes, every time we have changes in blockchain (new last block, or reorganizing the chain) we need to recalculate hit and target. At the same time we can precisely calculate time when we can generate block and again start to wait: time will pass or block(s) from other nodes will arrive.
I mean: we have no need to do calculations every second, or when transactions arrive or in any other conditions except changing blockchain.

[vamdor]

That's right. Without Transparent Forging this indeed should isolate part of the nodes. But this is not an injected flaw.

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

[gsan1]

Code:

String announcedAddress = (String)request.get("announcedAddress");
if (announcedAddress != null) {
							
    announcedAddress = announcedAddress.trim();
    if (announcedAddress.length() > 0) {

        peer.announcedAddress = announcedAddress;
								
    }
							
}
if (peer != null) {

If announcedAddress is not null, it adds it as a member variable to object peer. Afterwards it checks if peer is not null. Could there be a null pointer exception? Or is announcedAdress only not null when peer is not null?

[Come-from-Beyond]

But to my other issue:
If you can setup plausible looking fake nodes so easily and cause a blockchain split, users will loose trust in the system...
Why is that 720 block limit even in place? without that, this angle of attack couldn't happen...

It's kind of an automatic checkpointing.

[Come-from-Beyond]

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

This can be done in PoW too.

[ricot]

But to my other issue:
If you can setup plausible looking fake nodes so easily and cause a blockchain split, users will loose trust in the system...
Why is that 720 block limit even in place? without that, this angle of attack couldn't happen...

It's kind of an automatic checkpointing.

But it doesn't work like a check-pointing... it just gives an angle of attack on the network and I can see no benefit at all...

[vamdor]

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

This can be done in PoW too.

No. In PoW the cumulative work clearly decides the valid branch, there is no option that you see two branches and can't decide which one is the "real one" accepted as the consensus.

[Come-from-Beyond]

Code:

String announcedAddress = (String)request.get("announcedAddress");
if (announcedAddress != null) {
							
    announcedAddress = announcedAddress.trim();
    if (announcedAddress.length() > 0) {

        peer.announcedAddress = announcedAddress;
								
    }
							
}
if (peer != null) {

If announcedAddress is not null, it adds it as a member variable to object peer. Afterwards it checks if peer is not null. Could there be a null pointer exception? Or is announcedAdress only not null when peer is not null?

Looks like a non-critical bug, I'll check it, thx. This is not the flaw.

[vamdor]

Could u post ur math plz?

Now I won't be at my computer for a while but I will clean it up and post later.

[Come-from-Beyond]

But it doesn't work like a check-pointing... it just gives an angle of attack on the network and I can see no benefit at all...

The code was written with TF in mind. When TF is on it's supposed to work as a checkpoint.

[Come-from-Beyond]

No. In PoW the cumulative work clearly decides the valid branch, there is no option that you see two branches and can't decide which one is the "real one" accepted as the consensus.

Sorry, I disagree. U can see 2 branches with 2000 blocks each and u won't be able to decide which branch is legit.