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

[ttookk]

(…)

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.

Nice! Where do unrevealed TX_BOUNTY deposits go at the moment?

[1714157269]

1714157269

[1714157269]

1714157269

[ttookk]

This is an idea for a hackathon:

I think, chess is a very interesting way to test the Elastic network. While it is in theory indefinitely deep, you can cap it (i.e. maximum number of turns in advance to be calculated), get a result and then apply the result to your next job.

Once the tesnet is stable and we are close to releasing mainnet, we could hold a chess tournament. The idea is as follows:

- Single persons or teams can enter.

- There is a considerable amount of BTC to win, to get people from outside of the XEL and blockchain bubble to join.

- Every participant gets the same amount of testnet XEL. All movements are recorded, to keep participants from cheating by aquiring additional XEL.

- The tournament is a chess tournament, depending on the number of participants, it's either KO-system (best of 5) from the beginning, or swiss system first, then KO-system in the finals.

- The moves of the figures have to be determined by using the Elastic network alone, maybe except for the first three to five moves. Thus, the real challenge is how to use the XEL you have most effectively, since everybody has access to the same network.

- Obviously, there has to be some kind of time cap per turn.

- To incentivise people to provide their computing power, bounties can be cashed out to BTC.

For the Elastic project, this could be an interesting way to a) get more popular to a bigger crowd and b) get data about performance of the network, like ideal work-to-bounty ratio and other stuff.

If this thing is of interest, it could become a regular thing on the mainnet as well.

[coralreefer]

Hi EK,

Is it possible to place a pre-calcualted WCET value in JSON "getMineableWork" response.  This will greatly simplify how the miner determines which work package is most profitable.  Otherwise, the miner would have to parse the source for each package before knowing which one give the best WCET to POW reward ratio.

Also, regarding workid in the response.  Can the miner assume that for a given workid that the elasticpl source cannot change?  This will also help out the miner only needing to re-parse the source if it changes to a different workid.

[coralreefer]

EK, I also have a question regarding the personalizedIntStream.  My understanding is that m[0]-m[11] are made up of hashes of the workid, multiplier, pubkey, and blockid.  However, I'm a little unclear how to make this work efficiently for a multi-threaded miner as well as this appears to add a lot of over-head to the miner that is taking away from scanning the work for bounties.

Maybe we could tweak it this way:

  - Leave m[0] available for the miner to assign incremental values to...similar to a nonce.  This way each pass, the miner would just have to increment m[0] by whatever value instead of incurring the overhead of rehashing m[0]-m[12] every time.  If the event of multiple cpu cores, it would be up to the miner to ensure m[0] is uniquely set for each core and once all m[0] values have been checked to reset m[0]-m[11]

  - Populate m[1]-m[11] with the personalizedIntStream for each cpu core that will be mining.  I'm guessing the multiplier could be used to make sure each cpu core is working on unique values for m[1]-m[11].

I realize the risk here is that if the elasticPL coder does not use m[0] only limited processing would get done, but that should just be a given that they should use m[0] as a primary input.

My thought here along with my question of adding WCET to the response is that we really want the miner focusing on looking for bounties, and minimizing the amount of overhead outside of running the elasticPL VM.

[ttookk]

Started working on a very basic visualization of elastic project



