For those who know Mr. David Brin:
https://twitter.com/kLee1977/status/410766480980975616
Topic: NXT :: descendant of Bitcoin - Updated Information - page 2408. (Read 2761645 times)
Version 0.3.18 - https://dl.dropboxusercontent.com/u/67242472/nxt.zip
Enabled hallmark protection for outbound requests
Added code for migration to non-standard ports for peer communication
Added code for migration to other blockchain file format (check "blockchainStoragePath" in web.xml, u can use absolute paths)
Added http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds
If u announce address of ur host via "myAddress" u must set it to the "host" value returned by http://otherserver.com:7874/nxt?requestType=getMyInfo . In one of the next versions nodes will begin checking that it matches the address returned by http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
More info about the hallmark protection
Now marked hosts will attract more traffic. There r 2 types of outbound requests - Send (for getting unknown unconfirmed transactions, for blockchain downloading) and SendToAll (for pushing blocks and transactions). Send picks one of the connected peers depending on their weight (weighted random hit is made), peers with weight = 0 r considered as having weight = 1. SendToAll sends data to peers according to their weights in descending order.
NB: Those who update to 0.3.18, please, keep 0.3.17 somewhere just in case. Blockchain is dumped to "blockchain.nrs" file when client is closed by pressing CTRL+C.
Enabled hallmark protection for outbound requests
Added code for migration to non-standard ports for peer communication
Added code for migration to other blockchain file format (check "blockchainStoragePath" in web.xml, u can use absolute paths)
Added http://localhost:7874/nxt?requestType=getUnconfirmedTransactionIds
If u announce address of ur host via "myAddress" u must set it to the "host" value returned by http://otherserver.com:7874/nxt?requestType=getMyInfo . In one of the next versions nodes will begin checking that it matches the address returned by http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
More info about the hallmark protection
Now marked hosts will attract more traffic. There r 2 types of outbound requests - Send (for getting unknown unconfirmed transactions, for blockchain downloading) and SendToAll (for pushing blocks and transactions). Send picks one of the connected peers depending on their weight (weighted random hit is made), peers with weight = 0 r considered as having weight = 1. SendToAll sends data to peers according to their weights in descending order.
NB: Those who update to 0.3.18, please, keep 0.3.17 somewhere just in case. Blockchain is dumped to "blockchain.nrs" file when client is closed by pressing CTRL+C.
I guess I am gonna buy a bit more of NXTs while they are super cheap 
+1 
I guess I am gonna buy a bit more of NXTs while they are super cheap
+1 
I guess I am gonna buy a bit more of NXTs while they are super cheap
BCNext decided to make it more interesting to do a review, so the code will contain 3 security flaws - serious, critical and fatal ones.
This is great idea!
Yeah, this guy is full of great ideas.
But others have to implement them.
BCNext decided to make it more interesting to do a review, so the code will contain 3 security flaws - serious, critical and fatal ones.
This is great idea!
Yeah, this guy is full of great ideas.
But others have to implement them.
BCNext decided to make it more interesting to do a review, so the code will contain 3 security flaws - serious, critical and fatal ones.
This is great idea!
A lot of open source software with critical functionality stay untested and unreviewed just because everyone idly consider "open source means no backdoors, no big flaws". Just remember famous OpenSSL random bug!...
- Add GZIP compression (~10x improvement)
I think this can be selectable via request parameter.In Java GZIP is part of standard library and is not a problem at all.
But right now traffic is not a problem. It download full blockchain incredibly slow even on very good internet connection. Block by block, 0.5s for each.
it took me 3 hours a few days ago
I think we should watch Quark, their strategy and reaction of people about it's premining thing:
"I agree that Quark is out of control, but only because of it's currency supply curve. Early blocks accounted for 90%+ of the total currency supply, mined in a very short period. A multimillion USD market cap is scary with such rapid reward halving in the coin by design. Quark was intentionally designed for severe wealth inequality.
90%+ of the currency supply goes to creators/early miners, and this has already occurred. This is important to note for cryptotraders who might see this as an opportunity to "ride the wave" and will further inflate this bubble. The only opportunity this coin provided was for the early miners (if that was even made possible by the creators) and that opportunity is long gone.
PSA- Always consider the following when trying to weed out pump & dump altcoins:
Age of coin
Total coins in existence now
Total currency supply
If it's really new and 90%+ mined already, seems a prime candidate for market manipulation and dumping.
PSA- Always consider the following when trying to weed out pump & dump altcoins:
Age of coin
Total coins in existence now
Total currency supply"
"I agree that Quark is out of control, but only because of it's currency supply curve. Early blocks accounted for 90%+ of the total currency supply, mined in a very short period. A multimillion USD market cap is scary with such rapid reward halving in the coin by design. Quark was intentionally designed for severe wealth inequality.
90%+ of the currency supply goes to creators/early miners, and this has already occurred. This is important to note for cryptotraders who might see this as an opportunity to "ride the wave" and will further inflate this bubble. The only opportunity this coin provided was for the early miners (if that was even made possible by the creators) and that opportunity is long gone.
PSA- Always consider the following when trying to weed out pump & dump altcoins:
Age of coin
Total coins in existence now
Total currency supply
If it's really new and 90%+ mined already, seems a prime candidate for market manipulation and dumping.
PSA- Always consider the following when trying to weed out pump & dump altcoins:
Age of coin
Total coins in existence now
Total currency supply"
This can be a problem for non-Java clients.
Is GZIP not a part of HTTP standard?I'm even thinking that it can be released transparently through any HTTP client library, isn't it?
And I don't believe that in 21st century anyone will write client using pure OS API anyway...
In worst case you can always add parameter to request, to switch gzip on/off, or use different port for compressed traffic.
Aye, I'm going to add a parameter or just increment "protocol" value.
NEWS
On the 3rd of January the source code of basic features will be published for peer review. BCNext decided to make it more interesting to do a review, so the code will contain 3 security flaws - serious, critical and fatal ones. The 1st person who reports one of these flaws in a special thread will get a reward (1'000, 10'000 and 100'000 NXT accordingly). There will be SHA256 hashes of flaw descriptions published, the descriptions will be revealed after the flaws r reported. If some unreported ones left after 3 months, BCNext may decide to reveal them at any time.
PS: This has a nice side-effect, copycats have to wait for full disclosure or do their own research.
On the 3rd of January the source code of basic features will be published for peer review. BCNext decided to make it more interesting to do a review, so the code will contain 3 security flaws - serious, critical and fatal ones. The 1st person who reports one of these flaws in a special thread will get a reward (1'000, 10'000 and 100'000 NXT accordingly). There will be SHA256 hashes of flaw descriptions published, the descriptions will be revealed after the flaws r reported. If some unreported ones left after 3 months, BCNext may decide to reveal them at any time.
PS: This has a nice side-effect, copycats have to wait for full disclosure or do their own research.
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?
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 would compress.
This can be a problem for non-Java clients.
Is GZIP not a part of HTTP standard?I'm even thinking that it can be released transparently through any HTTP client library, isn't it?
And I don't believe that in 21st century anyone will write client using pure OS API anyway...
In worst case you can always add parameter to request, to switch gzip on/off, or use different port for compressed traffic.
In Java GZIP is part of standard library and is not a problem at all.
This can be a problem for non-Java clients.
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.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?
Blocks r feeded in 128 Kb chunks (4 blocks min). I put in todo list to check why it's so slow.
JSON greatly lowers entry threshold for new programmers
... and badly documented API cut off inexperienced noobs - Add GZIP compression (~10x improvement)
I think this can be selectable via request parameter.In Java GZIP is part of standard library and is not a problem at all.
But right now traffic is not a problem. It download full blockchain incredibly slow even on very good internet connection. Block by block, 0.5s for each.
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.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?
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?
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?
Jump to: