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

No, the transaction amount as well as the sender's balance have to be positive. Neither is the case in your apocalyptic scenario.

  if someone unllocks genesis account, could they send negative NXT to everone to reduce everyone's balance to zero?

I suggested a similar approach in the other main thread when people wanted to change the fee to a fiat based number. Basically a 'difficulty based' adjustment like in the other cryptocoins but for the transaction fee.

Edit: I would love to share ideas with you. Feel free to PM me if we shouldn't clutter up this thread with that. (Unless that's OK).

Ah, now I found it in the code. cumulative difficulty was the buzzword I needed. Thanks a lot Come-from-Beyond and  ricot.

I just found something else which is at least an inefficiency in the network and could potentially be exploited...

I looked at the cumulative difficulty checks.
When actively querying peers for blocks, the checks seem ok (except for that 720 block issue that we already discussed).
However, when I myself forged a block, I'll call the processBlock methods of my peers to get it into the network.
processBlock doesn't check cumulative difficulty, it just checks if it's the next block (i.e. newBlock.previousBlock == lastBlock).
So if it gets a worse block first, it will ignore the better block coming from me.
This, combined with the "we accept blocks that are 15 seconds into the future" can be exploited:
Say Anna can generate a block that is valid in 15 seconds. She immediately sends it to all peers, which accept that block, obviously.
Poor Bob can generate a block that is valid in 10 seconds, but waits until that time to send out that block.
Now all the peers that Bob sends his superior block to will just ignore it, if they have Anna's block and the only way for Bob to publish his block is to be asked by peers for blocks.
So sending blocks before there's time seems to increase forging chances... I think...

[edit]
Totally forgot to write the solution
Check the cumulative difficulty in a way similar to actively getting blocks from a peer in the passive case.

[edit2]
And here is the attack and the results:
Anna keeps spamming all the peers she knows with her blocks. She probably gets blacklisted by all her peers, but fortunately processBlock doesn't care about that. (slight hint at another thing you might want to fix: the blacklisting isn't checked in a lot of cases)
So Anna will get a block that shouldn't have belonged to her iff:
- her chance to forge that block is at most 15 seconds past the chance of the real block
- the forger of the real block (Bob) sits behind a firewall, so that he can't receive calls from his peers querying him for blocks
- Anna manages to send her block to all of Bob's peers before he does

So it definately increases Anna's chances and the methodology also spams the network. Neither is something you want to have.
To figure out by how much Anna's chances are increased, we'd need to estimate the ratio of blocks forged behind firewalls,
let's say, that's 30%. (I've got no clue about the real number, so feel free to replace it with anything you want)
Anna has a chance to forge 15 seconds longer, at an average 60 second forge duration. This means a 1.25x increase in chance of block generation. Combined with the 30% chance of the other block being forged behind a firewall, Anna can increase her forging chances by 7.5%.
Not much, but definately enough to start spamming the network.

I don't think the genesis account can ever forge, since it's max balance will be zero (if everyone sent their NXT there to be destroyed).

Generally, I think that keeping the genesis account around in this way is a good feature.  It's a way for NXT to be destroyed, decreasing the money supply, if desired.  It's completely up to users if they want to send they NXT there for destruction.  In contrast, I'm not sure forgetting/losing your brainwallet password counts as destroyed money.

It doesn't.

One of the two blocks will have a better cumulative difficulty (comparable to a nonce in BTC) and will "win". So the worse block becomes an orphan and every client just builds on the better block.
This process hsould happen quite often because of network latency and such.

Nodes will see a longer branch and orphane one of the blocks.

And how gets the forked chain joined together again?

This will be determined by the next block.

I think the answer to your next question will make it clear.


I don't say to base it only on the transactions, but to include the transactions as part of the input.  Including the transactions as part of the gen sig would help prevent the security issue proposed by dicot.

But maybe there's something I don't understand about it, which would not be surprising given there's no formal account or whitepaper.

And who gets the fees?

They'll create a fork in a chain of predictions, which is a good thing. This is why block timestamps r seconds, not milliseconds.

Ah, I overlooked that u proposed 2 solutions.

I am new to cryptocurrencies, so please excuse my noob question:

What happens if two distinct nodes forge the same block at the same time (assume both are allowed to, though both blocks are valid)?

There are two solutions.  The first would not convert it to a PoW coin.

The second, again, would not, but it would do away with transparent forging; a sensible thing to do if it's insecure.  Maybe that's what you mean?

The genesis account has a negative balance (because it created the currency supply from a zero balance I suppose).  Peers do not allow accounts with negative balances to transmit NXT.  Makes sense to me.

Ur approach would transform Nxt into a PoW coin.

Yes, if we simple allow to include payload hash to gen sig, we effectively return PoW to Nxt.