What is the function of sha256 ? This is used to verify that the package you downloaded is really the one I created and has not been tampered with. Run "sha256sum nxt-client-0.4.8.zip" from the command line on linux and it should print out the above result. No idea how to check sha256 sums on windows though. |
|
|
|
NRS 0.4.8 is ready and can be downloaded from:http://info.nxtcrypto.org/nxt-client-0.4.8.zipsha256: ec7c30a100717e60d8abe50eedb23641952847d91ff90b9b05a74ff98d8a4cf2 From now on I will also be posting the latest version number and sha256 as the value of NRSversion alias on the blockchain: https://localhost:7875/nxt?requestType=getAliasURI&alias=nrsversionChange log: - Added Transparent Forging, will be turned on at block 32000. - Memory leak fixed. - Send money from the browser now also asks for the secret phrase. There is only one new parameter in the web.xml, myPlatform. It is used to announce your platform - PC, Mac, Raspberry, NeXTstation, VAX, zombie... The zip file does not contain blocks.nxt and transactions.nxt. Make sure you preserve your own *.nxt files before upgrading!
|
|
|
|
More precisely, the account public key becomes known to the blockchain when the first outgoing transaction has been sent from this account. And you can't make an outgoing transaction unless there are funds in the account. So there is some chicken and egg problem here, the very first time you open an account and want to fund it, the above request will tell you that the account is unknown. Client developers should still allow sending money to such an account, but just give a warning. To be even more specific, there are three possible cases: errorCode 5, "Unknown account" - there have been neither incoming nor outgoing transactions to the account an empty response (i.e., no public key known) - there has been at least one incoming transaction (so that the blockchain knows the account number), but public key is not known (and is not sure if anyone in the world knows the password, as is the case with account 100000) a valid publicKey returned - there has been at least one outgoing transaction (and necessarily at least one incoming), the public key is known, somebody really has used this account and hopefully remembers the password In the first two cases, the risk of mistyping the account number is that the money goes into a blackhole, which increases the value of the remaining Nxt in circulation. In the last case, the risk is that the money goes to somebody else, who can still put them to a good use. |
|
|
|
I was actually about to start stuffing the block chain into ES. Is that something you're interested in playing with?
Yes, definitely. I have some experience with Lucene, but that's from before ElasticSearch existed. I would be interested to try ES, only need to take care of the more immediate core issues first. |
|
|
|
More precisely, the account public key becomes known to the blockchain when the first outgoing transaction has been sent from this account. And you can't make an outgoing transaction unless there are funds in the account. So there is some chicken and egg problem here, the very first time you open an account and want to fund it, the above request will tell you that the account is unknown. Client developers should still allow sending money to such an account, but just give a warning. |
|
|
|
Cool. When you said paid Core, you mean they are being paid for their development work? If so, full details of this should be provided (not the amounts obviously, but who is paying who, for what duration etc). Development team is a major plus of this coin. I am not paid. I will work full time on Nxt. If Nxt is successful, I will never need to work for money again, this is enough motivation for me. I will remain anonymous, at least for now. I feel safer this way. |
|
|
|
for my part, i begin to work on the core of a future Alias search engine (index + request tools) implements in java . I think it could be interesting to have a query tools allow us finding alias and URI associate. In a second step maybe we can implement a more sophisticated crawler (tags ans metada of URI ) . what the forum think about this project ?
That's interesting, do you plan to use Lucene/Solr, Elasticsearch, or write something from scratch yourself? Long term we may indeed need a search index within the Nxt core, as the blockchain grows too big to load all in memory and we keep adding more stuff to it that we need to query fast (like aliases). |
|
|
|
I just feel that NXT absolutely has to run on 512 Mb with no issues, and openjdk-7-jre-headless seems a better choice vs openjdk-7-jre.
It is not there yet, but I agree, it takes more memory than it should now. The memory leak that I fixed is not related to headless/headed differences, if any. I have only used the Oracle JVM, can't comment on openJDK. There is still room for optimizing the memory usage, we create a lot of objects unnecessarily which even if not a leak puts an extra load on the garbage collector. |
|
|
|
Maybe CfB can comment on the dev team's desire to manage a NXT marketing campaign?
Ask Jean-Luc, he is the captain. Manage? Not me, I have no time and abilities for that. I hardly have the time to catch up with the posts here. Developers should do coding, marketeers should do marketing. Otherwise yes, I agree the marketing campaign is very important. |
|
|
|
Jean Luc Picard of the USS Enterprise....  I had to do it...it was just too tempting Edit: USS Nxterprise boldly go where no Crypto has gone before. In a hindsight, I have really picked up an appropriate pseudonym. I never imagined I will make the progress from a forum Newbie to a Captain that fast. I hereby appoint CfB as my First Officer. Now that the USS NRS Enterprise has been making successful test flights, we have to get ready for our first trip outside the solar system, scheduled for Jan 03. I am now proof-reading the code for any visible bugs. The memory leak has been fixed and I hope version 0.4.8 should have lower memory consumption and not require periodic restart. Next, there are some minor thread safety bugs I noticed that I will fix. I can also think of some optimization in the peer networking code, right now we create a lot of temporary byte[] and char[] that put extra load on the garbage collector and increase the memory usage too, but this is not urgent. I need to do some refactoring of the code, because now everything is in one huge file. The parts that are to remain closed source will have to be factored out, as much as possible, in separate classes, so that they can be distributed in compiled form, still allowing one to work on the base open source part without having the complete source. I also need to pick up a repository where we should host the source code, and prepare it for the Jan 03 launch. Probably github, but I need to investigate the alternatives. |
|
|
|
Account Balances pageI wanted to share a small piece of html/javascript that I wrote today to be able to keep track of multiple account balances at once. Save this under webapps/root/accountBalances.html : <!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8"/>
<title>Nxt Account Balances</title>
<style type="text/css">
table {border-collapse: collapse;}
td {padding: 5px;}
.result {white-space: pre; font-family: monospace;}
</style>
<script type="text/javascript">
function getAccountBalances(form) {
var accounts = form.elements["accounts"].value.split('\n');
var balance = 0;
var result = '<table><tr><th>account</th><th>balance</th></tr>';
for (i = 0; i < accounts.length; i++) {
account = accounts[i].trim();
if (account != '') {
var accountBalance = getBalance(accounts[i]) / 100;
result += '<tr><td>';
result += account;
result += ':</td><td>';
result += formatAmount(accountBalance);
result += '</td></tr>';
balance += accountBalance;
}
}
result += '<tr><td>total:</td><td>';
result += formatAmount(balance);
result += '</td></tr></table>';
form.getElementsByClassName("result")[0].innerHTML = result;
return false;
}
function getBalance(account) {
var request = new XMLHttpRequest();
request.open("GET", '/nxt?requestType=getBalance&account=' + account, false);
request.send();
return JSON.parse(request.responseText).balance;
}
function formatAmount(amount) {
var digits=[], formattedAmount = "", i;
do {
digits[digits.length] = amount % 10;
amount = Math.floor(amount / 10);
} while (amount > 0);
for (i = 0; i < digits.length; i++) {
if (i > 0 && i % 3 == 0) {
formattedAmount = "'" + formattedAmount;
}
formattedAmount = digits[i] + formattedAmount;
}
return formattedAmount;
}
</script>
</head>
<body>
<b>Get Account Balances:</b><br/>
<form action="/nxt" method="GET" onsubmit="return getAccountBalances(this);">
<table>
<tr>
<td>Accounts:</td>
<td><textarea name="accounts" style="width: 100%; height: auto;" rows="6"></textarea></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
</body>
</html>
Then go to https://localhost:7875/accountBalances.html . Enter your account numbers, one per line, and click submit. If you created several accounts in order to purchase aliases, hallmark servers, mine, etc, I find it useful to be able to check all your balances on one page.
|
|
|
|
But I guess this is an example of if you send to the wrong account that may not have a "buyer". Like what just happened to someone. The ability to cancel the transaction so your funds don't get lost in a random account.
I would keep such a feature out of the core. A user-friendly client may implement something like that entirely in the client - after clicking on send, the transaction goes into a list of "ready to send" transactions, and the user has to click on a second "confirm" button after double checking everything again. And the client may show a warning if the receiving account is not in personal address book, etc. |
|
|
|
Since we are deciding about features... what about reversible transactions? Mastercoin is planning to have this..
Isn't that what Two-Phase Payments is about? Like an escrow, the payment is released to the seller only after the buyer confirms receipt of the purchase with a second transaction. |
|
|
|
|
I vote for Mixing too, not having to rely on external mixing services for anonymity. After the Asset Exchange, that would be a killer feature that no other currency has at the moment.
|
|
|
|
0.4.7e on 46.165.208.107:32151 , now at: 24226 10105875265190846103 Wed 25 Dec 2013 02:29:28 PM EET
0 0 + 0 0 B
1 15185855132775691856 2308 %
|
|
|
|
|
Yes, looks like somebody found an integer overflow bug. Account.balance is long, but Transaction.amount and Transaction.fee are integers. My guess is that somewhere in the transaction validation code those are subtracted in a way that gives a value < Integer.MIN_VALUE, which overflows and becomes a positive. So a transaction with fee exceeding the account balance is wrongly considered valid. Or something along those lines.
Anyway, the result is that the blockchain after the corrupted block is invalid, but the current client code does not know that. Once the bug is fixed, and the blockchain rescanned, it should reject the block with the invalid transaction and start a new fork. Hopefully BCNext and CfB can provide a fix soon. In the meantime, I would advise everybody not to do any transactions - because they will all be recorded in a chain that is going to be orphaned after the fix.
|
|
|
|
I forgot that some people still use web interface.
Hmm... so you yourself use a super-secret native client, unlike us mere mortals.  |
|
|
|
I am getting: 2013-12-24 16:04:47.304:WARN:oejs.DoSFilter:qtp1260709007-101: DOS ALERT: Request delayed=1000ms ip=127.0.0.1,session=null,user=null
2013-12-24 16:04:48.933:WARN:oejs.DoSFilter:qtp1260709007-112: DOS ALERT: Request delayed=1000ms ip=127.0.0.1,session=null,user=null
2013-12-24 16:04:50.482:WARN:oejs.DoSFilter:qtp1260709007-116: DOS ALERT: Request delayed=1000ms ip=127.0.0.1,session=null,user=null
2013-12-24 16:04:52.077:WARN:oejs.DoSFilter:qtp1260709007-136: DOS ALERT: Request delayed=1000ms ip=127.0.0.1,session=null,user=null
2013-12-24 16:04:53.631:WARN:oejs.DoSFilter:qtp1260709007-110: DOS ALERT: Request delayed=1000ms ip=127.0.0.1,session=null,user=null
in the log while my browser window is open. As soon as I close it, those warnings stop. Aren't we mistakenly identify as a DOS attack the regular javascript requests from localhost? Is it possible to exclude requests from localhost from the DoSFilter? |
|
|
|
The CLOSE_WAIT problem is back... nxt@n02:~$ netstat -a -n | grep CLOSE | wc
91692 550152 7335360
Then it just stops responding, there is no exception in the log, CPU load is very low, but nothing is happening. Only restart of jetty fixes it. |
|
|
|
Just upgraded the well-known node that I run, 46.19.137.116 to the maximum my VPS provider offers, 8 CPU / 16 GB ram. It is at block 22350 now. Had to help it a bit by copying the latest blocks.nxt and transactions.nxt from my home laptop |
|
|
|
|
Show Posts
