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

[Alohaboy?!]

where can I buy ?

it´s not released yet.

[radley]

lets see how is it going to be.

[Evil-Knievel]

EK, I have posted my miner here:  https://github.com/sprocket-fpga/xel_miner

Please keep in mind that this miner is in the earliest stages of development and still has lots of issues.

Edit:  The AST is stored in the array vm_ast.  I'm assuming this is what you'd need to traverse for the C code interpreter.

Wow, this is an amazing piece of artwork  
What I noticed ...

1. The minus operator in your case is not an own "operator" but belongs to a "number". So as you already pointed out you cannot do "m[2]=--2345;" but neither can you do "m[2]=-(1);".
I think the minus needs to be an own "unary operator".

2. The software is cool!

3. The div operator in the ElasticPL language does not work on floats ;-) So using the c++ "/" operator is perfect in my eyes. If anyone needs "floating number" he must implement them using div and mod himself  

4. Few things differ, you for example do

Code:

if (rval != 0)
    push(lval % rval, false);
else {
    applog(LOG_ERR, "ERROR: VM Runtime - Modulus Operand Equal To Zero");
    return false;

In our case, we do not "crash" ever ... instead ... for both div and mod ... if a zero is the second operator we define the result to be simply 0.

5. You have the boolean datatype

Code:

push(lval != rval, false);

In the java implementation's case, we just push 1 for true, and 0 for false. Not sure about the impact, but multiplying a boolean by a number could crash in your case ... this should be avoided.
That means, these equivalencies should hold:

Code:

3*(1>0) == 3*(true) == 3*1 == 3

6. I still can't believe how cool your miner is!!!

[coralreefer]

Thanks for the feedback EK.  When I get some time this weekend I'll incorporate those changes.

[Evil-Knievel]

Thanks for the feedback EK.  When I get some time this weekend I'll incorporate those changes.

Good work, I am sure you will be rewarded!!
I will link some tiny C compiler to your program and try to get the "on the fly compilation" working ;-)
Also I found that my C engine totally leaves our mangle_state ... yet another todo!

[ttookk]

I can't really comment on the difficulty retargeting issue, since I don't understand how it works and why we need "regular" poW in the first place, but I guess you guys know why.

Here is what seems to be the scenario(spelled out for idiots like me):

- Jobs are submitted to the Elastic network, miners start working on them. Lots of mining power on the network.
- The jobs are done, no new jobs are submitted. Miners start to lose interest, because there are no bounties, so all they get are some measly transaction fees. They point their miners towards another currency, since there, they can actually make some dough.
- This lets us with two possible solutions:

     -- We find ways to keep the miners on the chain
     -- We somehow manage to create an "on demand" system,
         where miners can turn away from the chain and are
         alerted when jobs are being subbmitted.


Regarding the first solution:
This is probably the most idiotic idea I had yet (regarding Elastic, I mean. I have a lot of idiotic ideas ), but I'll write it anyway:

- You could create a "negative interest" system. Wallets that are offline, lose parts of their XEL over time.
- The XEL lost this way is paid out to miners, keeping them on the chain.

Regarding the second solution:
If we would use the reputation system, I was writing about (not saying that we should, or that we shouldn't, just putting it out there!), at least some miners are known entities. If there is a way for them to create a benchmark of their hashing power, you could set up a system that would look like this:

- You have a bunch of registered miners whose hashing power is known, or at least the ballpark.
- When there are no jobs on the chain, the PoW part goes into "hibernation" but remembers the hashingpower of the registerd miners. These miners can turn their power towards something else.
- When a job is submitted, an alert is sent out. The miners have a certain timeframe to respond, saying that they are willing to work on the submitted jobs. This way, the estimated hashing power and difficulty gets recalculated, based on the submitted benchmarks.
- A possible way to get those benchmarks could be to observe the miners when they mine other currencies, possibly by observing other blockchains. They could sign found blocks on other blockchains in a way, that Elastic recognises them as miners that are willing to potentially mine XEL, so that Elastic could estimate its hashing power based on difficulty and number of found signed blocks. Sadly, this wouldn't work with mining pools, where only a portion of the pool would want to mine XEL. Hmmm…
This idea obviously has some flaws, i.e. what happens when the power of a miner changes dramatically.

Any comments?

By the way, what happens if, let's say 10 jobs are submitted at the same time? Are they all being worked on at the same time, do miners decide which jobs they work on, or is there a qeue, with one job after another?

[ttookk]

(…)

Might be the solution to all evil!!!

(…)

Does that mean you are just Knievel now?

[Evil-Knievel]

Regarding the first solution:
This is probably the most idiotic idea I had yet (regarding Elastic, I mean. I have a lot of idiotic ideas ), but I'll write it anyway:

- You could create a "negative interest" system. Wallets that are offline, lose parts of their XEL over time.
- The XEL lost this way is paid out to miners, keeping them on the chain.

Regarding the second solution:
If we would use the reputation system, I was writing about (not saying that we should, just putting it out there!), at least some miners are known entities. If there is a way for them to create a benchmark of their hashing power, you could set up a system that would look like this:

- You have a bunch of registered miners whose hashingpower is known, or at least the ballpark.
- When there are no jobs on the chain, the PoW part goes into "hibernation" but remembers the hashingpower of the registerd miners. Thise miners can turn their power towards something else.
- When a job is submitted, an alert is sent out. The miners have a certain timeframe to respond, saying that they are willing to work on the submitted jobs. This way, the estimated hashing power and difficulty gets recalculated, based on the submitted benchmarks.
- A possible way to get those benchmarks could be to observe the miners when they mine other currencies, possibly by observing other blockchains. They could sign found blocks on other blockchains in a way, that Elastic recognises them as miners that are willing to potentially mine XEL, so that Elastic could estimate its hashing power based on difficulty and number of found signed blocks. Sadly, this wouldn't work with mining pools, where only a portion of the pool would want to mine XEL. Hmmm…
This idea obviously has some flaws, i.e. what happens when the number of a miner suddenly changes dramatically.

Any comments?

By the way, what happens if, let's say 10 jobs are submitted at the same time? Are they all being worked on at the same time, do miners decide which jobs they work on, or is there a qeue, with one job after another?

Let me think a moment about the second solution ... i'll grab a coffee and brainstorm!
Regarding the negative interest ... I am not so sure, but personally - from the user point of view - i would dare to touch anything with a negative interest  I think that the majority would abandon the "sinking ship".

Everyone works on any job he wants. Work is accepted for any work that is open (that is, not closed or not pending closure as may happen when still waiting for bounty revealings).

[ttookk]

(…)

Let me think a moment about the second solution ... i'll grab a coffee and brainstorm!
Regarding the negative interest ... I am not so sure, but personally - from the user point of view - i would dare to touch anything with a negative interest   I think that the majority would abandon the "sinking ship".

(…)

Yeah, I think so as well. It was just a thought I had and felt like putting it out there. It wasn't really meant for serious consideration. But I feel like this is kind of the problem with crypto: in a perfect world, XEL would be used not as a speculative object, but as a ticket. You buy it to use it right away. If the Elastic network would be running smoothly, with lots of new jobs incoming, it would probably benefit the price stability, because there wouldn't be as much speculation.

In fact, the only time the first "solution" would actually work would be when it is not needed: when there is enough interest in buying XEL to use it. Just forget it.

[TraderBill]

world's longest ico

[HmmMAA]

world's longest ico

What's the most important for you , time or value ? Personally , i don't mind if i have to wait for months .

[ttookk]

(…)

Regarding the second solution:
If we would use the reputation system, I was writing about (not saying that we should, or that we shouldn't, just putting it out there!), at least some miners are known entities. If there is a way for them to create a benchmark of their hashing power, you could set up a system that would look like this:

- You have a bunch of registered miners whose hashing power is known, or at least the ballpark.
- When there are no jobs on the chain, the PoW part goes into "hibernation" but remembers the hashingpower of the registerd miners. These miners can turn their power towards something else.
- When a job is submitted, an alert is sent out. The miners have a certain timeframe to respond, saying that they are willing to work on the submitted jobs. This way, the estimated hashing power and difficulty gets recalculated, based on the submitted benchmarks.
- A possible way to get those benchmarks could be to observe the miners when they mine other currencies, possibly by observing other blockchains. They could sign found blocks on other blockchains in a way, that Elastic recognises them as miners that are willing to potentially mine XEL, so that Elastic could estimate its hashing power based on difficulty and number of found signed blocks. Sadly, this wouldn't work with mining pools, where only a portion of the pool would want to mine XEL. Hmmm…
This idea obviously has some flaws, i.e. what happens when the power of a miner changes dramatically.

(…)

Flaws/questions I found so far:

- What happens if some miners don't respond, but start mining anyway? That way, the calculations would be off.
- What happens if a miner responds, but then doesn't mine?
- What happens if a miner faked a lower or higher hashing power (higher by e.g. renting rigs)?

In conclusion, the way I see it, this system is easily broken, unless you have a way to punish malicious behaviour.

To make matters worse, some of this may happen without malicious intent, e.g. by stocking up on rigs, by power outages and so on.

The best you can do with this system is hoping that an overwhelming majority of miners have no bad intent, so that a few bad miners won't ruin the calculations.

I feel like I'm missing something, though. I don't know what, but I have the feeling, the idea is not half bad…

[ImI]

world's longest ico

What's the most important for you , time or value ? Personally , i don't mind if i have to wait for months .

lookup his history. he is just building another fake-account and going into every thread and writes some bullshit. thats all.

[ttookk]

world's longest ico

What's the most important for you , time or value ? Personally , i don't mind if i have to wait for months .

lookup his history. he is just building another fake-account and going into every thread and writes some bullshit. thats all.

Guys, don't bother. I'd rather have you comment on the issues at hand. Throw some of your Brain-Watts Elastics way

[ImI]

world's longest ico

What's the most important for you , time or value ? Personally , i don't mind if i have to wait for months .

lookup his history. he is just building another fake-account and going into every thread and writes some bullshit. thats all.

Guys, don't bother. I'd rather have you comment on the issues at hand. Throw some of your Brain-Watts Elastics way

i would love to, but to give any meaningful advice i would have to invest much more then just a couple of minutes as i would have to catch-up from like 2 months ago. and as i am no coder i could only help in more general decisions or economical questions.

but as soon as i have less real-life-necessities i am willing to join in more often. maybe to add some stuff to the wiki also.

[ttookk]

world's longest ico

What's the most important for you , time or value ? Personally , i don't mind if i have to wait for months .

lookup his history. he is just building another fake-account and going into every thread and writes some bullshit. thats all.

Guys, don't bother. I'd rather have you comment on the issues at hand. Throw some of your Brain-Watts Elastics way

i would love to, but to give any meaningful advice i would have to invest much more then just a couple of minutes as i would have to catch-up from like 2 months ago. and as i am no coder i could only help in more general decisions or economical questions.

but as soon as i have less real-life-necessities i am willing to join in more often. maybe to add some stuff to the wiki also.

I'm no coder either. I don't know how useful I actually am and I probably enjoy writing out every brainfart I have way too much (the proof is hidden in the last few posts I wrote), but still: There are some decisions that need to be made by a wider range of people.

[Limx Dev]

I have created a little Forum for Elastic (Childboard)



http://bitsend.info/forums/index.php#c8

or

http://bitsend.info/forums/index.php?board=21.0

Best Regards Christian

P.S. I can add a mod from here.

[ttookk]

Just in case Lannister does a bounty hunting ;-)

Here my first submission on an idea, it is really bad and up for discussion:

1. Every work has its own target value
2. Once a work is created, the target value gets initialized with the average final target value of the last 10 closed jobs.
3. As long as no PoW submission is made, the target value or rather the difficulty drops very quickly so that in at most 5 blocks it reaches the "least possible difficulty" (to help readjusting to changed miner population)
4. There can be only 20 unconfirmed PoW submissions in the memory pool (and in each block) at most per work.
5. The retargetting mechanism reacts quickly, per block, to adapt to a targetvalue that results in on average 10 PoW submissions per block

(…)

Thinking about it, I believe this is a better approach than mine. Maybe something like this could be an addition in case of a very long void:

(…)
- A possible way to get those benchmarks could be to observe the miners when they mine other currencies, possibly by observing other blockchains. They could sign found blocks on other blockchains in a way, that Elastic recognises them as miners that are willing to potentially mine XEL, so that Elastic could estimate its hashing power
(…)

Some general thoughts regarding the project:

At the moment, I think we have two main opinions about what the Elasic project is supposed to be:
Evil-Knievels has more of an "everything goes, no exclusion of miners" position (if I may be so bold), while mine is a little more careful and community-driven, with the reputation system and all. I'm not saying one position is better than the other, but this looks like a very basic question that needs an answer to move forward: Do we either want a reputation system or the possibility of implementing one, or do we want to keep the network open for all miners? At the moment, I think Evil-Knievels word holds the most weight here, I'd go his way and abandon my pursues of finding a working reputation system.

[Evil-Knievel]

At the moment, I think Evil-Knievels word holds the most weight here, I'd go his way and abandon my pursues of finding a working reputation system.

No, this should be not the case! I am just working shifts here, I am no authority! I do what the majority wants to ... so let's discuss all ideas that come up! I am still thinking about your "second approach" though ;-) I will comment soon!

[ImI]

I am with EK here as i have followed some of the discussions Golem is having in finding a valid and not manipulable reputational system. They seem to have put lots of thought into it, including using lots of scientific articles in that certain field, and havent come up with a solution so far. That leads me to believe if we can avoid it we should try to, imho.

If the community is really undecided in which way to go we can always use EK's nice voting system and vote about a certain issue. Of course not after having a good discussion before..