Bitcoin Forum
July 22, 2019, 10:58:51 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 [108] 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 ... 346 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 449651 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
October 11, 2016, 11:15:48 AM
 #2141

(…)

@ttookk thanks for your big involvement.

If you need something specific from me please send me PM (I'll get email notif).

(…)

Nice to see you're back Smiley

I'm not a technical person, so I wouldn't even know where to begin to ask for anything specific Tongue So I'll spin it around: If you guys need graphics, e.g. for a certain scenario, feel free to ask, I'll do my best.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563793131
Hero Member
*
Offline Offline

Posts: 1563793131

View Profile Personal Message (Offline)

Ignore
1563793131
Reply with quote  #2

1563793131
Report to moderator
1563793131
Hero Member
*
Offline Offline

Posts: 1563793131

View Profile Personal Message (Offline)

Ignore
1563793131
Reply with quote  #2

1563793131
Report to moderator
1563793131
Hero Member
*
Offline Offline

Posts: 1563793131

View Profile Personal Message (Offline)

Ignore
1563793131
Reply with quote  #2

1563793131
Report to moderator
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
October 11, 2016, 11:21:48 AM
 #2142

Feature Announcement / Discussion

Currently, Elastic only supports "bruteforceable" work and with it it covers a lot of work types. However, this scheme does not allow specific use cases where work is performed on a large portion of data and does not operate on a "search space" (like elastic's 384 bit long random entropy) but rather on different portions of blob data. Typically an example might be the rendering of a large video or audio stream.

So I suggest to add a second type of job type which works a bit diffently.
Similar to Zennet you can in addition to the already present "ElasticPL" scheme, write "Elastic Dist" programs. Here, a work author creates a regular job but does not submit source code to the blockchain but rather submits a "IP for a public Elastic Dist node". Miners then connect to the node which then distributes both "Data and Sourcecode" which has to be then executed by the miners. Here, we again work ith the safe-to-execute ElasticPL language.

Here, the "Elastic Dist Node" can seperate the work itself into packages, and submit them along with data (up to x MB) to the nodes. They return the result back and get paid the PoW price. Here, we cannot use any proof of execution in order to prevent blockchain cluttering, but we use (like Zennet does, big credits to them) micropayments. Miners do not execute other tasks until they receive the micropayment from the last code portion.

So let's say we have 2 miners, and a Elastic Dist job with a public work distribution node. Imagine we want to render a video. The job is split into 100 different sub-tasks (which fit in the maximum allowed WCET per program). The work author announces this job and says it pays 100 XEL per execution. The 2 miners then poll 1 subpackage each, calculate it and submit it to the Elastic Dict node and wait for the micropayment of 100 XEL. Once received, they poll the next subpackages. If not, they wasted at most WCET computation time.
If the Elastic Dist node becomes unreachable, no ork is done and no XEL is paid. The job just times out.

This opens a few attack vectors of course were the Elastic Dist node does not send any micropayment. We would have to think about it, how to mitigate that.

This scheme would be a bit trust based, but in conjunction with the traditional ElasticPL work type, allow to do ANYTING with elastic ... from mining, bruteforcing up to rendering arbitrary tasks.

For those who need more security write their programs in the somewhat limited Elastic PL scheme, those with special requirements use Elastic Dist which is somewhat trust based.

What do you think, ttookk and others?
ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
October 11, 2016, 11:36:37 AM
Last edit: October 11, 2016, 11:48:53 AM by ttookk
 #2143

I like it.

I see this as a good way to make use of the network, when there are no "technical" problems to be solved. As pointed out earlier, "voids" in the workload might become a problem when they get too big.

I think, rendering a video would be one of the most common use cases, in this youtube era, where spitting out quality content as fast as possible is a must to stay over water. Now, this might not be the userbase, Elastic wants to attract, but why not? As long as they are paying (and telling their viewerbase about Elastic). Effectively, this might bring more popularity to and more computing power into the Elastic network, which is good for all sides involved.

I wrote this part like a thousand times, but still: this may be the point, where we should think about a reputation system. See my previous posts and all that.

By the way, it is somehow possible to encrypt a video or other file in a way, that it can still be rendered but is unreadable for the miner?

These are my initial thoughts, and I am more than willing to step back from them.
Mrboot
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000


View Profile
October 11, 2016, 11:41:47 AM
 #2144

This is a hard project to follow if your not technical at all, but damn it looks great.

Im really impressed and happy i invested, but now i have a question.

I cant find any details about the chain anymore, is it still POS and what are the rewards.
Small things like that.

And developers if this work out i will def send you some nice extra working tip.

Kind Regards,
ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
October 11, 2016, 11:53:25 AM
 #2145

(…)

I cant find any details about the chain anymore, is it still POS and what are the rewards.
Small things like that.

(…)

I'm a little fuzzy regarding this part, but as far as I know, it still has PoS. Since the number of tokens is fixed, the PoS reward would be transaction fees only.
ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
October 11, 2016, 07:30:30 PM
 #2146

What may create a little problem, though, is the question of how to value the two types of jobs relative to each other. I mean, there is the risk that one of the two job types is that much more profitable, that miners won't bother to work on the other. You could hope for "the market" to sort it out, i.e. the pricing will be adjusted according to it, but it might not be enough.

Here are some random thoughts I had today: I was thinking about how Elastic will be used and will be perceived of the general public and the more I think about it, the more I think that its place is more of a backend solution than a full-blown, frontend flashy GUI thing. With the two jobs in place, we will probably have two main types of job authors:

1.: Scientific users, who need numbers to be crunched and problems to be bruteforced. Those will probably write their own code, or are otherwise able to use and interpret existing code for their tasts. It is safe to assume, that they don't need a shiny frontend, they need something reliable to get the job done.

2.: Everyday users, that need big chunks of data, e.g. a video, processed. Let's assume, there is a youtuber who wants to put out quality content in a timely manner. They probably don't have a renderfarm at hand, so they want to use Elastic for the job. For them, there's gonna be a number of obstacles:

- I wouldn't expect them to be even able to use the terminal, or console. They would have to use premade code that fits their requirements and would probably need a easy to use GUI that tells them exactly what to do. To reach them, some kind of database is needed(to be clear, I don't mean that it's the Elastic core teams job to create such libraries, but it would be handy if someone did at some point. As with other blockchains, once the whole thing takes off, I'd expect multiple clients to pop up that maybe are specialized for specific use cases. If rendering videos is all you're gonna do with Elastic, a client that is helping you with that and nothing else would be perfect.)

- Bitcoin itself is still a barrier to entry, the need to purchase XEL will be even worse. What Elastic would need is a gateway, where you can buy the exact amount of XEL needed, no questions asked. On the frontend, it would look like you paid with BTC or even fiat, the XEL is only used in the background, nearly invisible to "regular customers". It may even be possible, that they use clients to rent computing power without realizing, that they actually use blockchain technology.

- Volatility is a general problem crypto has and I believe it is one of the main obstacles for mass adoption. Let's say a bread costs 3 €. If you'll ask people on the street, whether they would like to know that bread costs 3 € tomorrow as well, or you'd give them a 33/33/33% chance, that a bread will cost 1,5 €, 3 € or 4 € tomorrow, I think most will opt for stability, although in the long run, taking that chance would give them a cheaper price. Now, it is hard to adjust Elastic in a way, that volatility is kept at a minimum, but I suspect, that the volatility will keep a lot of potential users away.

If we want Elastic to be adopted by a mainstream group (I'm not saying that we want to, but let's assume we do), we have to make the entry as simple as possible. This includes:
- An easy-to-use GUI.
- Getting rid of the necessitiy to write own code and use "off the shelf" solutions instead.
- Creating a gateway, that safely calculates and purchases the right amount of XEL in the background.

This is not something that needs to happen NOW. I think it would be perfectly fine to release Elastic into the wild with the one type of job as a possibility, then work on the other part. Depending on its success, it might attract other people and devs, who will work on the second type of job and hopefully develop aforementioned clients.

As I said before, I don't expect this to be the job of the core team, to create easy-to-use solutions for non-technical users, but I think the question whether we expect other clients with premade preferences to emerge or not could possibly influence how Elastic is developed.


akhavr
Full Member
***
Offline Offline

Activity: 235
Merit: 100



View Profile
October 12, 2016, 07:03:33 AM
 #2147

Miners do not execute other tasks until they receive the micropayment from the last code portion.

Any other task at all or any other task from this work distribution node?

So let's say we have 2 miners, and a Elastic Dist job with a public work distribution node. Imagine we want to render a video. The job is split into 100 different sub-tasks (which fit in the maximum allowed WCET per program). The work author announces this job and says it pays 100 XEL per execution. The 2 miners then poll 1 subpackage each, calculate it and submit it to the Elastic Dict node and wait for the micropayment of 100 XEL. Once received, they poll the next subpackages. If not, they wasted at most WCET computation time.

How I, as a work author, can be sure that the work is really performed and I've got not just a noise?  Running the same job on 2+ miners?  Miners reputation?

akhavr
Full Member
***
Offline Offline

Activity: 235
Merit: 100



View Profile
October 12, 2016, 07:08:11 AM
 #2148

2.: Everyday users, that need big chunks of data, e.g. a video, processed. Let's assume, there is a youtuber who wants to put out quality content in a timely manner. They probably don't have a renderfarm at hand, so they want to use Elastic for the job. For them, there's gonna be a number of obstacles:

Such users be better served by regular web apps.  Say, I'd create a site, where you can upload your video and get it rendered for a paypal payment.  The fiat price would include all kinds of risks -  volatility, chargebacks - and some profit of course.

tomkat
Hero Member
*****
Offline Offline

Activity: 1022
Merit: 507


View Profile
October 12, 2016, 07:27:52 AM
 #2149

Miners do not execute other tasks until they receive the micropayment from the last code portion.

Any other task at all or any other task from this work distribution node?

So let's say we have 2 miners, and a Elastic Dist job with a public work distribution node. Imagine we want to render a video. The job is split into 100 different sub-tasks (which fit in the maximum allowed WCET per program). The work author announces this job and says it pays 100 XEL per execution. The 2 miners then poll 1 subpackage each, calculate it and submit it to the Elastic Dict node and wait for the micropayment of 100 XEL. Once received, they poll the next subpackages. If not, they wasted at most WCET computation time.

How I, as a work author, can be sure that the work is really performed and I've got not just a noise?  Running the same job on 2+ miners?  Miners reputation?

I guess, the miners would need to run an algo/a script/whatever is supposed to do the rendering job, and not just a series of computations not related to input data.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
October 12, 2016, 08:40:25 AM
 #2150

Miners do not execute other tasks until they receive the micropayment from the last code portion.

Any other task at all or any other task from this work distribution node?

So let's say we have 2 miners, and a Elastic Dist job with a public work distribution node. Imagine we want to render a video. The job is split into 100 different sub-tasks (which fit in the maximum allowed WCET per program). The work author announces this job and says it pays 100 XEL per execution. The 2 miners then poll 1 subpackage each, calculate it and submit it to the Elastic Dict node and wait for the micropayment of 100 XEL. Once received, they poll the next subpackages. If not, they wasted at most WCET computation time.

How I, as a work author, can be sure that the work is really performed and I've got not just a noise?  Running the same job on 2+ miners?  Miners reputation?

The second scheme was just a first idea, open for discussion ;-) And you have perfectly argued that probably such tasks (as rendering) should be performed on centralized services.

But we can brainstorm a little, to identify if its really so bad and we should leave it out, or if it's worth pursuing this idea.

To your first question: Only for the work distribution node (or any other that the miner is connected to). The blockchain would not track any work, it would be used only to negotiate work between "distribution node" and "worker node" and keep them working by periodically sending micropayments.

To your second question: of course you canot be sure, this is of course a problem and this is why i personally think Zennet is inferior to us. You have to "trust" or somehow ensure that the result is plausible or not yourself. If you think the result is bad, you can deny the micropayment and not distribute any work to the connected worker node anymore.

This scheme is of course fragile! I am just interested if it could somehow work as an "additional work type" or if we better leave it out and stick to our "verifiable computation scheme" which is robust.
cryptoboy.architect
Hero Member
*****
Offline Offline

Activity: 513
Merit: 500


View Profile
October 12, 2016, 08:54:10 AM
 #2151

Love the project development so far. I was looking into building something similar.

Few ideas here:

- instead of inventing a new language, why not use OpenCL? It is fairly straightforward and kernels compile on the host. As an added benefit - you can request work done on the GPU. Now we are talking real computing power.

- hook to IPFS, so that a worker that requires big data could fetch it by a hash. Result of the work, if it is large could also be returned via IPFS hash.

- with respect to verifying the work - just like in mining, a job could have a "manager" script, which computes portions of the work. i.e. it's the developer's responsibility to provide some ratings metrics, so that job can be assigned to the most reputable hosts.
ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
October 12, 2016, 09:16:29 AM
 #2152

(…)

How I, as a work author, can be sure that the work is really performed and I've got not just a noise?  Running the same job on 2+ miners?  Miners reputation?

The second scheme was just a first idea, open for discussion ;-) And you have perfectly argued that probably such tasks (as rendering) should be performed on centralized services.


