Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 242. (Read 450524 times)

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

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.

Amazing work ttookk!

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.

 

that's amazing.

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

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?

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):

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)

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.

cool picture!

Still get the error :

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

If I try to set my account info

regards

Hi all,

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

feel free to play around.

regards

Started working on a very basic visualization of elastic project



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

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.

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.

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.

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

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.

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