Topic: Nxt source code flaw reports - page 15. (Read 113378 times)

Yes, my assumption would be that the one that "wins" is the first transaction with the matched key that is received by the node that forges the block.  So, you send out 30 transactions, each with different keys, but which ever node forges the inclusive block should only select the first TX that it received, and ignore all of the others.

Make sense?

Yes, the key should only be saved if it's in a block...

Full key is set when a transaction is verified, no matter if it's unconfirmed. Removing key setting in unconfirmed transactions solves this issue.

I may be missing something.  Bob sends out 2 different colliding transactions , but those 2 transactions are still not on the blockchain yet, right?  They are still out there floating around waiting for a forging node to sign them into a block, right?  Wouldnt eventually one make it and the other wouldnt?  Or assuming they both made their way to the forging node for inclusion into the next block, then I guess the forging node should then have to determine which one to make permanent, and which to reject, right?

Or I could just be smart enough to make myself look dumb here, which is most likely the case...

Good catch. What fix do u propose?

It's time for evil Bob to return once again.
Not with the fatal flaw, but still, Bob can cause quite a bit of damage with that...

Our friend Bob has some left-over hardware that is too inefficient to mine BTC, so he decides to wreak havok on the NXT blockchain instead...
He tasks his GPUs with finding 64bit collissions in account numbers. It doesn't matter which account, just that there is a 64bit collission.
Because of the birthday phenomenon that's actually not that hard to do.
When he has found enough collissions, e.g. a few, but it starts to work even with 2, so let's say Bob just found 2, he starts with his evil plan.
He makes 2 transactions and signes each with a different key that results in the same account number.
Then he calls "processTransactions" on all the peers he knows, and sends the first transactions to half the peers, and the second transaction to the other half.
What should happen now?
The network should decide on the public key that gets into the blockchain first and invalidate the other transaction, no problem.
But what actually happens?
Each peer analyses the transaction, sees that there was no transaction from that account before and adds the new public key to the account.
Now half the network has a different public key for the account than the other half.
If now any peer generates a block, the other half of the network will not accept that block, because it knows a different public key for one of its transactions, and we have a nice split of the blockchain that can't be resolved.

If Bob is a bit more patient and waits for a few more collissions (not neccessarily on the same account), he can generate even more separate blockchains and cause some nice chaos. 

2 flaws were found. The fatal flaw with 100K reward is still waiting for u.

Interesting callenge Ill take a closer look to the source code later. Has someone found a flaw yet or are they sill undiscoverd?

This chain will be "shorter" and hence will be rejected.

This might be a silly question 'cause I only just started looking at the Nxt client source and I'm not really familiar with Java, but starting with a null blockchain, couldn't an attacker change program lines 4749-4757 like:


and comment out the "Peer.sendToAllPeers(request);" on line 300.

Wouldn't the modified program in effect be bootstrapping a blockchain with only a genesis block and all empty transaction blocks?  Once the empty blockchain was longer than the network blockchain (and it will be 'cause it's cranking out empty blocks as fast as it can now that we disabled the time check) stop the modified program, then run a good unmodified client on our empty blockchain which would send that empty blockchain to the network?  Since the empty chain is longer, the empty chain would be favored over the network's chain?  Or am I missing something?

So another slogan here:

Nxt will blow your mind like quantum mechanics did!

Yes, the same as in Bitcoin.

Whether there is any sense in the generation of an empty (without transactions) block?

Because we may ultimately need more supply and to use coins for different purpose, not necessarily just to buy things.

Hehe, but seriosly, can not find the "rejection" part, show me Also, why would you create an alt coin of nxt, it is already as good as it gets:D

Humble regards
j0b

Yes, on top of Nxt using Arbitrary Messages.

Of course, thank you

You can use google translater to english, it's good enough to get the main points.

Would it be possible for you to translate (English) your first post, just so we have an idea?  Is it going to be built on top of Nxt, so we can use it within Nxt?  Thanks.

Upon the launch I'll post all info in English.