Pages:
Author

Topic: Nxt source code flaw reports - page 12. (Read 113312 times)

legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
January 25, 2014, 11:10:48 AM
I have not see in code check interval for discard block or account as waiting many more time necessary

It may not have been introduced yet (the "transparent forging" stuff is being introduced one step at a time).

Basically though if you have your chance to forge but "delay" then you will be punished by not being able to forge for x blocks after.
legendary
Activity: 1918
Merit: 1190
January 25, 2014, 11:06:23 AM
I lose what ? If not interested quality of network ? only interest by profit

I have not see in code check interval for discard block or account as waiting many more time necessary

Edit:Personnal i have interest by quality of network .And commit my reflexion and not used exploit ( not proved )
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
January 25, 2014, 11:04:43 AM
You have two choice:
Get 0 Fee now
Or waiting for get fee

If you "wait" then you *lose* your chance to forge (timing is an essential part of the way it works).
legendary
Activity: 1918
Merit: 1190
January 25, 2014, 11:00:26 AM
Is perfect for next question.

I can now forge next block with 0 Transaction.


You have two choice:
Get 0 Fee now
Or waiting for get fee

What your choice ?
hero member
Activity: 687
Merit: 500
January 25, 2014, 10:54:49 AM
No perl, the transaction data is totaly uncorrelated to the generation signature of a block.
legendary
Activity: 1918
Merit: 1190
January 25, 2014, 10:20:34 AM
Ok for my, génération signature need secret .
Probleme as need one requirement ( I forge regular current block )


The id block use transactions for generated directly or not direcly (previousBlock) ?
If yes , probleme is present.


If account can forge the current block then account can make block for high scoring of next block


Resultat
If can forge one block  
I can forge next block

Fee on inject transaction is return by minning POS
And bonus, I have make free alias



And if blockSignature not include transaction.
I can inject transaction in block
legendary
Activity: 866
Merit: 1002
January 25, 2014, 09:54:06 AM

With this, I can make transaction for the next block with very good scoring for me for next lastblock

n-1 = last block forge
n = the current block in the forge
n +1 = The block I want to forge

1.) I predicted account that will forge the current block (n)
2.) I compute 100 000 or more transaction a include in the current block ( Transaction Alias per ex ).
3.) I choice best transaction need commited  for make scoring current block in the forge best for me
     Now ,  I am the person forge the next (n +1)
4.) return 2 or 1 if not success


a) doing transactions will probably lower your chance for forging
b) I assume, you've meant, that someone ELSE forged block "n", if so, how are you going to predict, what was generationSignature for that block...?
hero member
Activity: 687
Merit: 500
January 25, 2014, 09:50:04 AM
No perl, the transaction data is totaly uncorrelated to the generation signature of a block.
legendary
Activity: 1918
Merit: 1190
January 25, 2014, 09:07:44 AM
Question of transparent forge

If I understand correctly:

The calculation to see if i can build the next block is make from all data in the last block?

All transaction include in lastblock impact scoring ?

I have ammount and public key for all nodes connected !

I can estimate the next account forge next block !


With this, I can make transaction for the next block with very good scoring for me for next lastblock

n-1 = last block forge
n = the current block in the forge
n +1 = The block I want to forge

1.) I predicted account that will forge the current block (n)
2.) I compute 100 000 or more transaction a include in the current block ( Transaction Alias per ex ).
3.) I choice best transaction need commited  for make scoring current block in the forge best for me
     Now ,  I am the person forge the next (n +1)
4.) return 2 or 1 if not success




legendary
Activity: 866
Merit: 1002
January 25, 2014, 09:02:45 AM
If hit < target1 in the first check then hit < target2 in the second check because the target increases if the elapsed time increases and thus target1 <= target2. So it shouldn't be a problem.

Oh gosh, I somehow read the code in opposite manner. Feeling dumb now.
Thanks for clarification.
hero member
Activity: 644
Merit: 500
January 25, 2014, 08:39:16 AM
This is a real and fair Nxt distribution
Well, thanks for graphics, but numbers soon'll get old (I think distribution'll go even better, we're in 62-days old system). It'd be checked at picture.
hero member
Activity: 687
Merit: 500
January 25, 2014, 04:07:02 AM
If hit < target1 in the first check then hit < target2 in the second check because the target increases if the elapsed time increases und thus target1 <= target2. So it shouldn't be a problem.
legendary
Activity: 866
Merit: 1002
January 24, 2014, 05:43:48 PM
Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

What?

Cfb, System.currentTimeMillis() is called twice in two different places, in even if in first case there was hit, in second one (in verifyGenerationSignature) there might be miss.


Only if a new block was found while we were generating our block.

Let me rephrase that:
  • there's a check if hit is lower than target (based on System.currentTimeMillis())
  • then, there's a block generation
  • then, at end of block generation, there's check in block sig is ok, and generation sig is ok
  • in generation block check, there's ANOTHER check in hit < target based on DIFFERENT time than in step 1 (there's another call to System.currentTimeMillis())

So what CAN happen, is that the time will be ok during FIRST check, but will be BAD during second one, so verifyGenerationSignature will fail.

It's not a big bug, and probably, it'll happen less times, than invalid signature itself, but still it CAN happen.
legendary
Activity: 2142
Merit: 1009
Newbie
January 24, 2014, 10:23:26 AM
Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

What?

Cfb, System.currentTimeMillis() is called twice in two different places, in even if in first case there was hit, in second one (in verifyGenerationSignature) there might be miss.


Only if a new block was found while we were generating our block.
legendary
Activity: 866
Merit: 1002
January 24, 2014, 10:22:09 AM
Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.

What?

Cfb, System.currentTimeMillis() is called twice in two different places, in even if in first case there was hit, in second one (in verifyGenerationSignature) there might be miss.
legendary
Activity: 2142
Merit: 1009
Newbie
January 24, 2014, 06:44:25 AM
Edit:  Hey... guess what?  I got the incorrect block notification as mentioned above... but it was a VALID block after all!!!

Can you comment on the above CfB?  ...just trying to understand...   thnx   Smiley

It's a minor issue. Keep forging. We'll fix it later.
legendary
Activity: 2142
Merit: 1009
Newbie
January 24, 2014, 05:04:01 AM
I'm not sure, bu I think there is one small bug, that might cause perfectly fine generated block to be rejected.

In one of the anonymous objects, there's following piece (which happens to be my favourite piece of code in nxt btw):
Code:
int elapsedTime = [b]getEpochTime(System.currentTimeMillis())[/b] - lastBlock.timestamp;
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) {  // [b]FIRST[/b] check

account.[u]generateBlock[/u](user.secretPhrase);

}

}

Now inside generateBlock, there's following piece:
Code:
Block block = new Block(1, [b]getEpochTime(System.currentTimeMillis())[/b], lastBlock, newTransactions.size(), 0, 0, 0, null, Crypto.getPublicKey(secretPhrase), null, new byte[64]);
block.transactions = new long[block.numberOfTransactions];
int i = 0;
   ⋮
// fill in missing stuff in the block
   ⋮
block.blockSignature = Crypto.sign(data2, secretPhrase);

JSONObject request = block.getJSONObject(newTransactions);
request.put("requestType", "processBlock");

if (block.verifyBlockSignature() && block.[u]verifyGenerationSignature[/u]()) {

And in verifyGenerationSignature there is following check (in both blocks):
Code:
int elapsedTime = timestamp - previousBlock.timestamp;
BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
byte[] generationSignatureHash = MessageDigest.getInstance("SHA-256").digest(generationSignature);
BigInteger hit = new BigInteger(1, new byte[] {generationSignatureHash[7], generationSignatureHash[6], generationSignatureHash[5], generationSignatureHash[4], generationSignatureHash[3], generationSignatureHash[2], generationSignatureHash[1], generationSignatureHash[0]});
if (hit.compareTo(target) >= 0) {  // [b]SECOND[/b] check
return false;
}

Now, notice, that in FIRST check, value of target will most likely be different, than in SECOND check
(because in FIRST check value of elapsedTime will probably be different than value of elapsedTime in second check... most times,
the difference will probably small enough, and SECOND check might pass, but not always...)

Wouldn't it be better, to pass value returned by call to getEpochTime(System.currentTimeMillis()), to generateBlock() ?

No, we already checked that the hit didn't miss the target.
hero member
Activity: 490
Merit: 504
January 24, 2014, 01:03:57 AM
This is the FAIR distribution (100% proof of stake) that the Nxt folks are so proud of:
170486123 <--- 170 million Nxt

Looks like 9 guys have a lot of stake. 

170 mega account didn't belong to anyone, it was used for unclaimed coins, they were being given to their owners till 3 January.

This is a real and fair Nxt distribution, do not listen to his liar.

legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
January 24, 2014, 12:24:44 AM
I finally discovered the flaw in the Nxt source code:

Here is the FAIR distribution that the Nxt folks are so proud of:



This is a graph of the original NXT distribution.  73 accounts.

Here are the numbers:

36742
1970092
349130
24880020
2867856
9975150
2690963
7648
5486333
34913026
997515
30922966
6650
44888
2468850
49875751  <-- Did he pay in?
49875751  <-- Did he pay in?
9476393
49875751 <-- Did he pay in?
14887912
528683
583546
7315
19925363
29856290
5320
4987575
5985
24912938
49875751 <-- Did he pay in?
2724712
1482474
200999
1476156
498758
987540
16625250
5264386
15487585
2684479
14962725
34913026
5033128
2916900
49875751 <-- Did he pay in?
4962637
170486123 <--- 170 million Nxt
8644631
22166945
6668388
233751
4987575
11083556
1845403
49876
3491
3491
9476
49876
6151
682633
49875751 <-- Did he pay in?
482964
4988
49875751 <-- Did he pay in?
4988
9144
503745
49875751 <-- Did he pay in? Yup, 50million each
52370
29437998
585375
9975150
newbie
Activity: 56
Merit: 0
January 23, 2014, 10:04:25 PM
I'm posting this here because some of you devs might not have seen this on the main Nxt thread. We're in dire need of someone who is both technical and articulate and who understands Nxt deeply to represent Nxt on the "Let's Talk Bitcoin!" panel in Miami THIS FRIDAY. That's less than two days away. This is a HUGE opportunity!

I suggested JoeFox or Anon go, but neither feel qualified. JoeFox suggested wesley, ferment, opticalcarrier, rickyjames or ricot.

Some are suggesting that only C-f-B or BCNext could do this properly.

Any of you feel qualified enough to field the tough questions and interested in going if we can get the community to fund your trip? I think we can probably pull together enough Nxt to cover it completely, as this is a really important opportunity. I'll gladly chip in a couple hundred $-worth, and I'm sure others would too.

Sorry, that's a bit too short-notice for me to fly across the atlantic... Wink
If there's any european based meetup, I'd gladly join, though.
Pages:
Jump to: