Nxt source code flaw reports

[msin]

Is anyone offering the service of creating an altcoin based on the algorithm of Nxt?

I'm launching a coin based on Nxt soon. It will use AM and Nxt blockchain. Sources will be written in JavaScript and completely open. (https://bitcointalk.org/index.php?topic=415580.0)

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.

[1713528357]

1713528357

[BloodyRookie]

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

[msin]

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

Of course, thank you

[Come-from-Beyond]

Is it going to be built on top of Nxt, so we can use it within Nxt?  Thanks.

Yes, on top of Nxt using Arbitrary Messages.

[CrazyEyes]

I guess it is not my "birthday", (after some hinting) and i am not going too have my small investment stolen by some 16 year old script kiddie.
Therefore, im creating my own cryptocurrency, whos with me?

It's been repeated hundred of times already, your account is your PK, which is 256bits,
once you do first trasaction, you're safe.

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

[msin]

I guess it is not my "birthday", (after some hinting) and i am not going too have my small investment stolen by some 16 year old script kiddie.
Therefore, im creating my own cryptocurrency, whos with me?

It's been repeated hundred of times already, your account is your PK, which is 256bits,
once you do first trasaction, you're safe.

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

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

[lr127]

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

[Come-from-Beyond]

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

Yes, the same as in Bitcoin.

[ZeroTheGreat]

Sounds like multiverse concept. We already have coins and anticoins, superposition of transactions lost in limbo, event horizon that limits rate of the transactions, time warp of transparent forging...

So another slogan here:

Nxt will blow your mind like quantum mechanics did!

[xyzzyx]

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:

Code: (lines 4749 - 4757)

  int elapsedTime = lastBlock.timestamp + 60;
/* if (elapsedTime > 0) { */

    BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
    if (hits.get(account).compareTo(target) < 0) {

        account.generateBlock(user.secretPhrase);
								
/*   } */

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?

[Come-from-Beyond]

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:

Code: (lines 4749 - 4757)

  int elapsedTime = lastBlock.timestamp + 60;
/* if (elapsedTime > 0) { */

    BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
    if (hits.get(account).compareTo(target) < 0) {

        account.generateBlock(user.secretPhrase);
								
/*   } */

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?

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

[tyz]

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

[Come-from-Beyond]

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

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

[ricot]

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. 

[Come-from-Beyond]

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. 

Good catch. What fix do u propose?

[opticalcarrier]

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. 

Good catch. What fix do u propose?

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

[Come-from-Beyond]

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 would determine which one to make permanent, right?

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

[ricot]

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

[rlh]

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

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?

[Come-from-Beyond]

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

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, just don't forget to reset the key if the block becomes orphaned.