This might be an answer to the trust and possible abuse scenario:


- with respect to verifying the work - just like in mining, a job could have a "manager" script, which computes portions of the work. i.e. it's the developer's responsibility to provide some ratings metrics, so that job can be assigned to the most reputable hosts.


Other miners recalculate small random portions of the work and check whether they fit or not.

Quote
But we can brainstorm a little, to identify if its really so bad and we should leave it out, or if it's worth pursuing this idea.

(…)
This scheme is of course fragile! I am just interested if it could somehow work as an "additional work type" or if we better leave it out and stick to our "verifiable computation scheme" which is robust.

I still like the idea, but as pointed out, I'm not sure whether it is something you should pursue right now, maybe this should be treated more like a possible future addition to Elastics main functionality.
wwdz99
Sr. Member
****
Offline Offline

Activity: 245
Merit: 250



View Profile
October 12, 2016, 12:09:21 PM
 #2153

The OP has been updated with the current website.

Well done Lannister ,Nice to see u active again!
mr.coinzy
Hero Member
*****
Offline Offline

Activity: 504
Merit: 507



View Profile
October 12, 2016, 03:42:53 PM
 #2154

Did anyone hear about the current problems with blockchain.info?
Seems there are issues there and I really hope accounts where not compromised and such...
What will happen if we can not safely access blockchain.info accounts? some people sent their btc to the funding from such account (myself included).
Thanks.
anhpt192
Hero Member
*****
Offline Offline

