Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 22, 2016, 01:57:50 PM |
|
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild". For serious testing, please wait for 0.7.1.
|
|
|
|
coralreefer
|
|
November 22, 2016, 03:13:05 PM |
|
EK, here are a couple of observations.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
|
|
|
|
coralreefer
|
|
November 22, 2016, 03:24:46 PM |
|
EK, here are a couple of observations.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
One more thing, I still can't enter any jobs with crypto functions via the UI, (i.e. if I include "sha256 3 80;" in the job I get a "syntax error")
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 22, 2016, 03:53:52 PM |
|
One more thing, I still can't enter any jobs with crypto functions via the UI, (i.e. if I include "sha256 3 80;" in the job I get a "syntax error")
I think they have to be upper case
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 22, 2016, 03:59:45 PM |
|
EK, here are a couple of observations.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
3. It is hard to say, but right now there are just two options when a duplicate transaction may occur for the POW: a) it is really a duplicate and b) we have reached 20 in this block. Since duplicate POW submissions are nearly impossible if not handcrafted by a script kiddie (look how huge the search space of the deterministic input ints is), I think it is safe to assume that any duplicate message for the POW submission means that the 20 limit kicked in. 1.) 2.) I will try to reproduce them now 4.) Also taking a look on that, maybe 4 eyes see more than 2
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 22, 2016, 05:11:27 PM |
|
Not so sure if the "retargeting" thing works correct. I am seeing far less than the wanted 10 PoW per block:
|
|
|
|
coralreefer
|
|
November 22, 2016, 05:42:59 PM |
|
Not so sure if the "retargeting" thing works correct. I am seeing far less than the wanted 10 PoW per block: Do you think this may simply be due to the work already being at the minimum difficulty?
|
|
|
|
hagie
|
|
November 22, 2016, 06:14:59 PM |
|
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild". For serious testing, please wait for 0.7.1.
just want update my public node to latest git but compile.sh and run.sh is missing intentionally ? regards
|
|
|
|
coralreefer
|
|
November 22, 2016, 06:27:52 PM |
|
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild". For serious testing, please wait for 0.7.1.
just want update my public node to latest git but compile.sh and run.sh is missing intentionally ? regards You'll need to use the build instructions at the following link: http://elastic-project.com/installing_and_running_elastic
|
|
|
|
coralreefer
|
|
November 23, 2016, 03:13:02 AM Last edit: November 23, 2016, 03:50:19 AM by coralreefer |
|
Hi EK, I uploaded an updated miner to my git...I completely rewrote the i/o. Please let me know if this addresses the issue you observed earlier, and if so, I will finish cleaning up this approach.
Edit: I think I spotted one more issue with the submit array. I'll try to fix that issue tomorrow.
|
|
|
|
cyberhacker
Legendary
Offline
Activity: 1330
Merit: 1000
|
|
November 23, 2016, 06:22:56 AM |
|
now we have three projects focusing on decentralized computing: Elastic, Golem, Iex
XEL might be the first open market soon, and personally i estimate market cap should be around 25 million compared to golem and iex.
they are all legit, with somewhat pros and cons. but i believe Elastic is much more ready than those two. and the approach of XEL is more cryptographic than P2P.
So XEL may more catering to blockchain savvy.
I doubted this project at very first phase, but now i am a firm believer.
we have to be optimistic! look at those stupid big for nothing scammy projects in top20.
XEL is 20 times better than those sh*ts. lol
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 08:44:49 AM |
|
Hi EK, I uploaded an updated miner to my git...I completely rewrote the i/o. Please let me know if this addresses the issue you observed earlier, and if so, I will finish cleaning up this approach.
Edit: I think I spotted one more issue with the submit array. I'll try to fix that issue tomorrow.
Hi, coral reefer! Runs stable for now :-) Woow, awesome work. A little thing that I noticed, there is a strong delay before finding a solution and actually submitting it ( in the example below around 6 seconds): Maybe it's because the worker threads "max out" the machine. We could think about giving the IO thread a higher priority, as its mostly idle it should not hurt, but it should help to get the results to the server as quick as possible. However, in this case the worker threads might still "slow down the core client" if its running on the same machine. Another idea, but not sure if too fancy or stupid at all: We could "nice" the worker threads during every IO operation maybe with an additional "grace period", to quickly get the solutions to the core-client and, from there, broadcast to the world. [09:41:45] CPU2: Submitting POW Solution [09:41:45] CPU1: Submitting POW Solution [09:41:46] CPU1: 778.11 kEval/s [09:41:46] CPU1: Submitting POW Solution [09:41:47] CPU2: 792.52 kEval/s [09:41:47] CPU0: 803.76 kEval/s [09:41:49] CPU1: Submitting POW Solution [09:41:51] CPU2: ***** POW Accepted! ***** [09:41:51] CPU1: ***** POW Accepted! ***** [09:41:51] CPU1: ***** POW Accepted! ***** [09:41:51] CPU1: ***** POW Accepted! *****
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 08:53:10 AM Last edit: November 23, 2016, 09:14:28 AM by Evil-Knievel |
|
Also, @coralreefer: I noticed the "does not meet hash anylonger" bug on one of two worker threads suddenly. A restart of xel_miner fixed that. Checking if it's a bug in the retargeting method!
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 10:06:45 AM |
|
Coralreefer: The bug is in the miner.See this: Target was: 000000cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc The miner found these two solutions: [11:03:30] CPU2: Submitting POW Solution (000000F16E65B6C934C0A240E0C6B15EA8B931AEC6F3C80EF3A489A68B54A2EF) [11:03:31] CPU1: 815.32 kEval/s [11:03:31] CPU1: Submitting POW Solution (0000008EC171FDDE9FF4EF22A4995D620940D1D9BCE7F4EE584E6C99495861CA) [11:03:33] CPU0: 828.84 kEval/s [11:03:34] CPU0: ***** POW Accepted! ***** [11:03:34] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc for work_id = 17802030119850927464! *****
Comparison of the hashes to the target: 000000cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc 000000F16E65B6C934C0A240E0C6B15EA8B931AEC6F3C80EF3A489A68B54A2EF 0000008EC171FDDE9FF4EF22A4995D620940D1D9BCE7F4EE584E6C99495861CA You see that the first one, 0x000000F16..., is certainly bigger than the target 0x000000CC... and so the error message is valid! (Edit: I have created a pull request including the additional debug output)
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 10:24:28 AM |
|
Found the bug @coralreefer: g_pow_target is not getting updated! Example: Target is: e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 g_pow_target is: 000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally. [11:22:43] CPU1: Submitting POW Solution (00000050469D1E28E55464C705DF2AECCDFA78570B79541EFE425E76342381A7) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF] [11:22:46] CPU1: 789.40 kEval/s [11:22:46] CPU1: Submitting POW Solution (0000008EF17A408A1CD8F56462E153C7DD340BD81B3B50F26794E2AD263770F0) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF] [11:22:47] CPU0: 848.44 kEval/s [11:22:48] CPU2: 846.27 kEval/s [11:22:48] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 for work_id = 17802030119850927464! *****
|
|
|
|
coralreefer
|
|
November 23, 2016, 11:17:01 AM |
|
Found the bug @coralreefer: g_pow_target is not getting updated! Example: Target is: e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 g_pow_target is: 000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally. [11:22:43] CPU1: Submitting POW Solution (00000050469D1E28E55464C705DF2AECCDFA78570B79541EFE425E76342381A7) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF] [11:22:46] CPU1: 789.40 kEval/s [11:22:46] CPU1: Submitting POW Solution (0000008EF17A408A1CD8F56462E153C7DD340BD81B3B50F26794E2AD263770F0) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF] [11:22:47] CPU0: 848.44 kEval/s [11:22:48] CPU2: 846.27 kEval/s [11:22:48] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 for work_id = 17802030119850927464! ***** Thanks for all the feedback EK. I just updated my git with a fix for what I believe was that submit memory leak I've been chasing for days. I also think this may address that 6 sec submit delay you observed earlier. I'll take a look at why the pow target was not getting updated in the miner now.
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 12:23:55 PM |
|
[quote author=coralreefer link=topic=1396233.msg16963757#msg16963757 date=1479899821Thanks for all the feedback EK. I just updated my git with a fix for what I believe was that submit memory leak I've been chasing for days. I also think this may address that 6 sec submit delay you observed earlier. [/quote] Not really ;-) [13:22:45] CPU2: Submitting POW Solution (00000076E9FC4C13674D68E8...) [t:000000FFFFFFFFFFFFFFFFFF...] [13:22:47] CPU0: 876.47 kEval/s [13:22:47] CPU2: 890.56 kEval/s [13:22:47] CPU1: 887.20 kEval/s [13:22:51] CPU2: ***** POW Accepted! ***** I suspect that the delay is due to the high CPU load slowing down the main client and its responsiveness. I'll try something. And, with the latest GIT version, this artefact came up: [13:23:36] CPU0: Submitting POW Solution (0000007CF731DCB4EED0CF97...) [t:000000FFFFFFFFFFFFFFFFFF...] [13:23:36] ERROR: Unknown request type [13:23:36] ERROR: Unknown request type [13:23:36] CPU0: ***** POW Accepted! ***** [13:23:40] CPU1: 796.49 kEval/s [13:23:41] CPU2: 740.96 kEval/s [13:23:41] CPU0: 757.11 kEval/s [13:23:42] ERROR: Unknown request type
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 01:10:06 PM |
|
@coralreefer: I have created a pull request for what I think might be a good thing (renice the miner threads ... and only those ... to +7 in order to ensure system responsiveness). It does not slow down mining noticeably at all. However, it did not really fix the 6 seconds delay bug.
|
|
|
|
unvoid
|
|
November 23, 2016, 01:15:12 PM |
|
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild". For serious testing, please wait for 0.7.1.
Hi hardworking people! @EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up. Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case. Keep up good work.
|
BTC: 1CMgHWx4wkAaAy2FfeCyPdedUExmhGhfi5 XEL: XEL-HCM8-KB6E-YFLK-8BWMF
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
November 23, 2016, 01:24:03 PM |
|
@coralreefer: pull request for a command line option to skip "renice" just submitted ;-) Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild". For serious testing, please wait for 0.7.1.
Hi hardworking people! @EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up. Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case. Keep up good work. Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address. That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks. // Redeemer-Account is not allowed to do any transaction whatsoever if( this.getSenderId() == Genesis.REDEEM_ID && type != TransactionType.Payment.REDEEM){ throw new NxtException.NotValidException( "Redeem Account is not allowed to do anything."); }
|
|
|
|
|