It can't take that long to learn Java right? I picked up php/sql in a few days...
Sorry, it's too late now. Once you start with php, you will never think in Java the right way.  |
|
|
|
Gets stuck at block 60. This is on Debian, compiled from source. verify solution - 4724 / 1968 / 1026119530
verify solution - 4724 / 1968 / 1026119530
Ensure grant database up to date 20
Grant database has processed too many blocks. Needs to be rebuilt. 40ERROR: ConnectBlock() : grant awards error
InvalidChainFound: invalid block=0001778d4a0f24092da5f20d47c513e5f2da41053c49e0af03c8100e42ee058b height=61 log2_work=19.179078 date=2013-12-15 18:39:06
InvalidChainFound: current best=000109eb135d502854382cf8709c25a877e2776f2462daa5c2d8ca6da1112193 height=60 log2_work=19.076307 date=2013-12-15 17:56:25
verify solution - 4724 / 1968 / 1026119530
InvalidChainFound: invalid block=001f7e66a0424a399d7dfb62fd648deb167e43879d6b4eaaf70c1d63330f3983 height=40 log2_work=13.120562 date=2013-12-15 14:18:54
InvalidChainFound: current best=000109eb135d502854382cf8709c25a877e2776f2462daa5c2d8ca6da1112193 height=60 log2_work=19.076307 date=2013-12-15 17:56:25
verify solution - 6468 / 1968 / 4147875085
verify solution - 6468 / 1968 / 4147875085
and again and again. Failed again after starting from scratch. Giving up, this is a waste of time. |
|
|
|
The debian build still has problems due to an old version of cmake...
I got it to build with the version from backports. |
|
|
|
Delete the DB and start again
I already did, twice. |
|
|
|
Gets stuck at block 60. This is on Debian, compiled from source. verify solution - 4724 / 1968 / 1026119530
verify solution - 4724 / 1968 / 1026119530
Ensure grant database up to date 20
Grant database has processed too many blocks. Needs to be rebuilt. 40ERROR: ConnectBlock() : grant awards error
InvalidChainFound: invalid block=0001778d4a0f24092da5f20d47c513e5f2da41053c49e0af03c8100e42ee058b height=61 log2_work=19.179078 date=2013-12-15 18:39:06
InvalidChainFound: current best=000109eb135d502854382cf8709c25a877e2776f2462daa5c2d8ca6da1112193 height=60 log2_work=19.076307 date=2013-12-15 17:56:25
verify solution - 4724 / 1968 / 1026119530
InvalidChainFound: invalid block=001f7e66a0424a399d7dfb62fd648deb167e43879d6b4eaaf70c1d63330f3983 height=40 log2_work=13.120562 date=2013-12-15 14:18:54
InvalidChainFound: current best=000109eb135d502854382cf8709c25a877e2776f2462daa5c2d8ca6da1112193 height=60 log2_work=19.076307 date=2013-12-15 17:56:25
verify solution - 6468 / 1968 / 4147875085
verify solution - 6468 / 1968 / 4147875085
and again and again. |
|
|
|
I got tired of typing api requests manually in the browser url, and put together a single html page with the ones I most commonly use. To run it from localhost, save it as nxt/webapps/root/admin.html and then go to https://localhost:7875/admin.html . You can see what it looks like at https://nxt.airdns.org:7875/admin.html . Here is the source: <!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8"/>
<title>NRS</title>
<style type="text/css">
table {border-collapse: collapse;}
td {padding: 10px;}
.result {white-space: pre; font-family: monospace;}
</style>
<script type="text/javascript">
function submitForm(form) {
var url = '/nxt?';
for (i = 0; i < form.elements.length; i++) {
if (! form.elements[i].name) {
continue;
}
if (! url.endsWith('?')) {
url += '&';
}
url += encodeURIComponent(form.elements[i].name);
url += '=';
url += encodeURIComponent(form.elements[i].value);
}
var request = new XMLHttpRequest();
request.open("GET", url, false);
request.send();
var result = JSON.stringify(JSON.parse(request.responseText), null, 4);
form.getElementsByClassName("result")[0].textContent = result;
return false;
}
</script>
</head>
<body>
<h3>Nxt admin tools</h3>
<b>Generate Hallmark:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="markHost"/>
<table>
<tr>
<td>Public IP:</td>
<td><input type="text" name="host"/></td>
</tr>
<tr>
<td>Weight:</td>
<td><input type="number" name="weight" value="100"/></td>
</tr>
<tr>
<td>Date:</td>
<td><input type="text" name="date" value="2013-12-10"/></td>
</tr>
<tr>
<td>Secret Phrase:</td>
<td><input type="password" name="secretPhrase"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Verify Hallmark:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="decodeHallmark"/>
<table>
<tr>
<td>Hallmark:</td>
<td><input type="text" name="hallmark"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Verify Token:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="decodeToken"/>
<table>
<tr>
<td>Token:</td>
<td><input type="text" name="token"/></td>
</tr>
<tr>
<td>Website:</td>
<td><input type="text" name="website"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Get Peers:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="getPeers"/>
<table>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Get Peer Info:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="getPeer"/>
<table>
<tr>
<td>Peer:</td>
<td><input type="text" name="peer"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Get State:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="getState"/>
<table>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Get My Info:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="getMyInfo"/>
<table>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
<hr>
<b>Get Account Balance:</b><br/>
<form action="/nxt" method="GET" onsubmit="return submitForm(this);">
<input type="hidden" name="requestType" value="getBalance"/>
<table>
<tr>
<td>Account:</td>
<td><input type="text" name="account"/></td>
</tr>
<tr>
<td colspan="2"><input type="submit" value="submit"/></td>
</tr>
</table>
<div class="result"></div>
</form>
</body>
</html>
|
|
|
|
I have an idea.
We could split development among different people to speed things greatly. If my team and me worked on core functions only then we would get advanced features much more earlier. NRS could be a headless server soft and clients would just connect to local private or remote public nodes that run NRS. Transactions can be signed on client side, so it's secure.
R there any bounties for developers and tech support? We could pay to those who create client software or run public nodes.
Also NRS would work much more stable if I got rid of all code related to web interface. Right now it's a monolithic block of code, no MVC pattern at all.
I would volunteer to help with the server-side work once the source is public. I am not much of a UI guy, so can't help with the clients, but I have been doing server-side java on linux for more than 10 years now. Hey, and as a stakeholder I will not be asking for a bounty, I contribute so that I increase the value of my investment. Can't wait to replace few of those HashMaps with ConcurrentHashMap too... |
|
|
|
[2013-12-12 22:32:53.596] Loading blocks...
[2013-12-12 22:32:55.176] ...Done
[2013-12-12 22:32:55.177] Scanning blockchain...
[2013-12-12 22:32:57.183] 10: java.lang.NullPointerException
2013-12-12 22:32:57.184:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@4093b096{/,file:
/home/nxt/nxt/webapps/root/,AVAILABLE}{/root}
2013-12-12 22:32:57.305:INFO:oejs.ServerConnector:main: Started ServerConnector@48265f7f{HTTP/1.1}{0.0
.0.0:7874}
2013-12-12 22:32:58.496:INFO:oejs.ServerConnector:main: Started ServerConnector@13cd6d16{SSL-http/1.1}
{0.0.0.0:7875}
nxt.airdns.org got stuck with the above NullPointerException which prevented the blockchain from loading. Copying over the .bak files didn't help, had to get all .nxt files from another machine. |
|
|
|
Now time for bad news.
BCNext is becoming more and more angry coz of stakeholders who don't help Nxt. They don't run their nodes, they don't support bounties, they don't take part in Nxt promotion.
All of us that spend most of their waking hours following Nxt development tend to forget that not everybody has that time, technical knowledge, and interest, to do so. Those "stakeholders", me including, tend to invest in a variety of crypto-related things. Somebody with a full time job absolutely doesn't have the time to follow the development in all the areas he has invested in, let alone actively participate. Let's not forget that the maximum investment was capped at 1BTC. This is not a huge amount at all, for somebody investing in crypto. I myself have invested more than that for example in Mastercoin, and have spent time and money worth more than 1BTC mining ProtoShares. Yet I don't have time to check the progress of those two projects more than about once a week. It is just diversification, people don't put all their eggs in one basket. In any such project most of the investors will be just that - passive investors. You cannot blame them for not having the time and technical ability to participate. I do it with Nxt because it happens to be in Java and I hope to be able to contribute as a developer. I don't have the time to figure out the intricate Mastercoin protocols and the long term vision behind ProtoShares, so my investment in those projects is passive. Many of the Nxt stakeholders may have the same attitude towards Nxt - they put some money in it, just in case, and moved on because they are busy with other things. We have to accept it as normal, and BCNext should not risk ruining the whole project because of that. |
|
|
|
Finally managed to have the hallmark done and decoded correctly, after manually encoding all special characters.
I also did this once, and then decided nobody should have to do it manually. So here is a very simple html form one can use to generate hallmark, letting the browser take care of the encoding. No javascript tricks, plain old html. Save this file as nxt/webapps/root/markHost.html and then go to https://localhost:7875/nxt/markHost.html . <html>
<head><title>Generate a Hallmark for your NXT node</title></head>
<body>
<form action="/nxt" method="GET">
<input type="hidden" name="requestType" value="markHost"/>
<table>
<tr>
<td>Public IP:</td>
<td><input type="text" name="host"/></td>
</tr>
<tr>
<td>Weight:</td>
<td><input type="number" name="weight" value="100"/></td>
</tr>
<tr>
<td>Date:</td>
<td><input type="text" name="date" value="2013-12-10"/></td>
</tr>
<tr>
<td>Secret Phrase:</td>
<td><input type="password" name="secretPhrase"/></td>
</tr>
<tr>
<td><input type="submit" value="submit"/></td>
<td></td>
</tr>
</table>
</form>
</body>
</html>
This warning is still valid. I tried to use POST instead of GET, but then I get a NullPointerException. Once this is fixed, the above form should be changed to use POST and the secretPhrase will not appear in the browser history. |
|
|
|
Full blockchain downloading took almost half an hour to complete jumping from one node to another (which adds a little overhead) on 1 Mbps connection.
There r 2 options for optimization:
- Switch to binary protocol instead of JSON-based (~3x improvement, I prefer to stick to JSON until we get some alt-clients, JSON greatly lowers entry threshold for new programmers)
- Add GZIP compression (~10x improvement)
Or we can leave it as is for the time being.
Any suggestions?
I also prefer to keep it JSON, and add a gzip filter on top. But why is it so slow to begin with? My blocks.nxt file takes 4.6M and transactions.nxt 0.5M. Is it because it is downloading it in way too many small pieces, one block at a time, and makes a new connection each time? If so, I would thing the biggest performance boost would come from downloading it in batches, many blocks in one go, rather than trying to compress each block download separately. |
|
|
|
Please, please, I beg you, bruteforce my tiny account! It is only 9 digits! I haven't sent a bit... oups, NXT from it! So it all be yours!  Or stop spreading bullshit here  I was worried about that, but no, brute forcing 9-digit account is not any easier than brute forcing 20-digit account. It is just that the first 11 digits are zeros. But you still need to match the full 64 bits, including all starting zeros. |
|
|
|
That might be a problem for offline or paper wallet creation. Something I would like to see in future. Since when offline it can't be known if an account already exists.
Yes, but one can work around it. All that has to be done is the public key of the account needs to be announced to the network somehow. You can sign a transaction (send 1Nxt to yourself) on an air-gapped computer, then broadcast it to the network using a connected computer. Or a special transaction type could be created, which purpose is just to announce the public key of the account, with zero amount of money moving and no fee. When you try to broadcast that transaction to the network, you will get an error if the account already exist. Then you just need to try again, generate a new account number offline. It is extremely unlikely though - unless you used a common password and not a randomly generated one. |
|
|
|
I started writing this post in reply to http://nextcoin.org/index.php/topic,471.msg3484.html#msg3484 , only to find that the thread has been locked before I was able to post it. So copying it here: transactions.nxt still contains public keys data.
Then I am correct, you need at least one outgoing transaction before the full public key of an account is stored in transactions.nxt. After that, the full 256 bits are used. But before any outgoing transactions, it is physically not possible for the network to know the account public key - let's say I generated an account using the vanity generator, and gave the account number to someone to send me money. I have never entered my password in the client yet, the account public key could not possibly be known to the network yet. One other thing I want to point out, the maximum possible password length is irrelevant when trying to evaluate the risk of collisions. Of course, if you use 100000 character passwords, the number of collisions will be enormous. However all that means is that you don't need a 100000 character password. To determine the brute force resources required to find a collision all that matters is the total number of different accounts possible - which currently is 2^64 if you compare account id only, or 2^256 if you compare the full 256-bit public key. Second, it matters how long it takes you to calculate an account number given a password. You cannot indeed compare with bitcoin and the sha-256 hashing power of the bitcoin network, because in addition to sha-256 Nxt is using curve25519 - and there are no asics that calculate that (actually... I don't know, the bitcoin mining asics certainly don't, but who knows what type of hardware NSA has). Assuming a perfect distribution, you need to try 2^64 different passwords to generate all possible 2^64 account numbers (ignoring the full-public key comparison). So how fast can one do that? On my laptop, with the Vanity.java code I posted on bitcointalk, I can go through 8000 passwords per seconds. This means it will take me 2^64/(8000*3600*24*365) = 73,117,802 years to generate all possible account numbers and have a 100% certainty that the one I am after has been found. Somebody doing this exercise of course will not be after one account only, but would be creating a rainbow table to be used against any account created now or in the future. But try to estimate how much storage space this rainbow table will require... And that's only for accounts which have only ever received transactions, with no outgoing transactions. Once you send money from your account, its public key gets known to the network, so the account is protected to 2^256 against collisions - try the above calculation now again. |
|
|
|
@ miners: next version will include activated hallmark protection for outbound traffic, u may see increased rate of orphaned blocks if u don't mark ur node.
If you do that, could you also add the option to advertise a port number other than the default 7874, in myAddress and in the hallmark? Jetty can still listen on 7874, I would use iptables or ssh to do the forwarding. This would let me put several nodes behind the same VPN public IP and use one for mining, another for serving as bootstrapping node. |
|
|
|
depends on your system, a ctr-c sends a sigint (2) to stop the process gracefully, which should be fine.
a sigterm (15) also but more stringent. a sigkill (9) just pulls the plug, not good because the process
can't clean up gracefully. in this case a possible broken file descryptor damaged the file.
Before going all the way for kill -9, I usually try kill -6, and so far -6 hasn't damaged the files. |
|
|
|
Done, thanks. I see my IP shows, how do I get my dns to be the one thats showing instead of my IP?
I just put the hostname there instead of the IP. Both under myAddress in the web.xml file, and also when generating the hallmark. Can you explain the weighted thing more? Should I transfer more of my coins to my dedicated VPS for whatever the weighted reason might be?
Not sure what you mean transfer the coins. You never need to unlock your account at the VPS. If you have several accounts, and only one public IP (the VPS), use the account with the highest balance when generating the hallmark. I don't know if CfB provided a way to combine the balance of several accounts to vouch for one node, probably not. |
|
|
|
I had to clear the browser cache to get to see the peer weights. Indeed too few have added it. Clearing the peers.nxt file may also be a good idea at this release, to remove the blacklisted. The disappearing balance bug is unfortunately still present. |
|
|
|
when I'm putting in my hallmark code do i need to have {"hallmark":" in from the code?
No, just the very long string of characters after that. Without the quotes. |
|
|
|
If you are running it behind a router, as most home users would do, just keep 7874 and 7875 closed, which is probably the router default. To have them accessible from the outside you have to intentionally set up port forwarding of those two ports at the router. To repeat the parameters for using tor: java -DsocksProxyHost=127.0.0.1 -DsocksProxyPort=9050 -Xmx1024M -jar start.jar
|
|
|
|
|
Show Posts
