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
Topic: Nxt source code flaw reports - page 7. (Read 113312 times)
although I posted in this thread, I find the idea lame...
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
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..
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
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
Where is the fatal flaw, guys.
I know saying (based on the similarity to word "who"), that russian guys will understand:
xyй knows.
Where is the fatal flaw, guys.
Does it matter?
Don't know... Just wondering... I'm not a developer by any stretch of imagination. 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
Is there a method to limit target from overflowing?
I suppose line 5873
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
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.
I suppose line 5873
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
1st one is ugly, but compiler will accept that
I suppose line 5873
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
Does it matter?
I suppose line 5873
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
if (peer.state == peer.STATE_DISCONNECTED) {
should be
if (peer.state == Peer.STATE_DISCONNECTED) {
Ur model is way too simplified. This is better one (but also doesn't match reality):
king/pawn in this sample gives 12, and that's also result of second float printed after both loops
Code:
king/pawn in this sample gives 12, and that's also result of second float printed after both loops
Quote
> foo.py
12
0.12333879483 12.2624434389
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.
"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 ...
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.
Ur model is way too simplified. This is better one (but also doesn't match reality):
king/pawn in this sample gives 12, and that's also result of second float printed after both loops
Code:
king/pawn in this sample gives 12, and that's also result of second float printed after both loops
Quote
> foo.py
12
0.12333879483 12.2624434389
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
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)
Quote
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
Quote
> foo.py
12
0.12333879483 12.2624434389
12
0.12333879483 12.2624434389
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!
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.
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 
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!
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.
Jump to: