Bitcoin Forum
March 19, 2024, 11:19:58 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 [135] 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 ... 345 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 450418 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
November 22, 2016, 01:57:50 PM
 #2681

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.
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710847198
Hero Member
*
Offline Offline

Posts: 1710847198

View Profile Personal Message (Offline)

Ignore
1710847198
Reply with quote  #2

1710847198
Report to moderator
1710847198
Hero Member
*
Offline Offline

Posts: 1710847198

View Profile Personal Message (Offline)

Ignore
1710847198
Reply with quote  #2

1710847198
Report to moderator
1710847198
Hero Member
*
Offline Offline

Posts: 1710847198

View Profile Personal Message (Offline)

Ignore
1710847198
Reply with quote  #2

1710847198
Report to moderator
coralreefer
Sr. Member
****
Offline Offline

Activity: 464
Merit: 260


View Profile
November 22, 2016, 03:13:05 PM
 #2682

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
Sr. Member
****
Offline Offline

Activity: 464
Merit: 260


View Profile
November 22, 2016, 03:24:46 PM
 #2683

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 Offline

Activity: 1260
Merit: 1168



View Profile
November 22, 2016, 03:53:52 PM
 #2684

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  Wink
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1260
Merit: 1168



View Profile
November 22, 2016, 03:59:45 PM
 #2685

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 Offline

Activity: 1260
Merit: 1168



View Profile
November 22, 2016, 05:11:27 PM
 #2686

Not so sure if the "retargeting" thing works correct. I am seeing far less than the wanted 10 PoW per block:

coralreefer
Sr. Member
****
Offline Offline

Activity: 464
Merit: 260


View Profile
November 22, 2016, 05:42:59 PM
 #2687

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
Hero Member
*****
Offline Offline

Activity: 792
Merit: 501



View Profile
November 22, 2016, 06:14:59 PM
 #2688

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
Sr. Member
****
Offline Offline

Activity: 464
Merit: 260


View Profile
November 22, 2016, 06:27:52 PM
 #2689

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
Sr. Member
****
Offline Offline

Activity: 464
Merit: 260


View Profile
November 23, 2016, 03:13:02 AM
Last edit: November 23, 2016, 03:50:19 AM by coralreefer
 #2690

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 Offline

Activity: 1330
Merit: 1000



View Profile
November 23, 2016, 06:22:56 AM
 #2691

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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 08:44:49 AM
 #2692

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.

Code:
[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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 08:53:10 AM
Last edit: November 23, 2016, 09:14:28 AM by Evil-Knievel
 #2693

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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 10:06:45 AM
 #2694

Coralreefer:

The bug is in the miner.
See this:

Target was:
Code:
000000cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

The miner found these two solutions:
Code:
[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:
Code:
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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 10:24:28 AM
 #2695

Found the bug @coralreefer:

g_pow_target is not getting updated!

Example:

Target is:
Code:
e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229

g_pow_target is:
Code:
000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally.

Code:
[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
Sr. Member
****
Offline Offline

Activity: 464
Merit: 260


View Profile
November 23, 2016, 11:17:01 AM
 #2696

Found the bug @coralreefer:

g_pow_target is not getting updated!

Example:

Target is:
Code:
e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229

g_pow_target is:
Code:
000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally.

Code:
[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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 12:23:55 PM
 #2697

[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 ;-)
Code:
[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:

Code:
[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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 01:10:06 PM
 #2698

@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
Hero Member
*****
Offline Offline

Activity: 535
Merit: 500



View Profile
November 23, 2016, 01:15:12 PM
 #2699

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 Offline

Activity: 1260
Merit: 1168



View Profile
November 23, 2016, 01:24:03 PM
 #2700

@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.

Code:
// 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.");
}
Pages: « 1 ... 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 [135] 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 ... 345 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!