 Show Posts
|
|
Pages: [1]
|
[...] If it's just a few hundred thousand I may buy it just to shut you up.  Nice move! If he has too much FIMK, let me know and we will group together to buy them.. I'm fed up as well!  |
|
|
|
i have 9 million FIMK and i don't plan on dumping. i'm just disappointed at the activity level from the dev team.
WOW! You must be forging quite a lot then! Keep that stash for a year and I'm sure you won't be disappointed anymore! |
|
|
|
@Primitive, feel free to dump your coins whenever you want! I'm looking for more in order to get more forging rewards!  |
|
|
|
To fix this weakness forever, a simple no money, no fee transaction could be executed. Whenever you open a wallet, if the NXT client notices that your account on the chain doesn't have a public key associated with, it could issue a 0nxt/0fee transaction that is meant to record the key.
So every new account which gets opened just for a second would get 'loaded' into the blockchain. then, someone would open thousands of thousands of accounts to bloat the blockchain just for fun. i don't like. wrong? No, only when opening an account that has no public key associated to it that you can do this. If the account doesn't exist yet (has not received any transactions), then the operation should fail. |
|
|
|
Sorry, but I disagree that ur example is relevant.
There isn't really any room to disagree, 64 bits is not safe. The 64bit issue you are talking about is real but trivial to fix, hard to exploit and easy to protect yourself against. It can only be exploited if an account doesn't have an associated public key. In that case, the issue is real. It is easy to protect yourself against it because as soon as you do a transaction, the public key is going to be associated and your account will be safe. Now, you'll probably try to say that someone did crack a 64bit key previously and you are right. However, it took them over 4 years... You know, everything can be "cracked" or "bruteforced" in cryptography. However, if the time taken to bruteforce is more expensive or require more time than the validity of the data, then we consider this safe. To fix this weakness forever, a simple no money, no fee transaction could be executed. Whenever you open a wallet, if the NXT client notices that your account on the chain doesn't have a public key associated with, it could issue a 0nxt/0fee transaction that is meant to record the key. It doesn't require much modifications on the current codebase to do this. Commodity hardware is able to generate ~250k accounts per minute right now. 2^63 / 250 000 = 36893488147419 min = 614891469124 hours = 25620477880 days = 70193090.082 years I'm using 2^63 instead of 2^64 because of the "Birthday Problem" No doubt this will be fixed in 70 million years... |
|
|
|
Hey gang, Any thoughts on this? https://nextcoin.org/index.php/topic,2418.0.htmlWhen a POST is done with "processBlock", there is no sanity check on "payloadLength". This means, an attacker could use this issue to DoS a node by keeping its heap exhausted all the time. This would trigger various OOM exceptions in other parts of the code. Simple request causing 662.2 megs to be allocated: curl " http://localhost:7874/nxt" -d '{"protocol": 1, "requestType": "processBlock", "version": 1, "blockTimestamp": 666, "timestamp": 666, "previousBlock": "666", "numberOfTransactions": 0, "totalAmount": 666, "totalFee": 1, "payloadLength": 662200000, "payloadHash": "deadbeef", "generatorPublicKey": "deadbeef", "generationSignature": "deadbeef", "blockSignature": "deadbeef"}' * Tested against 0.5.0 Isn't this memory garbage collected? Yes, the allocation will get garbage collected, but don't rely on this for this kind of operations. The solution is very easy here.. there is a check that should be done against the max payload constant and it is done, but too late in a different function. As soon as you call 'processBlock', a first allocation will occur. If I trigger this constantly on a node (let say localhost), any concurrent 'new' operation will fail with an OOM exception before memory is exhausted by this issue. That means I can easily DoS any node I want without using that much bandwidth. An attacker could bring down the entire network using this trick. This is a critical issue. Nice catch... expect some tips! I'm doing this to protect my investment... but thanks! That's always appreciated! |
|
|
|
Hey gang, Any thoughts on this? https://nextcoin.org/index.php/topic,2418.0.htmlWhen a POST is done with "processBlock", there is no sanity check on "payloadLength". This means, an attacker could use this issue to DoS a node by keeping its heap exhausted all the time. This would trigger various OOM exceptions in other parts of the code. Simple request causing 662.2 megs to be allocated: curl " http://localhost:7874/nxt" -d '{"protocol": 1, "requestType": "processBlock", "version": 1, "blockTimestamp": 666, "timestamp": 666, "previousBlock": "666", "numberOfTransactions": 0, "totalAmount": 666, "totalFee": 1, "payloadLength": 662200000, "payloadHash": "deadbeef", "generatorPublicKey": "deadbeef", "generationSignature": "deadbeef", "blockSignature": "deadbeef"}' * Tested against 0.5.0 Isn't this memory garbage collected? Yes, the allocation will get garbage collected, but don't rely on this for this kind of operations. The solution is very easy here.. there is a check that should be done against the max payload constant and it is done, but too late in a different function. As soon as you call 'processBlock', a first allocation will occur. If I trigger this constantly on a node (let say localhost), any concurrent 'new' operation will fail with an OOM exception before memory is exhausted by this issue. That means I can easily DoS any node I want without using that much bandwidth. An attacker could bring down the entire network using this trick. This is a critical issue. |
|
|
|
|
The market cap for LTC is pretty decent. You shouldn't be worried too much about buying it since it follows the step of the BTC.
|
|
|
|
[...]
Anyway I've noticed alot of posts say stuff without doing much research!
Yeah, you are right. There are even people claiming that it isn't decentralized... but yes, it is. I think the major issue for NXT right now is the lack of a "proper" client. Who wants to access his wallet in a browser?! Sure.. running on localhost.. but still.. |
|
|
|
|
Why not investing efforts in something else instead of yet forking 'another coin doing pretty much the same thing with different configuration'?
|
|
|
|
|
Some concepts and features in NXT are nice. The code isn't following proper standards but it isn't huge yet and could easily be refactored.
|
|
|
|
|
