Nxt source code flaw reports

[starik69]

Ah, maybe some other NXT developer knows elementary statistics well enough to understand this?

Seems like it is you who needs some elementary statistics classes

[1714742990]

1714742990

[1714742990]

1714742990

[1714742990]

1714742990

[1714742990]

1714742990

[1714742990]

1714742990

[1714742990]

1714742990

[opticalcarrier]

Good algorithm works equally good on 2 wallets, 3 wallets and 101 wallets and indefinite number of wallets. Bad algorithm needs someone like Come-from-Beyond to make unverifiable claims that 'it works, believe me!'

C'mon! It's not religion, it's programming!

The right way to do this is to have some penalty for fat wallets and encourage a lot of small wallets.  So 100 small wallets should make more than 1 fat wallet.

ok so then i break down my one 50M account into fiftty 1M accounts

come on you're going to have to do better than this.  if you fell for this logical trap, I dont see how you are EVER going to do your own coin...

Then go with proof of burn... the bigger the risk the bigger the gain.  Just like Bitcoin,  the bigger the investment on mining hardware,  the bigger the gain.   That sounds more fair to me than a bunch of fat cats earning coins for just hoarding them.

no thanks - we want 1000's of transactions/second.  so we'll stay with 100% PoS.

[gimre]

Code:

from random import random
from operator import itemgetter

NBLOCKS = 100000
N = 100
W = [100000] + [1000] * N
z = [0.] * len(W)
wins = [0] * len(W)

for x in xrange(NBLOCKS):
	for i in xrange(len(W)):
		z[i] = random()/W[i]
	
	[position, value] = min(enumerate(z), key=itemgetter(1))
	wins[position] += 1

print float(wins[0])/sum(wins[1:]), float(wins[0])/(sum(wins[1:])/N)

1.71835159159 172.242506812

Ur model is way too simplified. This is better one (but also doesn't match reality):

Code:

from random import random
from operator import itemgetter

NBLOCKS = 100000
N = 99
pawn = 9000000
king = 1000000000 - N*pawn

print king/pawn

W = [king] + [pawn] * N
wins = [0] * len(W)
z = [0] * len(W)

for x in xrange(NBLOCKS):
	elapsedTime = (random()*60)
	count = 0
	for i in xrange(len(W)):
		target = W[i] * elapsedTime
		hit = random()*120000000219 # related to BASE TARGET, 
		                             # the lower the number, more peers have chance to hit
									 # ~120 will cause anyone to hit
		if (hit < target):
			wins[i] += 1
			count += 1
	#print count

print float(wins[0])/sum(wins[1:]), float(wins[0])/(sum(wins[1:])/N)
print wins

king/pawn in this sample gives 12, and that's also result of second float printed after both loops

> foo.py
12
0.12333879483 12.2624434389

[jkoil]

Ur model is way too simplified. This is better one (but also doesn't match reality):

Code:

king/pawn in this sample gives 12, and that's also result of second float printed after both loops

> foo.py
12
0.12333879483 12.2624434389

"doesn't match reality"

How close to reality you could make that kind of simulation?

There [in the simulation] should be included the feature that 'king' accounts are getting more and more and so their probabilities to get more increases. As to the NXT system is not coming any NXTs, the 'pawn' accounts will get poorer. In some scenarios   But that needs to be checked, even in theory ... later in practice.

Ofc the situation may not be so bias; there has been talked about forthcoming features and change of fees, but ...


Edit: typos and clarification

[Come-from-Beyond]

"doesn't match reality"

How close to reality you could make that kind of simulation?

There should be included the feature that 'king' accounts are getting more and more and so their probabilities to get more increases. As to the NXT system is not coming any NXTs, the 'pawn' accounts will get poorer. In some scenarios   But that needs to be checked, even in theory ... later in practice.

Ofc the situation may not be so bias; there has been taled about fortcoming features and change of fees, but ...

This can't happen coz accounts that lose their turn to forge a block will be penalized. The only way to avoid the penalty is to split big accounts into 100s small ones.

[gimre]

Ur model is way too simplified. This is better one (but also doesn't match reality):

Code:

king/pawn in this sample gives 12, and that's also result of second float printed after both loops

> foo.py
12
0.12333879483 12.2624434389

"doesn't match reality"

I was referring to the fact, that in reality, the king might not be "fastest", and there's chance for pawns connected to large number of peers.

P.S. but ofc, what you've written also matters, but CfB already replied to that.

[nadrimajstor]

I suppose line 5873
    if (peer.state == peer.STATE_DISCONNECTED) {
should be
    if (peer.state == Peer.STATE_DISCONNECTED) {
 

[Come-from-Beyond]

I suppose line 5873
    if (peer.state == peer.STATE_DISCONNECTED) {
should be
    if (peer.state == Peer.STATE_DISCONNECTED) {
 

Does it matter?

[gimre]

I suppose line 5873
    if (peer.state == peer.STATE_DISCONNECTED) {
should be
    if (peer.state == Peer.STATE_DISCONNECTED) {
 

1st one is ugly, but compiler will accept that

[bitcoinpaul]

I suppose line 5873
    if (peer.state == peer.STATE_DISCONNECTED) {
should be
    if (peer.state == Peer.STATE_DISCONNECTED) {
 

1st one is ugly, but compiler will accept that

Must be the fatal flaw.

[Meizirkki]

Is there a method to limit target from overflowing?

[gimre]

Is there a method to limit target from overflowing?

if you mean base target, it won't overflow. check is done inside calculateBaseTarget

Code:

...
long twofoldCurBaseTarget = curBaseTarget * 2;
if (twofoldCurBaseTarget < 0) {
	twofoldCurBaseTarget = maxBaseTarget;
}
if (newBaseTarget > twofoldCurBaseTarget) {
	newBaseTarget = twofoldCurBaseTarget;
}

if you mean hit target, computation is done using BigInteger, so that won't overflow.

Code:

BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));
BigInteger hit = ...
if (hit.compareTo(target) >= 0) {

edit added code fragments

[nadrimajstor]

Does it matter?

Don't know... Just wondering... I'm not a developer by any stretch of imagination. 

[bitcoinpaul]

Where is the fatal flaw, guys.

[gimre]

Where is the fatal flaw, guys.

I know saying (based on the similarity to word "who"), that russian guys will understand:

xyй knows.

[CrazyEyes]

I propose that everyone in here who have put their heart in mind into solving existing bugs as well as validating non vuln code will get bounty for it, right here, right now. We have done the community a huge favor. Core dev team should show their appreciation.

I assume i can speak for everyone here. People in this forum are working for free, making others profit. Now its their turn.

Regards
j0b

[CrazyEyes]

I propose that everyone in here who have put their heart in mind into solving existing bugs as well as validating non vuln code will get bounty for it, right here, right now. We have done the community a huge favor. Core dev team should show their appreciation.

I assume i can speak for everyone here. People in this forum are working for free, making others profit. Now its their turn.

Regards
j0b

If this takes place... please DO NOT include me... I already got a very very GENEROUS donation from klee for my participation!   

To be honest... I actually hope he has no regrets about it as my efforts reached a Dead End shortly after.   

You are probably the only one..

[gimre]

although I posted in this thread, I find the idea lame...

[CrazyEyes]

Lame? well spoken. Looking for other investments so do what you want. I will hang around the irc channel and helping people out though, since i have done from december. Have met some really nice and talented people there. Godspeed everyone!

Regards
j0b

[Eadeqa]

100K reward should go to him

https://nextcoin.org/index.php/topic,3884