Activity: 629
Merit: 500



View Profile
October 12, 2016, 03:55:09 PM
 #2155

Did anyone hear about the current problems with blockchain.info?
Seems there are issues there and I really hope accounts where not compromised and such...
What will happen if we can not safely access blockchain.info accounts? some people sent their btc to the funding from such account (myself included).
Thanks.

I tested some BTC transactions from exchange to exchange, transfers were done and coin was credited to my balance.
I don't think these is a big issue.



             ▄█
            ██  ██
           ██  ████
          ██  ██  ██
         ██  ██    ██
        ██  ██  ██  ██
       ██  ██    ██  ██
      ██  ██  ██  ██  ██
     ██  ██  ████  ██  ██
    ██  ██  ██  ██  ██  ██
   ██  ██  ██    ██  ██  ██
  ██  ██  ██████████  ██  ██
 ██                    ██  ██
█████████████████████▄  ██  █
                         ██
▀███████████████████████████




█████ █   █ █████      ███          █████████████▄▄    ████            ████     ▄▄██████████      ▄▄██████████
  █   █   █ █         █████         ████████████████    ████          ████     █████████████     █████████████
  █   █████ █████    ███████        ███         ▀███     ████        ████     ███▀              ███▀
  █   █   █ █        ███ ███        ███          ███      ████      ████      ███               ███
  █   █   █ █████   ███   ███       ███          ███       ████    ████       ███               ███
                    ███   ███       ███         ▄███        ████  ████        ███▄              ███▄
                   ███     ███      ██████████████▀          ████████          ██████████▄▄      ██████████▄▄
                   ███     ███      ██████████████▄           ██████            ▀▀██████████      ▀▀██████████
                  ███       ███     ███         ▀███           ████                      ▀███              ▀███
                  █████████████     ███          ███           ████                       ███               ███
                 ███████████████    ███          ███           ████                       ███               ███
                 ███         ███    ███         ▄███           ████                      ▄███              ▄███
                ███           ███   ████████████████           ████           ██████████████    ██████████████
                ███           ███   █████████████▀▀            ████           ███████████▀▀     ███████████▀▀

