Nxt source code flaw reports

[liyi3c]

In getEffectiveBalance()

Code:

if (height == 0) {
				
				return (int)(balance / 100);
				
			}

for GENESIS accounts(stackholder), not minus the last block recipient amounts like other 'normal' account

Code:

for (long transactionId : Block.getLastBlock().transactions) {
				
				Transaction transaction = transactions.get(transactionId);
				if (transaction.recipient == id) {
					
					amount += transaction.amount;
					
				}
				
			}

			return (int)(balance / 100) - amount;

this can leave a chance to genesis accounts to control which one can forge next block.
e.g.
account A has millions of nxt and knows he has a high chance to forge next block B1 by compute his target and compare with his hit
then he can make a transaction immediatly to a 'cooperate' genesis account, maybe choose best one with lowest hit to generate next block B2 after B1.

How can he do that? because account A is B1's generator, and B1 is legit. So A knows B1's generationSig before B1 is confirmed by others,  which can be used to calc next hit with account's secretPhrase, now A have the future hits for his every cooperate genesis account, and just choose the genesis account with the smallest hit, and make a transaction to send his huge nxt to this genesis account. this transaction will be included in B1
After B1 is confirmed by network, the chose one genesis account get his effectbalance which contains all the nxt sent by A just few minutes ago. and generate the next block B2 with a very high possibility.

what's worse is that, once u can predict the next block's generator, u can diverge the block chain by generate twins of B1->B2, let's say them T1->T2 in which u delete one transaction of yours. And both two chains are legit, u can release one(let's say it's B1->B2) with lower cumulativeDifficulty first util the transaction in B1 are confirmed, and release the other one later to override the first one. by doing this, u can revoke your transaction, just like u buy something, pay, and get your money back later!

I think this is a flaw

[Come-from-Beyond]

I think this is a flaw

This is not one of the injected flaws.

PS: getEffectiveBalance algo will be changed in one of the next versions. It still would be interesting to see some math that assess chance of a successful attack.

[liyi3c]

I think this is a flaw

This is not one of the injected flaws.

PS: getEffectiveBalance algo will be changed in one of the next versions. It still would be interesting to see some math that assess chance of a successful attack.

Yes math is more convincing. Fine. let's keep digging. if my understand is right, that's why minus all the receptions in last block, right? or there are some other concerns

[Come-from-Beyond]

if my understand is right, that's why minus all the receptions in last block, right?

Right

[Come-from-Beyond]

Regarding the flaws. They assume that an adversary can build ASICs (which is quite possible) or use a lot of GPUs that used to mine bitcoins and now r not used.

[jl777]

Regarding the flaws. They assume that an adversary can build ASICs (which is quite possible) or use a lot of GPUs that used to mine bitcoins and now r not used.

Like magically being able to modify blocks while maintaining hashes and sending these modified blocks to the network.

[Come-from-Beyond]

Regarding the flaws. They assume that an adversary can build ASICs (which is quite possible) or use a lot of GPUs that used to mine bitcoins and now r not used.

Like magically being able to modify blocks while maintaining hashes and sending these modified blocks to the network.

256-bit is still unbreakable.

[ricot]

Regarding the flaws. They assume that an adversary can build ASICs (which is quite possible) or use a lot of GPUs that used to mine bitcoins and now r not used.

Like magically being able to modify blocks while maintaining hashes and sending these modified blocks to the network.

256-bit is still unbreakable.

You just need to cause a collission of the block ID, which is 64bit.
So if you want to inject a block with a certain transaction somewhere within the last 720 blocks, here's how you do it:
You need a block that you generated, otherwise it's hard to modify.
You add your transaction to that block, the block ID (64bit will change).
To get th correct block ID, you just have to change some parameter in the block that doesn't really matter, e.g. the deadline for your transaction, that you just added.
You do that on an ASIC/GPU. You need a 64bit collission, that's not that hard.
When you have your block, you wait until someone calls you to update his blockchain.
You tell him, that you have a great cumulative difficulty. He'll want to confirm your last common block.
You tell him that your last common block is the one before the modified one. He'll believe you, he doesn't check anything.
When he asks you for the blocks, you send him your modified block. It perfectly fits on the common block, so he'll add it.
Next you send the normal chain, that will also fit perfectly because no ID changed. (You have to make sure, that by moving money around you don't keep someone from being able to generate a block that has already been generated)
You replay the current blockchain until you're at the level that the client was before.
The client will check the cumulated difficulty, which is equal to what he had before, so he'll accept it.
Now we have 2 slightly different blockchains, with different amounts of NXT in the wallets but that look the same in all operations. Because when getting a blockchain, you just check the IDs.

Did you mean that thing as a possible attack vector?

[edit]
How to avoid the whole thing:
Also check the 256bit signatures before accepting stuff.

[edit2]
As for 64bit collission generation: You've got nearly a day to calculate a collission with the rate that blocks are moving at the moment.

[edit3]
If you say the 16bit deadline isn't enough freedom to generate a fitting hash: Just add 3 transactions of 1 NXT to yourself, so you have 3*16bit more freedom.
There are tons of ways to do it, since the payloadHash is part of the block ID.

[Come-from-Beyond]

You just need to cause a collission of the block ID, which is 64bit.

Critical flaw description:

Code:

Only 64 bits of the previous block hash are used. This gives ability to inject blocks with another set of transactions.

SHA256-hash:

Code:

888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530

Looks legit. Where to send 10K to?

[utopianfuture]

You just need to cause a collission of the block ID, which is 64bit.

Critical flaw description:

Code:

Only 64 bits of the previous block hash are used. This gives ability to inject blocks with another set of transactions.

SHA256-hash:

Code:

888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530

Looks legit. Where to send 10K to?

Congrat ricot. Excellent work.

[gsan1]

You just need to cause a collission of the block ID, which is 64bit.

Critical flaw description:

Code:

Only 64 bits of the previous block hash are used. This gives ability to inject blocks with another set of transactions.

SHA256-hash:

Code:

888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530

Looks legit. Where to send 10K to?

LOL, this was too obvious to find. 

[bitcoinpaul]

 

[Come-from-Beyond]

LOL, this was too obvious to find. 

All flaws r obvious. This was the best way to hide them.

[gsan1]

LOL, this was too obvious to find. 

All flaws r obvious. This was the best way to hide them.

So I guess it's time for another hint regarding the serious or fatal flaw, because they were not discussed in this topic before, right? 

[Come-from-Beyond]

So I guess it's time for another hint regarding the serious or fatal flaw, because they were not discussed in this topic before, right? 

Here is the hint:

Fatal flaw wasn't discussed yet. Not sure about the serious one.

[ricot]

*rofl* (Why is there no rofl smiley here???)
That one was really too obvious... I thought about that ages ago and then I thought: Well, that's still quite a lot of computational power you'd need...

Address is in the sig.
Thanks!

[greyw00lf]

You just need to cause a collission of the block ID, which is 64bit.

Critical flaw description:

Code:

Only 64 bits of the previous block hash are used. This gives ability to inject blocks with another set of transactions.

SHA256-hash:

Code:

888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530

Looks legit. Where to send 10K to?

grats ricot!!

[theKnownUnknown]

You just need to cause a collission of the block ID, which is 64bit.

Critical flaw description:

Code:

Only 64 bits of the previous block hash are used. This gives ability to inject blocks with another set of transactions.

SHA256-hash:

Code:

888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530

Looks legit. Where to send 10K to?

Isn't it what I mentioned some time ago? Not in such detail, but this is the flaw that I meant. Here my own quotes:

Is it one of the flaws that blocks do not contain the hashcode of their previous block?

Block class does not contain hashcode of previous block, only block id and pushBlock() does not check anything into this direction. Isn't it possible to modify old blocks afterwards (By the original author of the block)?

[Come-from-Beyond]

Isn't it what I mentioned some time ago? Not in such detail, but this is the flaw that I meant. Here my own quotes:

Is it one of the flaws that blocks do not contain the hashcode of their previous block?

Block class does not contain hashcode of previous block, only block id and pushBlock() does not check anything into this direction. Isn't it possible to modify old blocks afterwards (By the original author of the block)?

Ur guess was based on decompilation of new binaries.

NB: Some guys mentioned that they would just decompile 0.4.7e binaries and compare the source codes to find the flaws. As a countermeasure against such the trick u still must explain why there is a flaw.

[LiQio]

@theKnownUnknown: come on, "not" (0 bit) is not the same as "only part" (64bit) - continue and try to get the 100k bounty!

@ricot: Great work Rico!

@everybody else: I'm trying to brute-force the remaining sha256-hashes that BCNext provided, think it's easier than learning java and becoming a crypto-genius. Anybody interested in creating a mining pool for this?
okay, okay, just kidding here