[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[chris_nor]

When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.

2 months

2 month AFTER testnet runs stable

I think we should take some date at some point that we will launch mainnet. Saying over and over "two months" or "three weeks" like @Lannister predicted isn't healthy for Elastic. We have competition as all of you know.

We will have bugs always. Even after mainnet. Thing is, when we believe that we have software that is able to be mainnet release we have to release it.

We can sit and wait forever as @EK develop Elastic but at some point we have to go mainstream. Sitting here for two/four/twelve more months isn't something that will transform into successful cryptocurrency.

Don't get me wrong. We need solid project before mainnet. But we have to at some point decide that this is time for action.

I didn't invested in Elastic much (much less than 0.5BTC). I just believe in this idea and I try to help as much as I can.

If you all end with endless loop of "we will release mainnet after X" I don't give a shit about it.

I just hope that this project have sense and:
1) will be successful, or
2) will be inspiration for better project this kind

We are observing Golem and other projects. Do not think that they are not watching us.

Clicking on random pages I see that you post a lot in this thread, so it's pretty amazing that you've only invested less than .5BTC. I hope it's because you already have to much money.

[1714308468]

1714308468

[1714308468]

1714308468

[1714308468]

1714308468

[1714308468]

1714308468

[1714308468]

1714308468

[unvoid]

Clicking on random pages I see that you post a lot in this thread, so it's pretty amazing that you've only invested less than .5BTC. I hope it's because you already have to much money.

I'm a pauper. I live in Poland in a cursh between western Germany (US, UK, France, EU influence) and eastern Russia. I'm a software developer just like @EK (and many other users that commented and was trying to develop Elastic) but in different technologies. I believe in Elastic idea. That's all.

[chris_nor]

Clicking on random pages I see that you post a lot in this thread, so it's pretty amazing that you've only invested less than .5BTC. I hope it's because you already have to much money.

I'm a pauper. I live in Poland in a cursh between western Germany (US, UK, France, EU influence) and eastern Russia. I'm a software developer just like @EK (and many other users that commented and was trying to develop Elastic) but in different technologies. I believe in Elastic idea. That's all.

They should give you extra coins then, for promoting and being active.

[akhavr]

@akhavr,ttook: The problem with rating schemes is imho that you can create an infinite number of alternative identities, all with a clear background. Reputation may work in centralized systems that require some sort of authentication like e.g. eBay, but if we do not want to penalize new users without any rating, we will have a hard time coming up with a reputation system that really works. I mean I could rip off some workers, collect negative reputation, move the XEL to a fresh account and start over.

What do you think?

I second the idea of @ttook.  Only I can add is the idea of bringing dash-like masternodes and limit the voting power just to them.  The collatelarized funds would held them economically accountable.  Have no idea, though, how difficult it would be to implement this.

Also, this would have a good effect on price: more than half of DASH miner are now in masternodes

[Evil-Knievel]

I might have a solution to the hashing overhead problem ... hashing the entire memory after the program has been executed (which is 256KB) is very bad. Why not instead keeping a "internal 128 bit state" which gets altered (using xor and rotation) with every operation the program performs. After the program executes, we only use the 12 integer input and the 128 state to calculate the pow hash? This would reduce the overhead to a minimum.

[kurniajim]

Activity 139 but hero member
How?

[Evil-Knievel]

Activity 139 but hero member
How?

Must be superpowers ... heros have that sometimes!

[coralreefer]

I might have a solution to the hashing overhead problem ... hashing the entire memory after the program has been executed (which is 256KB) is very bad. Why not instead keeping a "internal 128 bit state" which gets altered (using xor and rotation) with every operation the program performs. After the program executes, we only use the 12 integer input and the 128 state to calculate the pow hash? This would reduce the overhead to a minimum.

I think that could work.  Once implemented, we just need to make sure that it doesn't penalize the work package execution time by any material amount.

Also, I had mentioned previously about adding WCET to the response message.  I don't see the need for miners to calculate this every 15 sec for each package, when it could easily be calculated once when the work package is created and included in the work package.

And finally, yesterday you mentioned the personalized int stream which also does 12 rounds of sha256.  If we can find a simpler way to randomize the inputs using workid, blockid, pk, and multiplicator then I think we will have hit all the main points of overhead for the miner.

[Evil-Knievel]

I might have a solution to the hashing overhead problem ... hashing the entire memory after the program has been executed (which is 256KB) is very bad. Why not instead keeping a "internal 128 bit state" which gets altered (using xor and rotation) with every operation the program performs. After the program executes, we only use the 12 integer input and the 128 state to calculate the pow hash? This would reduce the overhead to a minimum.

I think that could work.  Once implemented, we just need to make sure that it doesn't penalize the work package execution time by any material amount.

Good point about the Int-Stream! Fixed that!

Works perfect ... we are back at over 40000 Evaluations per Second ...
Mostly of the slowdown comes from java itself. C implementations would be a LOT faster!

Per iteration of an ElasticPL program, we need only two hashes:
1x MD5 for personalized input integers
1x SHA256 for the POW hash itself

Both hash less than the 2*block size, so it it blazing fast! No more hashing of 256KB of data from the memory!