(just realized the amount of cubes doesn't add up. Oh well )

[hagie]

Hi all,

public testnet node updated to latest git : https://elastic.cryptnodes.site/

feel free to play around.

regards

[hagie]

Still get the error :

"Could not validate unsigned bytes returned by the server."

If I try to set my account info

regards

[provenceday]

Started working on a very basic visualization of elastic project



(just realized the amount of cubes doesn't add up. Oh well )

cool picture!

[Evil-Knievel]

Picture looks amazing!!! This would be ideal of a wiki where both detailed technical explanations as well as basic sketches could be included!
I will push the latest "bounty deposit" changes to the live branch after some more testing.

[Evil-Knievel]

What do you think about these "lower/upper bounds"? (Just a first idea, open for discussion)

• Number of bounties requested must be between 1 and 10
• Minimum POW payout price 0.001 XEL
• Minimum Bounty payout price 1 XEL
• Bounty deposit: exactly 10 XEL
• Deposit grace period: until the work has been closed and then up to 15 minutes later, all hash bounty announcement unveilings done in this time are paid back (even if not counted for the bounties as they exceed the maximum wanted number). Connection failures, power shortages, etc. between the hash announcement and the actual bounty submission will hurt!
• Maximum Code Length: 1 MB (1024 KB)

[ttookk]

I toyed around more with the picture and made a quick mock-up for a website design:

This is the basic setup with nodes(the red blocks) I prefer this look, it doesn't look as outdated as the one before, although the lines are a little confusing at the moment. Not sure how to solve this, yet(edit:possible solution is some posts down):



This is the visualization of a block being found (the shadow of the big block doesn't show, I need to fix this):



These are the mock-ups for the website. Please be aware that I would use a different font, something similar to futura(http://www.myfonts.com/search/futura/). I just don't have it on this computer:

Front page. You could show some statistic on it, like computing power of network, tasks being worked on atm, stuff like that:


I like it minimalistic. This is pretty much on the upper end of design elements, I'd use. Maybe even get rid of the "Elastic Project":


If you are looking for the official logo, well, to be honest, I don't like it. That's just me, I guess, but still, I have a hard time fitting it in the overall design.




But since I have no expertise in actually building a website, someone else would have to do the actual coding…

Btw, before someone mentions it: Yes, I know the designs look similar to the front cover of "blockchain revolution".

Edit: the font should be more like this (although not in the text itself, probably. Doesn't look like the best font for long reads):

[ttookk]

What do you think about these "lower/upper bounds"? (Just a first idea, open for discussion)

• Number of bounties requested must be between 1 and 10
• Minimum POW payout price 0.001 XEL
• Minimum Bounty payout price 1 XEL
• Bounty deposit: exactly 10 XEL
• Deposit grace period: until the work has been closed and then up to 15 minutes later, all hash bounty announcement unveilings done in this time are paid back (even if not counted for the bounties as they exceed the maximum wanted number). Connection failures, power shortages, etc. between the hash announcement and the actual bounty submission will hurt!
• Maximum Code Length: 1 MB (1024 KB)

It's really hard to determine, because I think it would strongly depend on XELs actual worth. I can't really comment on the actual numbers, since I'm not a numbers guy, but I think it would be good if there was some kind of mechanism in place to readjust those numbers, i.e. every half year, token holders vote (the way we did before) and then, based on the outcome, the numbers are adjusted.

You are right about power failures or other reasons of disconnect… This is actually the most serious problem I see at the moment, regarding taxed hashes, since this is a kind of negative lottery. A possible way to mitigate this may be to pay unrevealed hash taxes back, but with a hefty delay (maybe even a quarter of a year, or its equivalent in blocks).

By the way, would you consider rendering a big video file a realistic use case?

[ttookk]

… Sorry, couldn't help it. Worked on the graphics some more (the red cubes still look a bit big, but that's fine tuning):





Obviously, these are very basic visualizations. I'd like to try out some more complex visualizations, but I'm not quite sure where to start.

[provenceday]

I toyed around more with the picture and made a quick mock-up for a website design:

This is the basic setup with nodes(the red blocks) I prefer this look, it doesn't look as outdated as the one before, although the lines are a little confusing at the moment. Not sure how to solve this, yet(edit:possible solution is some posts down):



This is the visualization of a block being found (the shadow of the big block doesn't show, I need to fix this):



These are the mock-ups for the website. Please be aware that I would use a different font, something similar to futura(http://www.myfonts.com/search/futura/). I just don't have it on this computer:

Front page. You could show some statistic on it, like computing power of network, tasks being worked on atm, stuff like that:


I like it minimalistic. This is pretty much on the upper end of design elements, I'd use. Maybe even get rid of the "Elastic Project":


If you are looking for the official logo, well, to be honest, I don't like it. That's just me, I guess, but still, I have a hard time fitting it in the overall design.




But since I have no expertise in actually building a website, someone else would have to do the actual coding…

Btw, before someone mentions it: Yes, I know the designs look similar to the front cover of "blockchain revolution".

Edit: the font should be more like this (although not in the text itself, probably. Doesn't look like the best font for long reads):

that's amazing.

[Evil-Knievel]

I think this whole bounty announcement by hash-only thing with later uncovering the bounty solution still is flawed.

- Attacker sends 20 valid but meaningless bounty announcements (attacker is the work author and has created a trapdoor in the verify routine) but does not yet reveal them
- An honest bounty announcement is posted
- A few minutes later the bounty announcement is uncovered
- At the *very* same time, the attacker unveils his 20 bounties and tries the race to be included in the block before the honest bounty gets included claiming the whole bounty pool for himself

We need a solution for that, some kind of total order!

Or we just allow as many bounty announcement submissions as bounties were requested. This would allow potent attackers to stall/DOS the job at the cost of the bounty deposits, but prevent a race by preparing and submitting "more bounty announcements" than wanted in the hope that only the own bounty revealings end up in the next block after a true bounty has been uncovered.

Also we could "throw away" not claimed bounty announcements opening up the slot again after a fixed period of time in which the bounty announcement has not been uncovered. DOSsing would be then only possible for a limited time only at the cost of the bounty deposit.
... Instead we could just leave it as is and close the job after a sufficient amount of bounty announcements starting the grace period for revealing. So a DOS attack with fake hash announcements stops the POW fund being drained and, in the worst case, earns the author the bounty deposits.

 

[xxxgoodgirls]

Amazing work ttookk!

[jeffthebaker]

What's been going on with Elastic? I threw some BTC in it near the beginning. Website is now down? What gives?

Also, donation warnings were implemented after my payment, that seems to not be a good sign.

[Thefrolly]

What's been going on with Elastic? I threw some BTC in it near the beginning. Website is now down? What gives?

Also, donation warnings were implemented after my payment, that seems to not be a good sign.

devs are very activ working on it, just read some of the last pages and you will see that there is alot going on

[Evil-Knievel]

For those of you who work on the wiki:

Here are all possible "work states" with explanations:

[ttookk]

Amazing work ttookk!

Thanks, I appreciate it

I think this whole bounty announcement by hash-only thing with later uncovering the bounty solution still is flawed.

- Attacker sends 20 valid but meaningless bounty announcements (attacker is the work author and has created a trapdoor in the verify routine) but does not yet reveal them
- An honest bounty announcement is posted
- A few minutes later the bounty announcement is uncovered
- At the *very* same time, the attacker unveils his 20 bounties and tries the race to be included in the block before the honest bounty gets included claiming the whole bounty pool for himself

We need a solution for that, some kind of total order!

Or we just allow as many bounty announcement submissions as bounties were requested. This would allow potent attackers to stall/DOS the job at the cost of the bounty deposits, but prevent a race by preparing and submitting "more bounty announcements" than wanted in the hope that only the own bounty revealings end up in the next block after a true bounty has been uncovered.

Also we could "throw away" not claimed bounty announcements opening up the slot again after a fixed period of time in which the bounty announcement has not been uncovered. DOSsing would be then only possible for a limited time only at the cost of the bounty deposit.
... Instead we could just leave it as is and close the job after a sufficient amount of bounty announcements starting the grace period for revealing. So a DOS attack with fake hash announcements stops the POW fund being drained and, in the worst case, earns the author the bounty deposits.

 

Yeah, this really is a pain in the butt… Here are some of my thoughts on that matter:

I think there is a whole slew of possible attacks that we know and that we don't know of, which all either abuse or circumvent the bounty deposit system.

I think I stated it before, but I don't like the idea of the bounty deposit going to either of the involved parties. Here is a possible scenario:

- A job has a maximum amount of pending bounties allowed. If this is reached, no new bounty requests are allowed and no new bounty deposits happen. Once a reveal happens, a slot opens(provided there are still bounties) and the next miner can enter. Ideally, there would be some kind of qeue, but this qeue could be subject to DoS attacks…

- The bounty deposit is not a deposit, but a tax. This tax is not paid out to the job author or the miner, but enters the PoS* pool.

- There is no way for the job author or the miner, to get the "bounty deposit" back directly. The miner is rewarded in form of the bounty they receive. Obviously, the "bounty deposit" must be smaller than the potential bounty, in this case.

- A possible, albeit controversial scenario would be this: XEL has an "offline penalty", meaning, wallets that are offline/not active lose percentual parts of their funds over time. The XEL lost is paid out to stakers, as rewards. This mitigates two problems, XEL possibly has:
--> It is impossible to "burn" funds, therefore, the total amount of XEL won't decrease over time. In a system with fixed supply, this may become a problem at some point.
--> The "bounty deposit" is sent to an address with unknown priv. key (to prove this, the public key could be something like "XELDepositaddressforjobNo.1234", a string of zeros or something like that). Since no one has access to the funds, they decrease over time and float back into the ecosystem to stakers.

Obviously, this will not be well received by speculat*rs and invest*rs, because you can't hold XEL long term. Whether or not you want speculation to happen or not, is a different story, though. If you view XEL as a ticket rather than a currency, I don't see much wrong with it being a tokens that is not meant to be held for long periods of time.

Thoughts?


*There is PoS, right? I'm a little fuzzy in that regard… I mean, you could pay it out to whoever keeps the "regular" system moving