Topic: Nxt source code flaw reports - page 46. (Read 113359 times)
One might think that the angle of attack is fought off by the new transparent forging algorithm because the account that chooses not to forge gets a lower forging weight. However, that's not the case if you move the balance off of that account and into a brand new one as soon as you forge the block. (To avoid fees) This brand new account will be inactive for 1440 blocks, but that just means that a maximum of 1440 of your accounts will be inactive. So that's only a very small percentage of your total number of accounts in that case and you can influence the chances at which you can generate the next block.
Bob has 2 accounts. His chance to hit the target is 2 times lower coz he has 2 times less coins on any of the accounts. But he has 2 accounts, so the chance to hit the target with NONE of the accounts is
Thus the chance to hit the target with ANY of the accounts is
Code:
X = (1 - 1/2000) * (1 - 1/2000)
Code:
1 - X
Ok, so basically what you are saying is that Bob's accounts are at a disadvantage because they are competing against each other, and the loss is where both accounts hit the target at the same time. (as it doesn't give twice the winnings). But... this could be said of any two accounts regardless of who controls them. The question is what happens when two hits the target the same time? It seems to me that there is a kind of difficulty defined and the one with the higher difficulty wins. In that case we are back to:
there is a 50% chance of selecting Alice next, and 25% for each of Bob's account.
Because the time when they hit their target doesn't matter.Bob's accounts compete but still help each other. The net outcome is almost zero. If 2 hits r made simultaneously then next blocks determine who wins.
Quote
This is not obvious and I even think is incorrect.
I don't see why it would be incorrect. The only difference between the two approaches is that the second one disregards the timing of the events, and collapses the selection process into one step. Your approach can account for the lowered block-generation rate in the "gaming the lottery algorithm" I described, but because only the fees are given to the forger, it doesn't matter. (well, actually it just adds to the incentive to not publish the first winning ticket and use the second one, even when the second one isn't giving you the winning hash for the next block. So you can wait for a few more transactions and get the fees from those too. This makes gaming the system even more worthwhile than my original formula suggests)
I think this is the problem. See my next reply...
Quote
Nxt forging algo uses numbers with limited number of bits. Ur assumption is correct only for numbers with unlimited range.
Which bits are limited and why you think that is relevant?When base target is very high large accounts hit the target within a few seconds with 100% probability while small ones need a hour to reach 100%. Forging becomes very unfair in this case.
What is more profitable then? Forge using 1 big account (1M NXT) or a lot of small ones (100 x 10K NXT)?
Btw, this question itself can be answered without any of the game-theory math I did above:
Because the 1440 blocks out-of-the-game period is independent of the account's balance, it is obvious that the smaller the account you are using for the forging the better. If you have one big account, you're completely out of the block creation process for 1440 blocks, but if you have it distributed to many small ones, only one of them is disables so you still have most of your accounts taking part in the lottery.
So without further thinking it can be seen that this 1440 block disabling period is unfair towards big accounts and incentivises splitting them to small ones.
Edit: Ok, this may not be true... do I understand correctly that once an account created a block, it's effective balance is zeroed out for 1440 blocks? If not than what I wrote in _this_ post is incorrect, but doesn't change what I wrote above about using the second-best accounts for forging.
I'm curious, even if you are moving a bunch of small stake accounts around, those are still limited by 1440 blocks before they can forge. This is the same situation as one large account. So unless you can predict 1440 blocks into the future (which is impossible, due to forgers dropping in and out of the network randomly), wouldn't both be equal?
If we are talking about pre-allocating accounts (to bypass the 1440 block restriction), not counting the massive fees required (at least 2 NXT per account currently), wouldn't the chance still be the same? If you divide your stake X by N accounts, (X/N)*N = X, still the original stake.
As for your edit, I don't think that is true, because I personally have generated a block, then another 50 blocks later.
Bob has 2 accounts. His chance to hit the target is 2 times lower coz he has 2 times less coins on any of the accounts. But he has 2 accounts, so the chance to hit the target with NONE of the accounts is
Thus the chance to hit the target with ANY of the accounts is
Code:
X = (1 - 1/2000) * (1 - 1/2000)
Code:
1 - X
Ok, so basically what you are saying is that Bob's accounts are at a disadvantage because they are competing against each other, and the loss is where both accounts hit the target at the same time. (as it doesn't give twice the winnings). But... this could be said of any two accounts regardless of who controls them. The question is what happens when two hits the target the same time? It seems to me that there is a kind of difficulty defined and the one with the higher difficulty wins. In that case we are back to:
there is a 50% chance of selecting Alice next, and 25% for each of Bob's account.
Because the time when they hit their target doesn't matter.Quote
This is not obvious and I even think is incorrect.
I don't see why it would be incorrect. The only difference between the two approaches is that the second one disregards the timing of the events, and collapses the selection process into one step. Your approach can account for the lowered block-generation rate in the "gaming the lottery algorithm" I described, but because only the fees are given to the forger, it doesn't matter. (well, actually it just adds to the incentive to not publish the first winning ticket and use the second one, even when the second one isn't giving you the winning hash for the next block. So you can wait for a few more transactions and get the fees from those too. This makes gaming the system even more worthwhile than my original formula suggests)
Quote
Nxt forging algo uses numbers with limited number of bits. Ur assumption is correct only for numbers with unlimited range.
Which bits are limited and why you think that is relevant? You didn't understand vamdor's attack correctly, I think.
The question isn't about chances to forge a block, it's about choosing which block to forge in a way that increases your chances to forge the block AFTER that.
So it's similar to my "move alot of coins around to increase your chance"-attack, just without all the coin moving
The question isn't about chances to forge a block, it's about choosing which block to forge in a way that increases your chances to forge the block AFTER that.
So it's similar to my "move alot of coins around to increase your chance"-attack, just without all the coin moving
He can't change block forging sequence without being penalized. If that's the point of vamdor's attack, ok. It's not the injected flaw.
I don't really understand your math here. Why would Bob's chance be lower than 0.001 ?
Bob has 2 accounts. His chance to hit the target is 2 times lower coz he has 2 times less coins on any of the accounts. But he has 2 accounts, so the chance to hit the target with NONE of the accounts is
Code:
X = (1 - 1/2000) * (1 - 1/2000)
Code:
1 - X
I think we can agree that after any given block there is a 50% chance of selecting Alice next, and 25% for each of Bob's account. It's easier to reason when it is presented this way.
This is not obvious and I even think is incorrect. Nxt forging algo uses numbers with limited number of bits. Ur assumption is correct only for numbers with unlimited range.
You didn't understand vamdor's attack correctly, I think.
The question isn't about chances to forge a block, it's about choosing which block to forge in a way that increases your chances to forge the block AFTER that.
So it's similar to my "move alot of coins around to increase your chance"-attack, just without all the coin moving
But user didn't konw that, i didn't konw the time is used for broadcasting until i saw the code.
And the transaction will be broadcasted anyway.
And the transaction will be broadcasted anyway.
Well, it's just an interface issue, not one of the flaws.
@Come-From-Beyond: Any comment on my "Spam the network for 7.5% increase in blcok generation" approach? 
Give me the link plz.
https://bitcointalksearch.org/topic/m.4311620
Ah, I have to model this situation before I come to a conclusion.
I don't really understand your math here. Why would Bob's chance be lower than 0.001 ?
Bob has 2 accounts. His chance to hit the target is 2 times lower coz he has 2 times less coins on any of the accounts. But he has 2 accounts, so the chance to hit the target with NONE of the accounts is
Code:
X = (1 - 1/2000) * (1 - 1/2000)
Code:
1 - X
I think we can agree that after any given block there is a 50% chance of selecting Alice next, and 25% for each of Bob's account. It's easier to reason when it is presented this way.
This is not obvious and I even think is incorrect. Nxt forging algo uses numbers with limited number of bits. Ur assumption is correct only for numbers with unlimited range.
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.
But user didn't konw that, i didn't konw the time is used for broadcasting until i saw the code.
And the transaction will be broadcasted anyway.
@Come-From-Beyond: Any comment on my "Spam the network for 7.5% increase in blcok generation" approach?
Give me the link plz.
https://bitcointalksearch.org/topic/m.4311620
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 guess I couldn't explain the idea if this is still a question
Lot of small ones is more profitable. If you only have one account, you never have an option to choose from your own accounts (as you have no other) and it's also going to be out of the lottery process for the 1440 blocks after it create a block, so it gives exactly the "fair" chance, no more.Alice owns 500M NXT (only 1 account), Bob owns 500M NXT (two account with 250M on each).
Let's assess chances to HIT a TARGET for both of them:
Let's take a base target that gives Alice 1/1000 chance to hit it within a short period of time after a previous block. Bob's chance will be 1/2000 for each of his accounts.
Alice's chance == 1/1000 = 0.001
Bob's chance == 1 - (1 - 1/2000) * (1 - 1/2000) = 1 - 0.9995 * 0.9995 = 1 - 0.99900025 = 0.00099975
Alice / Bob = 0.001 / 0.00099975 = 1.000250062515629 => This contradicts to ur statement
What's wrong in my math?
I don't really understand your math here. Why would Bob's chance be lower than 0.001 ?
I think we can agree that after any given block there is a 50% chance of selecting Alice next, and 25% for each of Bob's account. It's easier to reason when it is presented this way.
Where Bob has an edge is that if one of his blocks is selected, he may check whether it is better for him to not publish his block. That happens when his other block is going to be the second best one, and makes the genSignature to select him after that too.
Yes I know that there are some mechanisms to punish accounts that are not publishing when it's their turn, but that doesn't matter if the accounts are small and many enough.
@Come-From-Beyond: Any comment on my "Spam the network for 7.5% increase in blcok generation" approach?
Give me the link plz.
@Come-From-Beyond: Any comment on my "Spam the network for 7.5% increase in block generation" approach?
Because the 1440 blocks out-of-the-game period is independent of the account's balance, it is obvious that the smaller the account you are using for the forging the better. If you have one big account, you're completely out of the block creation process for 1440 blocks, but if you have it distributed to many small ones, only one of them is disables so you still have most of your accounts taking part in the lottery.
So without further thinking it can be seen that this 1440 block disabling period is unfair towards big accounts and incentivises splitting them to small ones.
Edit: Ok, this may not be true... do I understand correctly that once an account created a block, it's effective balance is zeroed out for 1440 blocks? If not than what I wrote in _this_ post is incorrect, but doesn't change what I wrote above about using the second-best accounts for forging.
So without further thinking it can be seen that this 1440 block disabling period is unfair towards big accounts and incentivises splitting them to small ones.
Edit: Ok, this may not be true... do I understand correctly that once an account created a block, it's effective balance is zeroed out for 1440 blocks? If not than what I wrote in _this_ post is incorrect, but doesn't change what I wrote above about using the second-best accounts for forging.
Only part of the coins is out of the lottery.
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 guess I couldn't explain the idea if this is still a question
Lot of small ones is more profitable. If you only have one account, you never have an option to choose from your own accounts (as you have no other) and it's also going to be out of the lottery process for the 1440 blocks after it create a block, so it gives exactly the "fair" chance, no more.Alice owns 500M NXT (only 1 account), Bob owns 500M NXT (two account with 250M on each).
Let's assess chances to HIT a TARGET for both of them:
Let's take a base target that gives Alice 1/1000 chance to hit it within a short period of time after a previous block. Bob's chance will be 1/2000 for each of his accounts.
Alice's chance == 1/1000 = 0.001
Bob's chance == 1 - (1 - 1/2000) * (1 - 1/2000) = 1 - 0.9995 * 0.9995 = 1 - 0.99900025 = 0.00099975
Alice / Bob = 0.001 / 0.00099975 = 1.000250062515629 => This contradicts to ur statement
What's wrong in my math?
So without further thinking it can be seen that this 1440 block disabling period is unfair towards big accounts and incentivises splitting them to small ones.
Which is good, right?
What is more profitable then? Forge using 1 big account (1M NXT) or a lot of small ones (100 x 10K NXT)?
Btw, this question itself can be answered without any of the game-theory math I did above:
Because the 1440 blocks out-of-the-game period is independent of the account's balance, it is obvious that the smaller the account you are using for the forging the better. If you have one big account, you're completely out of the block creation process for 1440 blocks, but if you have it distributed to many small ones, only one of them is disables so you still have most of your accounts taking part in the lottery.
So without further thinking it can be seen that this 1440 block disabling period is unfair towards big accounts and incentivises splitting them to small ones.
Edit: Ok, this may not be true... do I understand correctly that once an account created a block, it's effective balance is zeroed out for 1440 blocks? If not than what I wrote in _this_ post is incorrect, but doesn't change what I wrote above about using the second-best accounts for forging.
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 guess I couldn't explain the idea if this is still a question
Lot of small ones is more profitable. If you only have one account, you never have an option to choose from your own accounts (as you have no other) and it's also going to be out of the lottery process for the 1440 blocks after it create a block, so it gives exactly the "fair" chance, no more. 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.
Btw: I just realized my mistake from yesterday and I'm now able to crash the Thread that gets created for my request with an OutOfMemory error. Since jetty starts a new Thread for every request, it doesn't take down the machine, but remotely killing Threads is at least quite funny.
Btw: Yes, that also works in 0.5.0 Jump to: