Nxt source code flaw reports

[Come-from-Beyond]

I checked several accounts and they all showed that unconfirmedBalance equal to the balance. Is unconfirmed balance always the same as the balance? Of course, as the balance decreases, the unconfirmed balance become lower. Is it possible that unconfirmed balance is lower than the balance?

Transactions r confirmed very fast, so it's hard to catch a moment when unconfirmed balance =/= balance.

[Come-from-Beyond]

Lines 634 through 638...


if (senderAccount.publicKey == null) {
                     
                     senderAccount.publicKey = transaction.senderPublicKey;
                     
                  }


Ok...wait a second now... do these lines actually change the sender's publicKey of synchronized transactions?!?!?   


Shouldn't senderAccount be examined here instead of senderAccount.publicKey...

and be assigned the Id information associated to transaction.senderPublicKey if null?

No. This code works when senderAccount can't be null.

[ricot]

Now for the interesting 75% part:
You can calculate in advance, which nonce each of your accounts would have and then choose the best one. So statistically speaking, all your accounts are behaving like accounts with your 0.98% stake in them. And you can freely choose between any of the 100.000 accounts in advance, already knowing the nonce. The chance that one of them has a nonce so good that it's better than all the others is extremely high: If you'd (theoretically speaking) combine all of those 100,000 accounts with 0.98% stake each, you have a stake of 98,000 % (yes, I know, that's more than 100%, but that's the whole point of having the prior knowledge ). So the total stake of the currency for that next block becomes 98,000 % (you) + 99.02 % (others) = 98,099.02 %. Which means, you suddenly own nearly 99.9 % of the stake and have the respective chance of forging that block.

So with that methodology, we have a forging chance of 25%*0.98%+75%*99.9% = 75.17 %.

Good catch. Looks like this trick will work if u r the only one who uses this strategy. Will freezing recently moved coins for 1440 blocks solve the issue?

PS: It's not the injected flaw, but still post ur Nxt account for 10K reward plz.

I guess, changing it to 1440 would even be overkill.
The 1% stake holder would have to give up a 63% chance to generate a block to attempt this. To cover his losses, he would have to predict next transactions with a certainty of 99.97%. And that's just to cover his losses, to actually gain something, he'd have to be even more precise.
I can't see anyone keeping a prediction rate of 99.97% each up for more than a few transactions. Doing so for 1440 transactions is impossible. Further, he'd only have the chance to get 1 block per day(?) now, which makes it even more hideous to even try.

Thanks for the reward!
13388990392070382939

[ImmortAlex]

Lines 634 through 638...


if (senderAccount.publicKey == null) {
                     
                     senderAccount.publicKey = transaction.senderPublicKey;
                     
                  }

This is just setting publicKey of account from it's first output transaction.
It was noted several times that publicKey became known in blockchain only after first output transaction. Before that you can try to find key that match account ID but doesn't match secret passphrase of original account holder.

[xibeijan]

Now for the interesting 75% part:
You can calculate in advance, which nonce each of your accounts would have and then choose the best one. So statistically speaking, all your accounts are behaving like accounts with your 0.98% stake in them. And you can freely choose between any of the 100.000 accounts in advance, already knowing the nonce. The chance that one of them has a nonce so good that it's better than all the others is extremely high: If you'd (theoretically speaking) combine all of those 100,000 accounts with 0.98% stake each, you have a stake of 98,000 % (yes, I know, that's more than 100%, but that's the whole point of having the prior knowledge ). So the total stake of the currency for that next block becomes 98,000 % (you) + 99.02 % (others) = 98,099.02 %. Which means, you suddenly own nearly 99.9 % of the stake and have the respective chance of forging that block.

So with that methodology, we have a forging chance of 25%*0.98%+75%*99.9% = 75.17 %.

Good catch. Looks like this trick will work if u r the only one who uses this strategy. Will freezing recently moved coins for 1440 blocks solve the issue?

PS: It's not the injected flaw, but still post ur Nxt account for 10K reward plz.

Surely the solution to the flaw entitles me to some NXT as well.

Reference: https://bitcointalk.org/index.php?topic=397183.msg4307059#msg4307059

[klee]

Don't worry FreaktionLess I have hired some of the best developers (who happen to be my friends too) to make this brilliant innovative algorithm into a real software project (along of course with Jean-Luc who is the leader dev atm).

See you around I hope to review their code too

Glad to read that! When do they get on board and who is paying for them?

They are almost a week on board (2 devs + 1 IT + maybe 1 more dev) and I pay for them...

My devs that are helping Jean-Luc:
http://www.linkedin.com/pub/vasilis-kokkinidis/5/222/444
http://gr.linkedin.com/pub/grigoris-grigoriadis/22/a8a/b80

I hope I will persuade another one to join.

I think we also need in the dev team asap the following: xibeijan, ImmortAlex (part time maybe) and rlh.

[ImmortAlex]

Surely the solution to the flaw entitles me to some NXT as well.

Yep! Those who see only flaws - they sells. Those who see solutions - we buy.

[rlh]

Surely the solution to the flaw entitles me to some NXT as well.

Yep! Those who see only flaws - they sells. Those who see solutions - we buy.

Double-yep... up until now, Nxt has been my "High Risk" investment of choice.  It's moved up a notch to just a "Risk".

This is because it's new and there is always a chance that this thing could get Luke-Jr'd like many of the early alt-coins.

[xibeijan]

Yeah, this thread has been great so far.  Great progress is being made.

[FrictionlessCoin]

Perhaps you can try to solve it analytically and get an equation?

No. It should take into account non-formalized variables like network topology.

Man you are really full of it.

[FrictionlessCoin]

Fair enough, but you still might be able to get a bound without these variables, no?  Could be helpful.

No. Nxt protocol uses some tricks to add as many non-formalized factors as possible.

Why?   Does this preclude a formal description or whitepaper?

That's just some B.S. that we'll hack into the protocol as we make it up.

[ImmortAlex]

Surely the solution to the flaw entitles me to some NXT as well.

Yep! Those who see only flaws - they sells. Those who see solutions - we buy.

Double-yep... up until now, Nxt has been my "High Risk" investment of choice.  It's moved up a notch to just a "Risk".

This is because it's new and there is always a chance that this thing could get Luke-Jr'd like many of the early alt-coins.

Early altcoins are highly vulnerable to 51% PoW attack. Nxt is not.
Early altcoins are mostly pump-n-dump shitcoins, lost userbase quickly. Nxt is not.
Nxt was highly vulnerable to zombie attack. Today situation is much better.
Even more, I see developer's position like "Welcome, Luke-Jr, and please test us". And I like it.
And if there's some flaws in algorythms, then we have this topic

[xibeijan]

Now for the interesting 75% part:
You can calculate in advance, which nonce each of your accounts would have and then choose the best one. So statistically speaking, all your accounts are behaving like accounts with your 0.98% stake in them. And you can freely choose between any of the 100.000 accounts in advance, already knowing the nonce. The chance that one of them has a nonce so good that it's better than all the others is extremely high: If you'd (theoretically speaking) combine all of those 100,000 accounts with 0.98% stake each, you have a stake of 98,000 % (yes, I know, that's more than 100%, but that's the whole point of having the prior knowledge ). So the total stake of the currency for that next block becomes 98,000 % (you) + 99.02 % (others) = 98,099.02 %. Which means, you suddenly own nearly 99.9 % of the stake and have the respective chance of forging that block.

So with that methodology, we have a forging chance of 25%*0.98%+75%*99.9% = 75.17 %.

Good catch. Looks like this trick will work if u r the only one who uses this strategy. Will freezing recently moved coins for 1440 blocks solve the issue?

PS: It's not the injected flaw, but still post ur Nxt account for 10K reward plz.

Wait a minute.... another possibly better solution could be for the generation signature to include a hash of the transactions contained in the block.

1) Suppose you've forged the current block B1 with account a1, but have not broadcast it.
2) Next, you compute corresponding generating signature sig(B1).
3) From this, you calculate the subordinate account a2 (one of your 100 pre-generated accounts) that generates the next block B2.
4) However, the transaction to move your NXT stake from a1 -> a2 (so you are able to solve B2) must to be part of B1.
5) So, you need to update the current block C with transaction a1 -> a2 and re-generate the generating sig(B1).
6) However, you've now changed B1, so you need to goto step (3) and repeat the process.

Thus, we have thwarted the adversary with a chicken-or-egg/halting-problem kind of puzzle.

Does this work as a solution?

Maybe a hash of the transactions is already included in the generation signature, in which case there was no issue in the first place.

Also, https://bitcointalk.org/index.php?topic=397183.msg4307553#msg4307553 seems to indicate that my earlier recollection that there is a 1440 block forging penalty for transferred coins is true.

In essence it works by having the author of the next block be selected by comparing the public key that he is using to hold his stake to the public key of the author of the previous block. In-order to prevent the new block author from simply creating a public key that would win and loading that public key with his stake BTCNext introduced the idea of effective stake. Only stake that has remained stationary for 1440 blocks (24 hours) has the right to author a block. Would be attackers can not calculate 1440 blocks into the future because they have no idea who is going to author the very next block, let alone the next 1440 blocks. Inorder to prevent an attacker from creating a "trap" where if he manages to become lucky enough to author one block in the future than he has prepared a set of funded addresses which would "catch" the subsequent blocks, we don't only rely on the previous block authors signature alone, but build an entirely separate "block chain" which is the result of hashing every public key ever used to author a block.

However, the source code defines getEffectiveBlance() with

...
         if (Block.getLastBlock().height - height < 1440) {

            return 0;

         }
...

which seems to imply the 1440 penalty is on the account, rather than on the NXT balance.

Could someone please confirm whether either of my two solutions work and whether they are already, in fact, implemented in the latest source code?

[rlh]

Surely the solution to the flaw entitles me to some NXT as well.

Yep! Those who see only flaws - they sells. Those who see solutions - we buy.

Double-yep... up until now, Nxt has been my "High Risk" investment of choice.  It's moved up a notch to just a "Risk".

This is because it's new and there is always a chance that this thing could get Luke-Jr'd like many of the early alt-coins.

Early altcoins are highly vulnerable to 51% PoW attack. Nxt is not.
Early altcoins are mostly pump-n-dump shitcoins, lost userbase quickly. Nxt is not.
Nxt was highly vulnerable to zombie attack. Today situation is much better.
Even more, I see developer's position like "Welcome, Luke-Jr, and please test us". And I like it.
And if there's some flaws in algorythms, then we have this topic

Well, my point was that some crafty/smart developer could spend months looking over this implementation, find a critical flaw and then initiate an exploit.

I don't know Luke-Jr, personally, but during the early days of BTC alts, he was one of the few that did us all a "favor" by being part of core group of guys who exploited coins so they would either get fixed or get out of the way.

Personally, for Nxt to become less "risky", it needs to have continual community growth and be put to use for about one full year.  I'm less worried about what we know and more concerned about what we don't know (i.e. have yet to discover.)  Granted, Nxt is similar enough to BTC that I don't see much in the way of "new" exploits but you don't if there is some deep, hidden flaw until someone fines it.  Still, we're talking about money here and nothing that is new should NOT be considered anything less than a risk until it has been excessively vetted, which is the point of this exercise.

Anyway, this is getting to be off topic.  Sorry for gunking up the discussion.

[ImmortAlex]

another possibly better solution could be for the generation signature to include a hash of the transactions contained in the block.

You're closer and closer to original bitcoin algo
AFAIK there's no generation sig in bitcoin block header, just header hash which miner need to find. And that hash "includes" everything.

Maybe a hash of the transactions is already included in the generation signature, in which case there was no issue in the first place.

As far as I can see transactions aren't included in generation signature. There's just payload hash in block header, which doesn't influent to anything.

[xibeijan]

another possibly better solution could be for the generation signature to include a hash of the transactions contained in the block.

You're closer and closer to original bitcoin algo

Maybe a hash of the transactions is already included in the generation signature, in which case there was no issue in the first place.

As far as I can see transactions aren't included in generation signature. There's just payload hash in block header, which doesn't influent to anything.

Well, though that would be similar to bitcoin it's still proof-of-stake, just a potentially improved proof-of-stake.

[ImmortAlex]

Well, though that would be more similar to bitcoin it's still proof-of-stake, just a potentially improved proof-of-stake.

Definitely.
But gen sig must be simple and deterministic for TF, so it can't contain payload hash.

[xibeijan]

Well, though that would be more similar to bitcoin it's still proof-of-stake, just a potentially improved proof-of-stake.

Definitely.
But gen sig must be simple and deterministic for TF, so it can't contain payload hash.

That's life, full of tradeoffs.  Security versus performance.

Nevertheless, it seems like my other solution of a 1440 block forging penalty on transferred NXT could work.  As, ricot suggested, we could probably get away with less than 1440.

However, 1440 could make forging a lot more interesting for low-balance miners (since less of the currency supply would be active for forging when tx volumes are high).

[ImmortAlex]

Nevertheless, it seems like my other solution of a 1440 block forging penalty on transferred NXT could work.  As, ricot suggested, we could probably get away with less than 1440.

Oh yes, and to have ability to determine age of coins from different transactions separately, we need to introduce... hmmm... kinda surrogate of what called "input" in bitcoin

[ricot]

Including any transaction hash into the signature would be quite messy and opens exploits that leave out or generate additinal transactions to influence the signature in their favor.

Since there already seems to be some kind of "design doc" that states that cash has to be stationary for a day to start forging, we could just fix the wrong implementation in the code...