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

If you want to try XEL ( Elastic ):

Download testnet client https://github.com/OrdinaryDude/elastic-core.
Best if you download it trough git for future easy updates. Install git on your machine and:

git clone https://github.com/OrdinaryDude/elastic-core.git

Watch this video for instructions how to run it https://player.vimeo.com/video/178616474?quality=1080p and paste your address here to receive some XEL for testing and fun.

Also you can get some XEL through faucet: http://elasticexplorer.org/faucet/

There is no compile script for Windows at the moment but I'll provide pull request to main github with it once I'll have time for it.

---

If you want to try out a miner:

1. Download it from: https://github.com/OrdinaryDude/elastic-miner
Best if you download it trough git for future easy updates. Install git on your machine and:

git clone https://github.com/OrdinaryDude/elastic-miner.git

2. ./compile.sh
3. ./run.sh
4. Give it your passphrase (after you hit a key make sure visible XEL address is yours)
5. Give it a XEL running daemon IP address (default localhost)
6. Hit enter and submit work to the network in your XEL client UI as shown here https://player.vimeo.com/video/178616474?quality=1080p. If someone else will submit work to the network your miner will automatically start working on it.
7. Example work are here https://github.com/OrdinaryDude/elastic-reference-client/tree/master/elasticpl_examples. no_bounties_found.epl will not found any bounty! Be warned that this is debug job that will just expire after 250 blocks without any submissions.

Suggestions:

run miner with lower cpu priority for optimal experience. Especialy if you running miner on the same machine that you running XEL node.

i. e.

20 is lowest possible priority in most linux env.

---

If you want to update XEL to the newest version:

Stop your node (CTRL + C)
Go to main directory of XEL and:

---

If you want to update miner to the newest version:

Stop your miner (CTRL + C)
Go to main directory of miner and:

java stack exception as in "maximum allowed AST depth reached?" or a true java stack exception?
In my eyes 7 seconds is bad enough  

I will send you a BTC from my own savings soon, to express my gratitude for helping me with the parser.
We still have to figure out what to do with this awful FAA ;-) And, generally, with all those other "really interesting attacks".

And I hope that we will soon see official bounty bug hunting guidelines here, but until then I strongly assume that you will be rewarded by Lannister for sure   Thanks once again for all your help, without you we would be 10 steps behind.

Well, that is cool, but I'm still not so sure about the proposition...


I think that some of the assumed distinctions between PoW and PoB are problematic.  This is directly related to the "really interesting" attacks.


Turns out that this is probably far less interesting.  With the current repo state, most of these manifest as java stack exception.  About the most that I can "hang" the parser right now is 3-7 second at a time. ([email protected], sun "jre 8")  Not sure if that is a problem.  Noticed heap GC got a little crazy though, so it might be that it could still be tuned into a combination problem.

Ok, this is just me, brainstorming bullshit again. I know, that right now, XEL is supposed to be a standalone currency, and there are a lot of people who want to keep it that way, so that they have tokens to speculate with. I am one of those and to be honest, what makes me most excited is a fat ROI at some point.
However, at the moment, I am working on an idea to create blockchains, that ultimately use tokens backed one-to-one with Bitcoin. The basic idea is that you pay BTC into a generated address and get the corresponding amount of tokens out of it. With this, you get a return address, to which you can send the tokens back. This pays out the corresponding amount of BTC held in the wallet (or parts of it, if only parts get sent in.) to a stated address, burning the tokens. This way, you would have a framework in which you can effectively use BTC, which has some significant advantages:
- You don't have to get XEL somewhere, if you have BTC, you're fine
- If you want to use Elastic, you are not subjected to volatility due to market movements that have nothing to do with XELs usability. Granted, BTC is volatile as well, but is still less volatile than most cryptocurrencies, probably including XEL. I am vary of single-use tokens overall, since i see dangers regarding their worth*, but that is probably besides the point.
- You might incentivise miners to point their power towards XEL, because they can effectively earn BTC directly, probably even mre easily than by traditional mining.

There are obviously a lot of questions to be answered and at this point, this is a mere idea. I am not saying that we should change the direction and move towards the ideas pointed out above, but at some point in the future, it might be interesting to copy XELs code and create something like mentioned above.

This idea is not limited to XEL, but XEL looks like a posterboy use case for it. Ideally, you would create a framework on top of which you can put any blockchain technology, that doesn't require new tokens to be mined (I mean, technically you could implement PoW/PoS in those scenarios, but you would dilute the BTC invested).
This idea is in its very early stages, probably not that unique anyway and if it is, it won't come to life until someone else gets it, too, because I am neither technically nor financially able to execute it.

As I tried to point out, I highly dout that no one is working on exactly this idea, since it sounds really basic to me. I'd love for someone to gie me some pointers where I could read more about it.

Feel free to ignore ths post, btw. just some stuff I had to get off my back.



*In fact, I suspect that volatility is one of the reasons why blockchain technology is not mass-adopted yet. I think the more use cases a currency has, the less volatile it gets.

Actually, in my scheme you would be able to submit PoW submissions with 0 XEL, just no bounty submissions. SO you would have to keep PoW'ing until you have enough for the bounty deposit fee.

Also having to reveal the bounties in "x blocks" might be very well "x seconds" based on the next blocks' timestamps (which can no be tampered that much by a malicious forger) as well.

Just brainstorming.


Im really interested ....


... and even more! Thanks for everything so far!!

Awww, come on, if you spend xxxxx on mining equipment, buying what is probably a two figure $ amount of XEL is not that big of a deal, is it?

I mean, I get what you mean and XEL will miss out on lots of mining power that is pointed elsewhere due to inconvenience, but it would lose even more mining power, if miners would avoid it because of the risk of being outrun. Kind of a "lesser evil" deal.

