With the current code, what will fail the validation when (transaction.amount + transaction.fee) overflows? Since amount and fee will both be > 0 and the negative total will be able to be credited to the account.
validateAttachment().
Topic: Nxt source code flaw reports - page 44. (Read 113369 times)
validateAttachment().
When switching to a new version people who deleted their transaction and block files complained that they can't catch up with the chain.
This happens when at start all well known peers have hallmarks. To check a hallmark the corresponding account must be known to the nxt server. Since the server has no block/transactions at start he doesn't know any accounts and thus rejects the peer. So he will never catch up with the chain.
From Peer class method analyzeHallmark:
This is certainly not an injected bug but the software shouldn't be stuck even if it starts with noch blocks/transactions.
This happens when at start all well known peers have hallmarks. To check a hallmark the corresponding account must be known to the nxt server. Since the server has no block/transactions at start he doesn't know any accounts and thus rejects the peer. So he will never catch up with the chain.
From Peer class method analyzeHallmark:
Code:
long accountId = Account.getId(publicKey);
Account account = accounts.get(accountId);
if (account == null)
{
return false;
}
This is certainly not an injected bug but the software shouldn't be stuck even if it starts with noch blocks/transactions.
Does it really stuck in this case? Have u checked?
Unless I missed something ...
Validation is done by the peers. A node doesn't adjust unconfirmedBalance and processes the transaction only after it's received from one of the peers. It's received only if passes validation check.
With the current code, what will fail the validation when (transaction.amount + transaction.fee) overflows? Since amount and fee will both be > 0 and the negative total will be able to be credited to the account.
Btw: This thing would never go thru any kind of (government mandated) review in the banking or automotive industry, just saying...
Agree. This code is just an implementation of the idea, not a finished product.
I have come up with a way to attack NXT, it won't kill it but would seriously damage it. I do not want to post publicly, I will send to CfB privately.
James
James
Hope it's just one of the flaws we are looking for here!?!?!
I seriously doubt it. At least I have a partial solution to it.
James
Uh, nice catch if CfB can confirm it...
Do you want to elaborate on what general type of attack it is?
I just heard back from CfB. He said it was "I insist u post this publicly. This is the best attack ever,..." I am reluctant to make it public, but when CfB says to post it, who am I to disagree. I will post on the main thread.
James
I have come up with a way to attack NXT, it won't kill it but would seriously damage it. I do not want to post publicly, I will send to CfB privately.
James
James
Hope it's just one of the flaws we are looking for here!?!?!
I seriously doubt it. At least I have a partial solution to it.
James
Uh, nice catch if CfB can confirm it...
Do you want to elaborate on what general type of attack it is?
No. Since I have not gotten the famous CfB oneliner quickly, I fear he has had to consult BCnext himself. I hope I am just being silly and totally wrong, but better to be safe than sorry
James
When switching to a new version people who deleted their transaction and block files complained that they can't catch up with the chain.
This happens when at start all well known peers have hallmarks. To check a hallmark the corresponding account must be known to the nxt server. Since the server has no block/transactions at start he doesn't know any accounts and thus rejects the peer. So he will never catch up with the chain.
From Peer class method analyzeHallmark:
This is certainly not an injected bug but the software shouldn't be stuck even if it starts with noch blocks/transactions.
This happens when at start all well known peers have hallmarks. To check a hallmark the corresponding account must be known to the nxt server. Since the server has no block/transactions at start he doesn't know any accounts and thus rejects the peer. So he will never catch up with the chain.
From Peer class method analyzeHallmark:
Code:
long accountId = Account.getId(publicKey);
Account account = accounts.get(accountId);
if (account == null)
{
return false;
}
This is certainly not an injected bug but the software shouldn't be stuck even if it starts with noch blocks/transactions.
I have come up with a way to attack NXT, it won't kill it but would seriously damage it. I do not want to post publicly, I will send to CfB privately.
James
James
Hope it's just one of the flaws we are looking for here!?!?!
I seriously doubt it. At least I have a partial solution to it.
James
Uh, nice catch if CfB can confirm it...
Do you want to elaborate on what general type of attack it is?
I have come up with a way to attack NXT, it won't kill it but would seriously damage it. I do not want to post publicly, I will send to CfB privately.
James
James
Hope it's just one of the flaws we are looking for here!?!?!
I seriously doubt it. At least I have a partial solution to it.
James
I have come up with a way to attack NXT, it won't kill it but would seriously damage it. I do not want to post publicly, I will send to CfB privately.
James
James
Ok, then he can wait a bit longer to get some more valuable transactions. It still increases his fees unfairly.
This would be an issue if gap between blocks was the same. Forging is unfair anyway, coz sometimes there are 5 seconds between blocks, sometimes 10 minutes.
Ok, then I'll just slightly modify my client now and enjoy getting more transaction fees than I should.
Oh, and when a new block is created there still is no check for deadline!!! So if a transaction that just went above deadline is in unconfirmedTransaction (which is definitely possible), you'll create a block that the other peers reject!
The chance is very low, list of unconfirmed transactions is checked each second.
PLEASEPLEASEPLEASE start making proper code!
Btw: This thing would never go thru any kind of (government mandated) review in the banking or automotive industry, just saying...
Ok, then he can wait a bit longer to get some more valuable transactions. It still increases his fees unfairly.
This would be an issue if gap between blocks was the same. Forging is unfair anyway, coz sometimes there are 5 seconds between blocks, sometimes 10 minutes.
Oh, and when a new block is created there still is no check for deadline!!! So if a transaction that just went above deadline is in unconfirmedTransaction (which is definitely possible), you'll create a block that the other peers reject!
The chance is very low, list of unconfirmed transactions is checked each second.
If the number of transactions is always more than can be fit into a block, you'll just generate a lot of backlog... why would you want that?
Users r supposed to compete for room in blocks => higher fees.
Ok, then he can wait a bit longer to get some more valuable transactions. It still increases his fees unfairly.
Oh, and when a new block is created there still is no check for deadline!!! So if a transaction that just went above deadline is in unconfirmedTransaction (which is definitely possible), you'll create a block that the other peers reject!
How can Visa scale be acheived (1000 tps +) if there is only room for 255 transactions per minute?
This limit is set for the time being.
How can Visa scale be acheived (1000 tps +) if there is only room for 255 transactions per minute?
If the number of transactions is always more than can be fit into a block, you'll just generate a lot of backlog... why would you want that?
Users r supposed to compete for room in blocks => higher fees.
The problem is that you can take away transactions (and fees) from the generator of the next block by putting off sending out yours by a little. Sending your block a bit later is no problem, since it will a) take more time for someone else to generate a block b) you'll have a better cumulative difficulty than the other person, even if the other person was there earlier.
This doesn't look as a serious issue. Next generator could play the same game. Anyway, number of transactions is supposed to be higher than it's possible to fit into a block.
Yes, we all could play the same game, then it would be even. But if only a few do (because the official client doesn't do it), then they will gain an advantage.
If the number of transactions is always more than can be fit into a block, you'll just generate a lot of backlog... why would you want that?
[edit]
And it really doesn't make sense at all to include transactions from the future in a block... that's just totally confusing :p
The problem is that you can take away transactions (and fees) from the generator of the next block by putting off sending out yours by a little. Sending your block a bit later is no problem, since it will a) take more time for someone else to generate a block b) you'll have a better cumulative difficulty than the other person, even if the other person was there earlier.
This doesn't look as a serious issue. Next generator could play the same game. Anyway, number of transactions is supposed to be higher than it's possible to fit into a block.
Jump to: