...as he is creating a block, he has a slightly higher chance to create the next one too.
Why?
Topic: Nxt source code flaw reports - page 47. (Read 113369 times)
Why?
Because there is a chance that he not only has the first winning ticket of the "who's gonna forge" lottery, but also the second one. In this case the can choose which one to use: if the second one makes him the winner for the next block too, he chooses that, instead of the first one.
What is more profitable then? Forge using 1 big account (1M NXT) or a lot of small ones (100 x 10K NXT)?
I found that every time made a transaction need to wait for a long time.
Can we change this code
to
Can we change this code
Code:
JSONArray transactionsData = new JSONArray();
transactionsData.add(transaction.getJSONObject());
peerRequest.put("transactions", transactionsData);
[b]Peer.sendToAllPeers(peerRequest);[/b]
JSONObject response = new JSONObject();
response.put("response", "notifyOfAcceptedTransaction");
user.pendingResponses.offer(response);
to
Code:
JSONArray transactionsData = new JSONArray();
transactionsData.add(transaction.getJSONObject());
peerRequest.put("transactions", transactionsData);
JSONObject response = new JSONObject();
response.put("response", "notifyOfAcceptedTransaction");
user.pendingResponses.offer(response);
[b]Peer.sendToAllPeers(peerRequest);[/b]
No. A user should see when his node completes broadcasting a transaction.
...as he is creating a block, he has a slightly higher chance to create the next one too.
Why?
...as he is creating a block, he has a slightly higher chance to create the next one too.
Why?
Edit: Assuming that moved coins r excluded from effective balance for 1440 blocks.
I found that every time made a transaction need to wait for a long time.
Can we change this code
to
Can we change this code
Code:
JSONArray transactionsData = new JSONArray();
transactionsData.add(transaction.getJSONObject());
peerRequest.put("transactions", transactionsData);
[b]Peer.sendToAllPeers(peerRequest);[/b]
JSONObject response = new JSONObject();
response.put("response", "notifyOfAcceptedTransaction");
user.pendingResponses.offer(response);
to
Code:
JSONArray transactionsData = new JSONArray();
transactionsData.add(transaction.getJSONObject());
peerRequest.put("transactions", transactionsData);
JSONObject response = new JSONObject();
response.put("response", "notifyOfAcceptedTransaction");
user.pendingResponses.offer(response);
[b]Peer.sendToAllPeers(peerRequest);[/b]
Nxt forging is a Poisson process. Does "x*(p+(1-p)*p^2) + (1-x)*p = p" take this into account?
That's what I am saying. It is intended to be a Poisson process, and it is as long as you are using the algorithm in the published source. But someone may decide to "optimise" it further for their own benefit. In that case it isn't strictly a Poisson process anymore, as he is creating a block, he has a slightly higher chance to create the next one too.Also I made a typo when copying: it's x*(p+(1-p)*p^2) + (1-x)*p = x , the solution is the same
So for those not following: A user may have many small accounts instead of one, and may sometimes be able to choose which one to use for forging in a way that the next block also belongs to him.
Of course there are some limitations because of the fees, but for now let's assume that a user has "p" stake [0..1], and it is available in many small accounts: specifically the number of accounts is significantly higher than 1440, so that we can ignore that the 1440 block waiting period disables some parts of the accounts. We also assume that all the other accounts are many small non-colluding users.
Now if this user has a probability "x" of creating a block, then we can express that probability as a recursive formula. Generating the next block will happen with probability:
x*(p+(1-p)*p^2) + (1-x)*p = p
The second part means that with probability (1-x) someone else is generating the block, the account has no word in the selection process, so he will get his fair "p" chance in this case.
However when with probability "p" it happens that the account with the best chances is one of his owns, he can also check whether he also has the second best account. So in this case there is a "p" chance of generating the next block in the "fairly deserved way", by choosing the best block which also happens to grant the second block, but when this isn't true (chance (1-p)), he can check whether he has the second best block too (*p) , and whether it grants him the next block too. (this also happens with "p" probability) So this case adds an additional chance of (1-p)*p*p for this branch.
Solving the equation gives x = p / (p^3 - p^2 +1)
As I said this is not a big difference. Gives some incentive for colluding though, a few players with 5%-10% stakes each may decide that the few extra percents are worth grabbing.
Of course there are some limitations because of the fees, but for now let's assume that a user has "p" stake [0..1], and it is available in many small accounts: specifically the number of accounts is significantly higher than 1440, so that we can ignore that the 1440 block waiting period disables some parts of the accounts. We also assume that all the other accounts are many small non-colluding users.
Now if this user has a probability "x" of creating a block, then we can express that probability as a recursive formula. Generating the next block will happen with probability:
x*(p+(1-p)*p^2) + (1-x)*p = p
The second part means that with probability (1-x) someone else is generating the block, the account has no word in the selection process, so he will get his fair "p" chance in this case.
However when with probability "p" it happens that the account with the best chances is one of his owns, he can also check whether he also has the second best account. So in this case there is a "p" chance of generating the next block in the "fairly deserved way", by choosing the best block which also happens to grant the second block, but when this isn't true (chance (1-p)), he can check whether he has the second best block too (*p) , and whether it grants him the next block too. (this also happens with "p" probability) So this case adds an additional chance of (1-p)*p*p for this branch.
Solving the equation gives x = p / (p^3 - p^2 +1)
As I said this is not a big difference. Gives some incentive for colluding though, a few players with 5%-10% stakes each may decide that the few extra percents are worth grabbing.
Nxt forging is a Poisson process. Does "x*(p+(1-p)*p^2) + (1-x)*p = p" take this into account?
Obviously: Before typing this post, I tried the latter method on my local 0.5.0 client and it didn't work. So I guess this has been fixed by now.
Published version is also immune to this attack coz out-of-memory is caught by try-catch.
OutOfMemoryError isn't a catchable exception because the memory of the VM has been compromised!(Hence the name Error, not Exception
)Also see the following little test code to verify:
Code:
public class Test {
public static void main(String[] args) {
try{
long[] l = new long[Integer.parseInt(args[0])];
}catch(Exception e){
System.out.println("foo");
}
System.out.println("bar");
}
}
If started with INT_MAX as a parameter, it shows a java heap space JVM exception and neither "foo" nor "bar".
U r right. Good catch.
If you guys think, that a catch(Exception e) safes you from those kind of things... I'm speechless.
Fixed.
Obviously: Before typing this post, I tried the latter method on my local 0.5.0 client and it didn't work. So I guess this has been fixed by now.
Published version is also immune to this attack coz out-of-memory is caught by try-catch.
OutOfMemoryError isn't a catchable exception because the memory of the VM has been compromised!(Hence the name Error, not Exception
)Also see the following little test code to verify:
Code:
public class Test {
public static void main(String[] args) {
try{
long[] l = new long[Integer.parseInt(args[0])];
}catch(Exception e){
System.out.println("foo");
}
System.out.println("bar");
}
}
If started with INT_MAX as a parameter, it shows a java heap space JVM exception and neither "foo" nor "bar".
If you guys think, that a catch(Exception e) safes you from those kind of things... I'm speechless.
Valid assumption. U could follow my way - try to create a model and run it. My results show that max difference in number of forged blocks between Alice owning 1M of coins and million Bobs with 1 NXT each is less than 1/1000 of the normalized base target.
Instead of running simulations I did the math and the effect is much smaller than I expected. For example someone having 33% stake can get up to 36% of the blocks if the rest of the network are many small non-colluding participants.
Could u post ur math plz?
So for those not following: A user may have many small accounts instead of one, and may sometimes be able to choose which one to use for forging in a way that the next block also belongs to him.
Of course there are some limitations because of the fees, but for now let's assume that a user has "p" stake [0..1], and it is available in many small accounts: specifically the number of accounts is significantly higher than 1440, so that we can ignore that the 1440 block waiting period disables some parts of the accounts. We also assume that all the other accounts are many small non-colluding users.
Now if this user has a probability "x" of creating a block, then we can express that probability as a recursive formula. Generating the next block will happen with probability:
x*(p+(1-p)*p^2) + (1-x)*p = x
The second part means that with probability (1-x) someone else is generating the block, the account has no word in the selection process, so he will get his fair "p" chance in this case.
However when with probability "p" it happens that the account with the best chances is one of his owns, he can also check whether he also has the second best account. So in this case there is a "p" chance of generating the next block in the "fairly deserved way", by choosing the best block which also happens to grant the second block, but when this isn't true (chance (1-p)), he can check whether he has the second best block too (*p) , and whether it grants him the next block too. (this also happens with "p" probability) So this case adds an additional chance of (1-p)*p*p for this branch.
Solving the equation gives x = p / (p^3 - p^2 +1)
As I said this is not a big difference. Gives some incentive for colluding though, a few players with 5%-10% stakes each may decide that the few extra percents are worth grabbing.
Code:
if (secretPhrase.length() < 30) {
response.put("secretPhraseStrength", 1);
} else {
response.put("secretPhraseStrength", 5);
}
The only thing that gets checked at the moment is the length of the password. Wouldn't it be appropriate to check for other things? Everyone will agree that "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" (31 x a) is not more secure than "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" (30 x a). When the software finds distribution and DAUs will use it, we need to tell them how a secure password has to look like. So we need at least a check that upper/lower-case letters, numbers and special characters are part of the password.
Wouldn't it be nice to have additional a password generator implemented in NXT? On the other hand that could become a problem, if users just generate a password and don't remember it afterwards.
Code:
if (secretPhrase.length() < 30) {
response.put("secretPhraseStrength", 1);
} else {
response.put("secretPhraseStrength", 5);
}
The only thing that gets checked at the moment is the length of the password. Wouldn't it be appropriate to check for other things? Everyone will agree that "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" (31 x a) is not more secure than "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" (30 x a). When the software finds distribution and DAUs will use it, we need to tell them how a secure password has to look like. So we need at least a check that upper/lower-case letters, numbers and special characters are part of the password.
Wouldn't it be nice to have additional a password generator implemented in NXT? On the other hand that could become a problem, if users just generate a password and don't remember it afterwards.
Shouldn't there be an || account.getEffectiveBalance() < 0 in the code above?
Does the Genesis account forge when unlocked without this restriction?
Imagine that... a situation where generating a block would not be desirable!!!
Does the Genesis account forge when unlocked without this restriction?
Imagine that... a situation where generating a block would not be desirable!!!
Target for genesis account will be negative, but it's still a good idea to use "<=" instead of "==".
This is not the flaw.
Shouldn't there be an || account.getEffectiveBalance() < 0 in the code above?
Does the Genesis account forge when unlocked without this restriction?
Imagine that... a situation where generating a block would not be desirable!!!
Does the Genesis account forge when unlocked without this restriction?
Imagine that... a situation where generating a block would not be desirable!!!
Target for genesis account will be negative, but it's still a good idea to use "<=" instead of "==".
This is not the flaw.
BEAUTIFUL, Programming nazi here are just trolls who imitate their tutors disgruntle at them when they were learning to program. Like the others, I am etching to fork it! But not a different chain... or maybe 
Code:
synchronized (senderAccount) {
senderAccount.setBalance(senderAccount.balance + (transaction.amount + transaction.fee) * 100L);
}I just wonder why not setUnconfirmedBalance back here
This code processes confirmed transactions.
Obviously: Before typing this post, I tried the latter method on my local 0.5.0 client and it didn't work. So I guess this has been fixed by now.
Published version is also immune to this attack coz out-of-memory is caught by try-catch.
Code:
synchronized (senderAccount) {
senderAccount.setBalance(senderAccount.balance + (transaction.amount + transaction.fee) * 100L);
}I just wonder why not setUnconfirmedBalance back here
I'll just wait until you guys fix their broken code for them and then i'll fork it.
U r one of the hundreds who waits for this.
Jump to: