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

[wwdz99]

For everyone who wants to hack with Elastic PL programming language but is scared of consoles!!!

Just get the Elastic PL Development IDE which allows you to develop and test your elastic PL programs comfortably in an IDE.
It is quite basic, the syntax highlighting still sucks, but its functional.
Feel free to adjust it and submit a git pull request if you like ;-)


Step 1

Download the Executable
https://github.com/OrdinaryDude/ElasticPL-Editor/raw/master/ElasticEditor.jar

-or-

Clone the entire source tree:
git clone https://github.com/OrdinaryDude/ElasticPL-Editor

Step 2

Launch the editor using:

Code:

java -jar ElasticEditor.jar

Step 3

Try if you can make Elastic PL crash  

Great job! EK

[1714255280]

1714255280

[1714255280]

1714255280

[1714255280]

1714255280

[1714255280]

1714255280

[HunterMinerCrafter]

For everyone who wants to hack with Elastic PL programming language but is scared of consoles!!!

Looks nice, but what would be really helpful right about now would be a single-step debugger that can inspect stack/memory state mid-execution.    I'm trying to chase down some difference in semantics between a C model of a program and its epl implementation, and it is currently proving quite difficult to do.

(Another feature that I thought of for the "standalone" interpreter mode that might be nice to see: the ability to churn a lot of inputs and count "bounty rate" - an approximate percentage of executions which result in bounties.  This could help people with deciding appropriate bounty values in the long run.)

[HunterMinerCrafter]

P.S.

Mod by 0 still produces an exception...

[ttookk]

(…)

(…)

It seems like this could leave a lot of miners unhappy when their deposits aren't returned because of "natural" cause.  (Like a sudden run of "by chance" rapidly forged blocks which do not include their reveal tx, but runs out their "x blocks" counter.)

This sounds like a valid concern, but it seems to me, that this is more a problem of balance, i.e. what "x Blocks" means exactly. You could probably make "X" dynamic, maybe by adjusting it every "Y" blocks, but that might open a whole new can of worms…

The more I think about it, the less I am sure miners need to be reimbursed in the first place, but maybe I am missing something. Here is the scenario as i understand it and you tell me where I got it wrong:

- A miner finds a solution for a job/a block (do we have a terminology for this already?)
- They send the hash out, paying the tax for it.
- After a time that is long enough for the network to recognise their hash, they send the block
- They are rewarded for finding the block with the bounty

Since there already is a reward (i.e. the bounty), the miner already gets reimbursed in a way. The tax they paid could go out to a lucky PoS staker instead of returning it.

Now, I have a question about taxed hashes, though: Couldn't I DoS the system by creating doublespends/multiplespends? I mean, if the timeframe in which the taxed hash gets sent out before the block is shorter than at least one block, I could just send out a whole lot of bogus hashes with the same XEL as payment over and over again, couldn't I?

[wpalczynski]

Im not sure how much nodes are needed at this point.  I have a VPS I could deploy a node to if there was an automated script which could do it on unix.  Probably other non technical people would be able to do the same if it was easy as that.

[Evil-Knievel]

- A miner finds a solution for a job/a block (do we have a terminology for this already?)
- They send the hash out, paying the tax for it.
- After a time that is long enough for the network to recognise their hash, they send the block
- They are rewarded for finding the block with the bounty

Since there already is a reward (i.e. the bounty), the miner already gets reimbursed in a way. The tax they paid could go out to a lucky PoS staker instead of returning it.

Now, I have a question about taxed hashes, though: Couldn't I DoS the system by creating doublespends/multiplespends? I mean, if the timeframe in which the taxed hash gets sent out before the block is shorter than at least one block, I could just send out a whole lot of bogus hashes with the same XEL as payment over and over again, couldn't I?

Hi ttookk,

regarding the first part:
- I am not sure how to call them correctly, for now we all have called them "bounty submission" which essentially are "solutions for a job". I think it's wrong to call them "blocks" as such solutions are just regular transactions and do not extend the blockchain by themselves.
- What you described would mean that the users have an unlimited number of time to reveal their hash. So yes, we could argue that we do not need a fixed deadline to reveal the hashes as miners (who have a paid tax on stake) will always have the interest to reveal their solution sooner or later.
- But what happens when they don't? A powerful attacker with lots of XEL could DOS work jobs. With a fixed deadline job creators would get reimbursed for the DOS attack by getting the tax. Without a deadline, they are just stuck with an "infinitely pending job".