Additionally, there may be ways to get XEL "outside" of the system,to incentivise new miners to get in. You could create a loan service, where miners can loan a start amount of XEL for BTC or whatever they have laying around.

Another problem, as mentioned before, is that it precludes people with 0 XEL from becoming work miners to get XEL.  If you want to mine XEL you'd first have to buy XEL, which is less than ideal from the miner's perspective.

Well obviously submitting an *infinitely* deep program is impossible in finite bandwidth, but yah - there were opportunities to leverage the parser to cripple nodes.

I'll have to re-check one of my remaining (DoS) attacks (which I've been calling the "max backtrack attack") against the parser.  Although I suspect that this change will prevent a node from being knocked out entirely by the attack, I also suspect that the attack could still be used to "temporarily hang" a node.  (Short version explanation:  use the production order of the parser to craft "worst case parse time" expressions and then spam them at a node.)

I'm biased, but I think sending hashes first and taxing them somehow is a valid idea. Could you elaborate on why you don't want to go that route?


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…

P.S.
Has the "official" bounty plan been formalized yet? 

I suspect that you will eventually end up combining the pools, anyway.... heh.


It is perhaps worth noting that it seems there will always be opportunity for races.  A publisher could submit a refund cancellation as soon as they see a PoW/PoB tx announced and try to race it.  One could even immediately submit cancellations as soon as work is published, in hopes of just seeing some "stale" PoW/PoB certificates announced by miners who haven't realized the cancellation yet.  (EDIT: Note that while it is assumed that watching for PoW certs should be "pointless" I'm afraid that it isn't, as I'll illustrate later.  )


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

I was brainstorming with a bunch of guys about this today.
Well, we could not come up with a solution for the bounty fund based FAA attack so far. But this is what we thought of:

1. One solution might be to make the bounties regular POW submissions which pay the very same absolute amount per submission from one single XEL fund. This limits the possibilities significantly, because you would be no longer able to set up very large bounties (which could attract some workers) for solving your task.

2. Otherwise you could stick with the idea of a bounty fund, but pay a fixed portion of it upon submission of a solution. Here, you could only try a race where you submit more bounties than allowed quickly when you see a valid submission online and hope that only yours end up in the block (effectivle all end up in a block but only the first x count). This attack could be further mitigated (not fully eliminated, as the probability of filling the first x spots increases with the number of bounties submitted) by ensuring a pseudo random order in which unconfirmed transactions have to be included in a block. This of course only helps if the attacker is not the forger at the same time. If we went for that solution we lose the funny aspect of people racing each other even after they have submitted bounties with the intention to maintain their percentual amount of bounties amongst all.

3. All ideas that include first submitting the hashes of the bounties and revealing them after they have been included in a block (at a good position so they count) are tricky as we cannot verify such bounties for correctness. This would open all work packages for a broad variety of DOS attacks through the submission of illegitimate bounties. So we would have to use "penalty" here: it could be possible to mitigate the DOS attacks by the requirement to attach a "bounty submission deposit" of x XEL to each unrevealed bounty submission and receiving it back (along with the actual reward) when the solution is revealed within the next x blocks and evaluates correctly. Otherwise the deposit is forfeited. Not sure if we want to go this way though.

I seem to be too dumb to reliably estimate the maximum stack space usage, so I (for now) just limit the allowed depth of the AST tree to 512. This should prevent exceeding the available stack space even though it's far from elegant.

The AST Tree depth limit exhaustion is detected *during* parse, and not traversed using BFS after the tree has been built. This prevents another attack where an attacker submits a job with an infinitely deep AST tree in the hope of triggering an out of memory error and shooting down once specific node.

Wow I am happy to be one of the early donors on this project after luckily finding this. It's exciting to watch this project grow and see new people getting interested.

unvoid, there is no file compile.bat in elastic-core folder. I want to test on windows also.

All operations have a cost...


I'm using a "circuit size" comparison.  By synthesizing random logic into both a (minimized) BLIF-MV specification and an ElasticPL program, and then comparing relative gate counts to WCET values, it becomes pretty easy to spot cases where cost is drastically mis-estimated.

Here's a related problem, "HMC Bug #10" aka "1 WCET Indirection Machines" which allow arbitrarily large programs (again, not using the hashing or curve statements) to be encoded with a cost of 1:
The programs:
and
both have WCET 1, but the second example actually requires 10 times the work in the assignment....

This can also be used with the "boolean expression transform" that I described for the verify case to stuff arbitrarily large programs (even greater than the limit constant) into "1 WCET" programs.

Woops.

(Use of the hash/curve statments can usually be done as well, it just requires a more complex transform "splitting" the program at the statement.)

The RuntimeEstimator will need to count literally every execution cost along the longest path through the control flow.  This includes costs of memory accesses and control flow through shortcut boolean evaluations and... exactly *every* operation that the vm can perform.

i think going on an exchange in 2 months is very realistic.

thank you for your feedback . It makes sense, just no time frame is a little frustrating .

Fixed! I am so glad that we have you here, helping us with all these nasty bugs!

This leaves the question what to specify as the "weight". The base weight is 0, and "costful" operations such as inserting a variable into the symtab, or doing some elliptic curve arithmetics have some positive weight.

Putting everything into the verify routine is of course one possibility to circumvent WCET calculation. This leaves us with the question what to account for in the weight? Should we consider 1 as the base weight? Making every operation worth 1 credit, and overriding that value for "more complex operations" which in fact require more operations internally?

I would have to think about it, I have no feeling yet for the correct definition on "weight"  
Using a base weight of 1 and accounting for the verification weight in the WCET calculation would mitigate this attack for now! Let's do it.