█  █
█  █
█  █
█  █
█  █
█▄▄
▀▀█
█  █
█  █
█  █
█  █
█  █

█  █
█  █
█  █
█  █
█  █
█▄▄
▀▀█
█  █
█  █
█  █
█  █
█  █
.PRE-SALE▬.... Nov 29 2017
.TOKEN SALE. Dec 12 2017

ANN Thread  ■  Whitepaper
■  Twitter
■  Telegram
■  Facebook
ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
October 12, 2016, 04:12:40 PM
Last edit: October 12, 2016, 05:54:11 PM by ttookk
 #2156

Did anyone hear about the current problems with blockchain.info?
Seems there are issues there and I really hope accounts where not compromised and such...
What will happen if we can not safely access blockchain.info accounts? some people sent their btc to the funding from such account (myself included).
Thanks.

I'm pretty sure there is a way to download your private key from your blockchain account. If you are afraid, that you won't have access to blockchain.info, do it(might be a good idea anyway), store it in a safe place and you can access your BTC address through pretty much any other wallet, that allows import of a priv.key (which are probably all of them).

Regarding video rendering on Elastic: The name of the dedicated client should be

XELLULOID

Had to be done Grin
tomkat
Hero Member
*****
Offline Offline

Activity: 1022
Merit: 507


View Profile
October 12, 2016, 05:02:13 PM
 #2157

Did anyone hear about the current problems with blockchain.info?
Seems there are issues there and I really hope accounts where not compromised and such...
What will happen if we can not safely access blockchain.info accounts? some people sent their btc to the funding from such account (myself included).
Thanks.

They claim it's DNS issue - see here https://twitter.com/blockchain.
I don't know if such issue require several hours to resolve though.

You need your private key(s) to claim XEL, so if you haven't got it from there yet, then you can only wait Sad
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
October 13, 2016, 07:24:04 AM
Last edit: October 13, 2016, 07:51:15 AM by Evil-Knievel
 #2158

Did anyone hear about the current problems with blockchain.info?
Seems there are issues there and I really hope accounts where not compromised and such...
What will happen if we can not safely access blockchain.info accounts? some people sent their btc to the funding from such account (myself included).
Thanks.

They claim it's DNS issue - see here https://twitter.com/blockchain.
I don't know if such issue require several hours to resolve though.

You need your private key(s) to claim XEL, so if you haven't got it from there yet, then you can only wait Sad

Or use one of the BIP39/BIP44 converters (e.g. https://iancoleman.github.io/bip39/) to convert your blockchain.info mnemonic seed to a private key stream.

Disclaimer: The linked project above is not mine and I have not reviewed it, just found it on google ... use at own risk and check the source code first. Ideally, use on an offline computer!!!
akhavr
Full Member
***
Offline Offline

Activity: 235
Merit: 100



View Profile
October 13, 2016, 08:36:15 AM
 #2159

To your first question: Only for the work distribution node (or any other that the miner is connected to). The blockchain would not track any work, it would be used only to negotiate work between "distribution node" and "worker node" and keep them working by periodically sending micropayments.

Tnx

To your second question: of course you canot be sure, this is of course a problem and this is why i personally think Zennet is inferior to us. You have to "trust" or somehow ensure that the result is plausible or not yourself. If you think the result is bad, you can deny the micropayment and not distribute any work to the connected worker node anymore.

This scheme is of course fragile! I am just interested if it could somehow work as an "additional work type" or if we better leave it out and stick to our "verifiable computation scheme" which is robust.

It's good to have this work type, my point is that the network has to have rules to help to set up such work.   

In this context I like proposal by @ttookk, even if the ratings update would be a job's point of responsibility.  OTOH then we'd have to have something to mitigate attacks on rating by malicious job authors.

+1 to the future addition.

Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
October 13, 2016, 08:56:31 AM
 #2160

@akhavr,ttook: The problem with rating schemes is imho that you can create an infinite number of alternative identities, all with a clear background. Reputation may work in centralized systems that require some sort of authentication like e.g. eBay, but if we do not want to penalize new users without any rating, we will have a hard time coming up with a reputation system that really works. I mean I could rip off some workers, collect negative reputation, move the XEL to a fresh account and start over.

What do you think?
Pages: « 1 ... 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 [108] 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 ... 346 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!