regarding the second part:
- good point to think about who gets the tax ... does the user get it back, will it be used as fee, ... we could brainstorm about this a bit, sure!
- No, you couldn't send the same XEL over and over again, your "unconfirmed Balance" would drop to 0 eventually, preventing you from spending any XEL that you don't have.

[ttookk]

(…)

- What you described would mean that the users have an unlimited number of time to reveal their hash. So yes, we could argue that we do not need a fixed deadline to reveal the hashes as miners (who have a paid tax on stake) will always have the interest to reveal their solution sooner or later.
- But what happens when they don't? A powerful attacker with lots of XEL could DOS work jobs. With a fixed deadline job creators would get reimbursed for the DOS attack by getting the tax. Without a deadline, they are just stuck with an "infinitely pending job".

regarding the second part:
- good point to think about who gets the tax ... does the user get it back, will it be used as fee, ... we could brainstorm about this a bit, sure!

 (The mentioned scenarios are obviously talking about the case in which there either is a single solution for the job or two or more miners find the same solution*)

- You would need some kind of deadline to reveal the solution, because otherwise, you could just stall the job. I mean, what's the point of taxed hashes if the one revealing the solution first gets the bounty? The scenario could look like this:
- I, as the malicious miner, send a hash for a job, but don't reveal it.
- Other miners see that a hash is submitted and must fear that solutions they find are invalid, thus…
- …they stop working on that job.
- Now, I can work on that job alone, until I find the real solution, or f*ck with the submitter for whatever reason.
Thus, you'd need some kind of deadline anyway.

Brainstorming:
- If you have a system in place, where the first person to send the right hash in would be the one who gets the bounty, but the network is stalled, others may have kept working on a job that already had a solution, thus wasted their time.

- In that case, one of the miners not only lost time and energy, but also the invested XEL, when we have a system where they do not get reimbursed.

- What if the tax gets added to the bounty of the job, the hash is meant for? This would a) effectively reimburse the miner and b) prevent the XEL to get on the free market again, until the job is finished, thus, an attacker couldn't buy the same XEL over and over again.

- Additionally, this could render any late submissions invalid, returning the XEL to the sender (thus, no XEL is lost for latecomers).

- But what happens to the XEL if the job remains unfinished? Although in that scenario, there shouldn't be sent in hashes in the first place, should there? So it is relatively safe to assume, that taxed hashes that get sent in to "solve" jobs without solution are mistakes at best and malicious at worst. In that case, the XEL should not go back to the miner, but get paid out to the network supporters. However, this would open the possibility for an attack by creating bogus jobs, send in hashes, then cancel the job, the XEL gets liquid again, and so on** (or is that too much of a corner case?). In this case, it may be prudent to implement some kind of deadline for releasing the submitted XEL, but this deadline could be ridiculously long, like six months or something, to prevent a wealthy attacker from buying the same XEL over and over again, but still preventing the XEL from getting burned.

- No, you couldn't send the same XEL over and over again, your "unconfirmed Balance" would drop to 0 eventually, preventing you from spending any XEL that you don't have.

Well, how do doublespends occur then in the first place? Which instance of the system checks for your balance, if not the miners/stakers? The first one is obviously your wallet, but that can be tampered with. I realize that there has to be some kind of easy solution which I am not aware of, since you could DoS pretty much any blockchain with this, if it was easily possible.


*This seems to be a general problem, though. I guess, this was discussed already?
** Do you think this is a valid attack scenario; that an attacker swarms the network with small jobs, solving them themself(since they know the job "from the inside", they'd have an advantage at solving it) to get the XEL back, effectively DoSing the network?

[Evil-Knievel]

ttookk, i will reply to your post shortly. I just had an inspiring moment in the supermarket which I want to share before I forget about it again.

A workflow might look like this:
- Job is being opened
- People submit bounties (TX_BOUNTY), from that time they have a fixed time (let's say 15 minutes, but not earlier than in the next block) based on the bock timestamps to reveal their bounty solutions (TX_BOUNTY_REVEAL).
- The job is then closed after either it times out, it runs out of PoW funds or receives exactly as many TX_BOUNTY_REVEAL transactions as specified through the adjustable "maximum number of bounties wanted" parameter.
- If the job is closed before enough TX_BOUNTY_REVEAL transactions have been received (i.e., due to a timeout) but it has some unveiled TX_BOUNTY submissions, then the protocol waits for another 15 minutes before starting to distribute the bounty pool to catch any remaining "just in time" TX_BOUNTY_REVEAL yet to come.
- Otherwise just distribute the bounty pool among all TX_BOUNTY_REVEAL submissions.
- TX_BOUNTY transactions are taxed, the deposit goes to someone else (block miners or job author) if he TX_BOUNTY_REVEAL is not received on time.

Explanation:
- This way submitting too many TX_BOUNTY will not stall/DOS the job as the job's cancellation is solely based on the number of TX_BOUNTY_REVEAL received.
- The job author cannot "race". It is pointless for him to "eavesdrop" the channel for bounties and then simultaneously push his own 100 bounty submissions in order to hope to be included in the next block first and so cash back the bounty fund to himself. This is impossible, because in order to get the content of his solution he needs to wait for the TX_BOUNTY_REVEAL which can happen not earlier than the next block of the related TX_BOUNTY. Means: No matter what he does, the original senders TX_BOUNTY is already in the blockchain and cannot be outraced anymore. This is because to "outrace" he would himself first have to push his own TX_BOUNTYs and a block later his TX_BOUNTY_REVEALs. But then, the original TX_BOUNTY_REVEAL is in the blockchain already.
- It may happen that too many TX_BOUNTY submissions are being sent because the job is still running due to most of them not yet being revealed, which eventually would not be accounted for in the bounty fund distribution ... not sure about this one, also in terms of network DOS! Maybe we could make a hard cap of X unconfirmed bounties in the TX pool to prevent DOS attacks by "easy bounty flooding". Maybe it could be possible to go with a rule like this: Not reveiling the TX_BOUNTY_REVEAL = tax deposit forfeited. Sending too many bounties which are correct when unveiled: Tax deposit gets charged back in 1440 blocks as a small penalty.

Problems:
He could still use FAA (Faster Algorithm Attack) to quickly generate multiple different, valid bounties to get a majority of the bounty fund. This could be mitigated by not distributing the bounty fund "proportionally" but to assign each valid bounty submission one fixed absolute XEL value.


If all these changes are added, it (at least now) looks to me that we have a solid mechanism for the bounty payouts which can only be tampered with at the cost of the tax deposit
(leaving aside the yet-to-be-solved DDOS opportunity)

[ttookk]

Looks like your post answered most of my questions in the post above anyway

Short question: Is there a possibility, that for some jobs, the miner can't conclusively validate on their own that their solution is correct? I.e. if I think, I've found a solution, send in TX_BOUNTY, is there a chance that at TX_BOUNTY_REVEAL, the solution proves to be invalid, not because I made a mistake, but because I couldn't prove its validity with the data at hand?

And if it does, does a miner gets reimbursed, even if the TX_BOUNTY_REVEAL turns out to be wrong? No, right? Otherwise, DoS attacks by wealthy miners are possible…

I think unrevealed TX_BOUNTIES should go into the bounty pool and get paid out to valid TX_BOUNTY_REVEALS. Although that creates the question what is going to happen with TX_BOUNTIES in job orders that get closed. Paying them out to the job author sounds like you could somehow create jobs, that are not meant to be solved, just to collect TX_BOUNTIES of miners who think they found a solution…

[Evil-Knievel]

Looks like your post answered most of my questions in the post above anyway

Short question: Is there a possibility, that for some jobs, the miner can't conclusively validate on their own that their solution is correct? I.e. if I think, I've found a solution, send in TX_BOUNTY, is there a chance that at TX_BOUNTY_REVEAL, the solution proves to be invalid, not because I made a mistake, but because I couldn't prove its validity with the data at hand?

I don't think so:
- the program code is present (or if its pruned already, it is so old that no deep verification is needed anymore)
- the input numbers to the program are deterministic and are always reconstructed in the same way
- the program does not change, so if the miner found "input numbers" that once validated to true in the "bounty check statement", then all other "validators" will see the same true result.

So miners can be 100% confident that the result they find (except some odd bug in a custom miner implementation which we haven't yet) is correct.

[ttookk]

Ok, that's good, that closes a lot of attack vectors (e.g. creating fake jobs to collect TX_BOUNTIES).

[Evil-Knievel]

Ok, that's good, that closes a lot of attack vectors (e.g. creating fake jobs to collect TX_BOUNTIES).

Or rather their tax deposits, right? Well, yes that would be not possible here.
What do you think about this scheme ... for now these were just random thoughts that popped into my head this morning.  

[ttookk]

Ok, that's good, that closes a lot of attack vectors (e.g. creating fake jobs to collect TX_BOUNTIES).

Or rather their tax deposits, right? Well, yes that would be not possible here.
What do you think about this scheme ... for now these were just random thoughts that popped into my head this morning.  

Well, I like it, but I have close to zero technical understanding, therefore what I like or not isn't exactly important
Yeah, I meant the deposits.
I'm not sure, where unclaimed deposits should go to, though…

Initially, I liked the idea to put them in the bounty pool, but that would not penalize every form of malicious activity. A miner could make lots of deposits, if they can be sure that they get them back, once they find (or already have) a valid solution… Although I don't see why a miner would do this instead of sending in the right solution and just claim the bounty.

[tomkat]

(…)

(…)

It seems like this could leave a lot of miners unhappy when their deposits aren't returned because of "natural" cause.  (Like a sudden run of "by chance" rapidly forged blocks which do not include their reveal tx, but runs out their "x blocks" counter.)

This sounds like a valid concern, but it seems to me, that this is more a problem of balance, i.e. what "x Blocks" means exactly. You could probably make "X" dynamic, maybe by adjusting it every "Y" blocks, but that might open a whole new can of worms…

The more I think about it, the less I am sure miners need to be reimbursed in the first place, but maybe I am missing something. Here is the scenario as i understand it and you tell me where I got it wrong:

- A miner finds a solution for a job/a block (do we have a terminology for this already?)
- They send the hash out, paying the tax for it.
- After a time that is long enough for the network to recognise their hash, they send the block
- They are rewarded for finding the block with the bounty

Since there already is a reward (i.e. the bounty), the miner already gets reimbursed in a way. The tax they paid could go out to a lucky PoS staker instead of returning it.

Now, I have a question about taxed hashes, though: Couldn't I DoS the system by creating doublespends/multiplespends? I mean, if the timeframe in which the taxed hash gets sent out before the block is shorter than at least one block, I could just send out a whole lot of bogus hashes with the same XEL as payment over and over again, couldn't I?

Just a note, that it seems your discussion goes more ad more towards a mining-only solution, but the origin of XEL is/was to make it decentralized supercomputer that is capable of doing various types of computations, ie. distributed rendering (like Golem's current main focus), and potentially scientific applications too.
What I mean is that basically the terminology should be general enough to cover as many as possible potential applications.

[Bgjjj2016]

Ok, that's good, that closes a lot of attack vectors (e.g. creating fake jobs to collect TX_BOUNTIES).

Or rather their tax deposits, right? Well, yes that would be not possible here.
What do you think about this scheme ... for now these were just random thoughts that popped into my head this morning.  

Well, I like it, but I have close to zero technical understanding, therefore what I like or not isn't exactly important
Yeah, I meant the deposits.
I'm not sure, where unclaimed deposits should go to, though…

Initially, I liked the idea to put them in the bounty pool, but that would not penalize every form of malicious activity. A miner could make lots of deposits, if they can be sure that they get them back, once they find (or already have) a valid solution… Although I don't see why a miner would do this instead of sending in the right solution and just claim the bounty.

unclaimed deposits ? Has XEL distributed yet or has anyone claimed their deposits yet ? I'm confused !

[ttookk]

Ok, that's good, that closes a lot of attack vectors (e.g. creating fake jobs to collect TX_BOUNTIES).

Or rather their tax deposits, right? Well, yes that would be not possible here.
What do you think about this scheme ... for now these were just random thoughts that popped into my head this morning.  

Well, I like it, but I have close to zero technical understanding, therefore what I like or not isn't exactly important
Yeah, I meant the deposits.
I'm not sure, where unclaimed deposits should go to, though…

Initially, I liked the idea to put them in the bounty pool, but that would not penalize every form of malicious activity. A miner could make lots of deposits, if they can be sure that they get them back, once they find (or already have) a valid solution… Although I don't see why a miner would do this instead of sending in the right solution and just claim the bounty.

unclaimed deposits ? Has XEL distributed yet or has anyone claimed their deposits yet ? I'm confused !

No, mainnet hasn't started.
I guess you have to read a few posts back to know what I mean, but I admit that the way I wrote it is a little misleading
By deposit I mean XEL that is paid to send a hash (TX_BOUNTY) before the solution is sent (TX_BOUNTY_REVEAL). This is a means to prevent spamming the network and the question is, where does this deposit go?

(…)

Just a note, that it seems your discussion goes more ad more towards a mining-only solution, but the origin of XEL is/was to make it decentralized supercomputer that is capable of doing various types of computations, ie. distributed rendering (like Golem's current main focus), and potentially scientific applications too.
What I mean is that basically the terminology should be general enough to cover as many as possible potential applications.

If it looks that way, it probably is because at the moment, there are a lot of discussions about very specific cases. Sometimes, you get lost in the details, but the main goal hasn't changed.

[Evil-Knievel]

ttookk, i will reply to your post shortly. I just had an inspiring moment in the supermarket which I want to share before I forget about it again.

A workflow might look like this:
- Job is being opened
- People submit bounties (TX_BOUNTY), from that time they have a fixed time (let's say 15 minutes, but not earlier than in the next block) based on the bock timestamps to reveal their bounty solutions (TX_BOUNTY_REVEAL).
- The job is then closed after either it times out, it runs out of PoW funds or receives exactly as many TX_BOUNTY_REVEAL transactions as specified through the adjustable "maximum number of bounties wanted" parameter.
- If the job is closed before enough TX_BOUNTY_REVEAL transactions have been received (i.e., due to a timeout) but it has some unveiled TX_BOUNTY submissions, then the protocol waits for another 15 minutes before starting to distribute the bounty pool to catch any remaining "just in time" TX_BOUNTY_REVEAL yet to come.
- Otherwise just distribute the bounty pool among all TX_BOUNTY_REVEAL submissions.
- TX_BOUNTY transactions are taxed, the deposit goes to someone else (block miners or job author) if he TX_BOUNTY_REVEAL is not received on time.

Explanation:
- This way submitting too many TX_BOUNTY will not stall/DOS the job as the job's cancellation is solely based on the number of TX_BOUNTY_REVEAL received.
- The job author cannot "race". It is pointless for him to "eavesdrop" the channel for bounties and then simultaneously push his own 100 bounty submissions in order to hope to be included in the next block first and so cash back the bounty fund to himself. This is impossible, because in order to get the content of his solution he needs to wait for the TX_BOUNTY_REVEAL which can happen not earlier than the next block of the related TX_BOUNTY. Means: No matter what he does, the original senders TX_BOUNTY is already in the blockchain and cannot be outraced anymore. This is because to "outrace" he would himself first have to push his own TX_BOUNTYs and a block later his TX_BOUNTY_REVEALs. But then, the original TX_BOUNTY_REVEAL is in the blockchain already.
- It may happen that too many TX_BOUNTY submissions are being sent because the job is still running due to most of them not yet being revealed, which eventually would not be accounted for in the bounty fund distribution ... not sure about this one, also in terms of network DOS! Maybe we could make a hard cap of X unconfirmed bounties in the TX pool to prevent DOS attacks by "easy bounty flooding". Maybe it could be possible to go with a rule like this: Not reveiling the TX_BOUNTY_REVEAL = tax deposit forfeited. Sending too many bounties which are correct when unveiled: Tax deposit gets charged back in 1440 blocks as a small penalty.

Problems:
He could still use FAA (Faster Algorithm Attack) to quickly generate multiple different, valid bounties to get a majority of the bounty fund. This could be mitigated by not distributing the bounty fund "proportionally" but to assign each valid bounty submission one fixed absolute XEL value.


If all these changes are added, it (at least now) looks to me that we have a solid mechanism for the bounty payouts which can only be tampered with at the cost of the tax deposit
(leaving aside the yet-to-be-solved DDOS opportunity)

I have implemented this in the development branch:

Related Commits (in chronological order):
https://github.com/OrdinaryDude/elastic-core/commit/75de86fcea9cfc07be7b0a42f364ab715a182c1c
https://github.com/OrdinaryDude/elastic-core/commit/a14d0c2a35fd175f98a4d7ea77bf9dac59b9029b
https://github.com/OrdinaryDude/elastic-core/commit/8d403de20b0eb6e5db9457ff8d5ba792a608353b
https://github.com/OrdinaryDude/elastic-core/commit/33e879606f48cae3cfcc9dd38077c4ca25952b37

I will test this myself for a bit and update the UI and miner, and then we can put the whole thing up for discussion/inspection/further review.

[cyberhacker]

glad to see all the progress.

sorry to ask what is expected stable mainnet launch?

I am patient for this great project. but only ask a eta.

thanks.

[Evil-Knievel]

glad to see all the progress.

sorry to ask what is expected stable mainnet launch?

I am patient for this great project. but only ask a eta.

thanks.

I would personally guess 1-2 months, but of course the highest priority is to get all bugs and design issues sorted out 

[cyberhacker]

glad to see all the progress.

sorry to ask what is expected stable mainnet launch?

I am patient for this great project. but only ask a eta.

thanks.

I would personally guess 1-2 months, but of course the highest priority is to get all bugs and design issues sorted out 

thanks man.

can't do any help here. but when we have a grand opening. I will but a nice banner on my site.

xel is my favorite project ever.