We should hard fork the change soon after thought about it for few more minutes.

Explanation: Every operation Mangles the result of that operation into a 128 bit long "garbage state" which is used for POW.
Nice side effect: Overhead increases with program complexity, and is no longer constant.

Example for the addition:

Code:

public void interpret()
  {
     jjtGetChild(0).interpret();
     jjtGetChild(1).interpret();

     top=top-1;

     Integer int1 = 0;
     Integer int2 = 0;
     int1 = ((Integer)stack[top]);
     int2 = ((Integer)stack[top+1]);
     Integer result = int1+int2;
     stack[top] = result;

     mangle_state(result);


  }
  public static Long internal_state = 0L;
  public static Long internal_state2 = 0L;

  public static void mangle_state(int x){
    if(x%2==0){
      internal_state = Long.rotateLeft(internal_state,x%64);
      internal_state = internal_state ^ x;
    }else{
      internal_state2 = Long.rotateRight(internal_state2,x%64);
      internal_state2 = internal_state2 ^ x;
    }
  }

[coralreefer]

That's great news.  Please update the development branch of the miner with these changes and I'll try them out.

[Evil-Knievel]

That's great news.  Please update the development branch of the miner with these changes and I'll try them out.

elastic-core and elastic-miner were updated in the development tree!

I used this program to test:

Code:

m[18]=-(1>2);
m[19]=-2424;
m[19]=2424;
m[20]=1-2424;
m[21]=--2424;
m[21]=-3;

verify (m[1] and 255)<35000;

Code:

Mining, Speed: 62k  evaluations / s ... submitted 9 POW solutions / 0 Bounties / 10 Bounties Pending (waiting approval)
Mining, Speed: 68k  evaluations / s ... submitted 3 POW solutions / 0 Bounties / 10 Bounties Pending (waiting approval)

Bounty verification will fail in this version!


EDIT: Fixed 2:38 pm

[Evil-Knievel]

Bump .. totally screwed up! Should be now correctly merged   sorry

[Evil-Knievel]

Please hang on a second ... have to fix a little thing!

[Evil-Knievel]

coralreefer, just use the master branch! I screwed up merging!
Found another bug in the core client which I will fix now!

[coralreefer]

will do.  it will be a little while until I get to this, but I'm encouraged by the results you are seeing.  I'll incorporate the changes later today.

[tomkat]

Also, I just throw out the "last resort" option.  If we really can't solve for keeping miners around when there are few to no work packages, maybe we should just go the other extreme and get rid of POW.  Miners get paid the same when no package is available...nothing.  When I comment POW out of my code, the ElasticPL parser runs great.  It just seems that there is a need for a lot of overhead on the POW piece to ensure mining is fair.  Honestly, if I was mining a package at this point I would just turn off the POW myself even if we decide to keep it.

I guess I've come around to your original comments that the bounty reward is what will really draw miners.

You've got a point regarding the "keeping miners on Elastic" issue. As I wrote before, I think the solution is based on the amount of work we expect on the Elastic network.
A possible solution that was mentioned before was essentially turning the Elastic network into a mining pool for cryptocurrencies other than XEL. So when no jobs are to be solved, the miners mine other coins instead, until a job is submitted. I suspect this only works for smaller voids, though.

But then you're getting into next issues like deciding on what crypto should be mined (which one is the most profitable at the moment).

POW mining XEL (with relatively small POW reward for less inflation) would be good to keep miners around, and also to have enough computing power when work packages come in.
POS would not work since POS miners are usually less efficient machines with little to none computing power.

[coralreefer]

EK, can you check the following function, I don't think it's doing what you intended:

       for(int i=0;i<12;++i){
          int got = toInt(digest,i*4 % ln) ;
          if(i>4){
             got = got ^ stream[i-3];
          }
          stream = got;
       }

When I dump the stream, I'm not seeing any randomization.  To me, it looks like its just pushing the first 4 bytes of the digest to stream ids 0,1,2,3,4, 8,9,10 and zeros to the others.

Also, when you get a few minutes, please post the updated ElasticPL to github.

[Evil-Knievel]

EK, can you check the following function, I don't think it's doing what you intended:

       for(int i=0;i<12;++i){
          int got = toInt(digest,i*4 % ln) ;
          if(i>4){
             got = got ^ stream[i-3];
          }
          stream = got;
       }

When I dump the stream, I'm not seeing any randomization.  To me, it looks like its just pushing the first 4 bytes of the digest to stream ids 0,1,2,3,4, 8,9,10 and zeros to the others.

Also, when you get a few minutes, please post the updated ElasticPL to github.

ElasticPL pushed! Let me please check the bug ;-)

[corvins]

In which exchange can I buy XEL?

[Evil-Knievel]

When I dump the stream, I'm not seeing any randomization.  To me, it looks like its just pushing the first 4 bytes of the digest to stream ids 0,1,2,3,4, 8,9,10 and zeros to the others.

I suspect the problem was this?
https://github.com/OrdinaryDude/elastic-miner/commit/885d2f75f34e17641261fbbf0d6527c6b4a9e3f5