It was the Bitcointalk forum that inspired us to create Bitcointalksearch.org - Bitcointalk is an excellent site that should be the default page for anybody dealing in cryptocurrency,
since it is a virtual gold-mine of data. However, our experience and user feedback led us create our site;
Bitcointalk's search is slow, and difficult to get the results you need, because you need to log in first to find anything useful - furthermore, there are rate limiters for their search functionality.
The aim of our project is to create a faster website that yields more results and faster without having to create an account and eliminate the need to log in -
your personal data, therefore, will never be in jeopardy since we are not asking for any of your data and you don't need to provide them to use our site with all of its capabilities.
We created this website with the sole purpose of users being able to search quickly and efficiently in the field of cryptocurrency
so they will have access to the latest and most accurate information and thereby assisting the crypto-community at large.
Moved explorer to US. Europe/Asia users may notice some lags.
Probably before mainnet I'll move it back to Europe into much stronger server. I'm afraid that once mainnet will launch there will be quite high traffic for couple of days.
akhavr@yoga14 ~/src $ git clone https://github.com/OrdinaryDude/elastic-miner.git [...] akhavr@yoga14 ~/src $ cd elastic-miner akhavr@yoga14 ~/src/elastic-miner $ ./compile.sh javac: file not found: src/evil/ElasticPL/*.java Usage: javac use -help for a list of possible options akhavr@yoga14 ~/src/elastic-miner $ ls src elastic_miner ElasticPL
Fixing it is a no-brainer, yet, it better be fixed. Need a pull request?
Also, starting miner gives
Code:
Retrieving work from server screwed up, most likely due to garbaged response. java.lang.NullPointerException at java.math.BigInteger.(BigInteger.java:415) at elastic_miner.Main.main(Main.java:75)
nxt.http.ParameterException at nxt.http.ParameterParser.getAccount(ParameterParser.java:243) at nxt.http.GetAccountTransactions.processRequest(GetAccountTransactions.java:28) at nxt.http.APIServlet.process(APIServlet.java:209) at nxt.http.APIServlet.doGet(APIServlet.java:153) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:800) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:497) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:313) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:626) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:546) at java.lang.Thread.run(Thread.java:745)
I'm using latest git version of elastic-reference-client
This was a very important catch! This stress tested source-code pruning, meaning that source code that is older than 24 hours (testnet) can be safely removed from the blockchain. There was a little bug which you found and which is fixed now! Thanks for testing!
Everytime I found something serious I'm happy so I'm glad I can help as much as I can
thank you ! You are another great asset along with EK for this project. Can't wait to see us mainstream with wallet and in exchanges ! Great Job !
Because Elastic mining really doesn't behave like the more traditional coins, maybe it should treat mining more like how a pool looks at it. In this case there would be a fixed number of XEL per pow block and instead of all or nothing, you would get a percent based on how much hash you contribute. So the target would only effectively be used to throttle the amount of POW submissions, and it could be set differently for different miners on the same block which just alters their percent of the reward.
I'd have to think more if there are any downsides but the more I been looking into mining xel, the network really looks like one big pool to me. The pow mining is just shares to determine your percent of the pow reward for that algo, and the bounty is equivalent to the pool finding a block, and even that should probably be distributed evenly across miners (not 100% sure if that would be correct).
Anyway, this idea may be way off base, but I think with xel we need to think outside the box.
This would leave the risk that a big miner could drive up the difficulty, then go offline leaving the remaining miners with such a difficult target that they may not get a POW reward for hours or days.
Could you please explain a little more how it is determined which Work Algo the miner gets (i.e. if there are currently 5 projects out there with different algos, how does the network decide which one I get). If it's simply distributed evenly, then there may not be any issue here regarding the re-targeting; however, if there is a way for the miner to pick which algo they work on, then I would think they will figure out how to always go after the one with the best profitability based on difficulty / reward leaving some algos without any miners interested in working on them.
Actually, the miner can pick whichever work he likes. We had a debate over this a few months ago and we decided to leave it up to the miners. Some surely just want to contribute to specific programs (like the work owner wants to work for himself only, or someone has a specific hardware like GPUs which is siutable for specific works only). Other miners also may have different goals: some may want the steady income from the POW submissions, others go "all in" and mine those works with the greatest bounty fund in the hope to make the big score.
Yes, it may leave several works "untouched", but this is the "market aspect". If your work finds no miner on the market, you have to rethink the rewards/payouts you configured
This would leave the risk that a big miner could drive up the difficulty, then go offline leaving the remaining miners with such a difficult target that they may not get a POW reward for hours or days.
This one is indeed a tough one! Any idea? I thought it could be an option to leave it as it is right now, and give a hard limit to the number of unconfirmed POW inside the memory pool. This would "softly" limit the impact of flooding those POW bursts. Even a block creator could only include a limited number of POW in a block since the block is limited by the maximum block size This is not a perfect solution though, i think!
I thought maybe we could only average over the last blocks that HAD at least on POW included, but not sure if this is the right way to go.
This would leave the risk that a big miner could drive up the difficulty, then go offline leaving the remaining miners with such a difficult target that they may not get a POW reward for hours or days.
Could you please explain a little more how it is determined which Work Algo the miner gets (i.e. if there are currently 5 projects out there with different algos, how does the network decide which one I get). If it's simply distributed evenly, then there may not be any issue here regarding the re-targeting; however, if there is a way for the miner to pick which algo they work on, then I would think they will figure out how to always go after the one with the best profitability based on difficulty / reward leaving some algos without any miners interested in working on them.
This was a very important catch! This stress tested source-code pruning, meaning that source code that is older than 24 hours (testnet) can be safely removed from the blockchain. There was a little bug which you found and which is fixed now! Thanks for testing!
Everytime I found something serious I'm happy so I'm glad I can help as much as I can
2016-09-17 14:40:20 INFO: Finished blockchain download 2016-09-17 14:40:22 INFO: Blockchain download in progress 2016-09-17 14:40:22 SEVERE: Error in blockchain download thread java.lang.NullPointerException at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:106) at nxt.Appendix$PrunableSourceCode.validate(Appendix.java:575) at nxt.TransactionImpl.validate(TransactionImpl.java:1014) at nxt.BlockchainProcessorImpl.validateTransactions(BlockchainProcessorImpl.java:1434) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:1326) at nxt.BlockchainProcessorImpl.access$1200(BlockchainProcessorImpl.java:38) at nxt.BlockchainProcessorImpl$1.downloadBlockchain(BlockchainProcessorImpl.java:550) at nxt.BlockchainProcessorImpl$1.downloadPeer(BlockchainProcessorImpl.java:270) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:175) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2016-09-17 14:40:22 INFO: Finished blockchain download 2016-09-17 14:40:23 INFO: Blockchain download in progress 2016-09-17 14:40:24 SEVERE: Error in blockchain download thread java.lang.NullPointerException at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:106) at nxt.Appendix$PrunableSourceCode.validate(Appendix.java:575) at nxt.TransactionImpl.validate(TransactionImpl.java:1014) at nxt.BlockchainProcessorImpl.validateTransactions(BlockchainProcessorImpl.java:1434) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:1326) at nxt.BlockchainProcessorImpl.access$1200(BlockchainProcessorImpl.java:38) at nxt.BlockchainProcessorImpl$1.downloadBlockchain(BlockchainProcessorImpl.java:550) at nxt.BlockchainProcessorImpl$1.downloadPeer(BlockchainProcessorImpl.java:270) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:175) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
Same story on two my nodes after del nxt_test_db
This was a very important catch! This stress tested source-code pruning, meaning that source code that is older than 24 hours (testnet) can be safely removed from the blockchain. The bug was that, after pruning, the source code was still tried to be executed!
There was a little bug which you found and which is fixed now! Thanks for testing!
2016-09-17 14:40:20 INFO: Finished blockchain download 2016-09-17 14:40:22 INFO: Blockchain download in progress 2016-09-17 14:40:22 SEVERE: Error in blockchain download thread java.lang.NullPointerException at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:106) at nxt.Appendix$PrunableSourceCode.validate(Appendix.java:575) at nxt.TransactionImpl.validate(TransactionImpl.java:1014) at nxt.BlockchainProcessorImpl.validateTransactions(BlockchainProcessorImpl.java:1434) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:1326) at nxt.BlockchainProcessorImpl.access$1200(BlockchainProcessorImpl.java:38) at nxt.BlockchainProcessorImpl$1.downloadBlockchain(BlockchainProcessorImpl.java:550) at nxt.BlockchainProcessorImpl$1.downloadPeer(BlockchainProcessorImpl.java:270) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:175) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2016-09-17 14:40:22 INFO: Finished blockchain download 2016-09-17 14:40:23 INFO: Blockchain download in progress 2016-09-17 14:40:24 SEVERE: Error in blockchain download thread java.lang.NullPointerException at java.io.ByteArrayInputStream.(ByteArrayInputStream.java:106) at nxt.Appendix$PrunableSourceCode.validate(Appendix.java:575) at nxt.TransactionImpl.validate(TransactionImpl.java:1014) at nxt.BlockchainProcessorImpl.validateTransactions(BlockchainProcessorImpl.java:1434) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:1326) at nxt.BlockchainProcessorImpl.access$1200(BlockchainProcessorImpl.java:38) at nxt.BlockchainProcessorImpl$1.downloadBlockchain(BlockchainProcessorImpl.java:550) at nxt.BlockchainProcessorImpl$1.downloadPeer(BlockchainProcessorImpl.java:270) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:175) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
There are these two little missing pieces before we can say that the testnet is stable!
1. Netsplits
Imagine that I generate a lot of POW for the current block's target! A different node then generates a block and I, before I get notified about the new block, rebroadcast my pending, unconfirmed POW. Since the target value changed for the new block (that the other peer is aware of) the unconfirmed transactions that I sent him will be invalid, because they do not meat the new block's target value! He, and possible others, then ban us and sends us on a fork!
2. Malicious retarget
The POW difficulty retarget scales with every block, and averages a sliding window over the last 3 blocks and how many POW submissions they had. However, after there was a short period without work, there will be of course 3 consecutive blocks without POW submissions, and as a consequence the target value will be "minimal" again once a work will be created. This will cause bursts of HUGE numbers of POW submissions. We need a solution for that!
I thought maybe we could only average over the last blocks that HAD at least on POW included, but not sure if this is the right way to go.
Been a while since I've used a NXT wallet, but i'm having an issue. I keep getting the error "Could not validate unsigned bytes returned by the server". This happens if I try to update my account, send xel, or submit work. Screenshot below:
