Bitcoin Forum
June 17, 2019, 09:53:16 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 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 ... 346 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 449639 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.
gravitate
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000


View Profile
May 12, 2016, 12:40:37 PM
 #681

EK, I like it.  It looks clean an intuitive to me.

Thanks  Wink

How do I throw my bitcoin your way please?

To peel or not to peel.
1560808396
Hero Member
*
Offline Offline

Posts: 1560808396

View Profile Personal Message (Offline)

Ignore
1560808396
Reply with quote  #2

1560808396
Report to moderator
1560808396
Hero Member
*
Offline Offline

Posts: 1560808396

View Profile Personal Message (Offline)

Ignore
1560808396
Reply with quote  #2

1560808396
Report to moderator
1560808396
Hero Member
*
Offline Offline

Posts: 1560808396

View Profile Personal Message (Offline)

Ignore
1560808396
Reply with quote  #2

1560808396
Report to moderator
NEW GAME FORMAT
JACKPOT UP TO $50000+
Guess The Symbols Of a Real Ethereum Hash
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
fast2fix
Legendary
*
Offline Offline

Activity: 1617
Merit: 1001


Veil-Privacy Without Compromise


View Profile
May 12, 2016, 12:56:54 PM
 #682

EK, I like it.  It looks clean an intuitive to me.

Thanks  Wink

How do I throw my bitcoin your way please?

http://www.elastic.pro/donations



▄▄                                  ▄▄
 ███▄                            ▄███
  ██████                      ██████
   ███████                  ███████
    ███████                ███████
     ███████              ███████
      ███████            ███████
       ███████▄▄      ▄▄███████
        ██████████████████████
         ████████████████████
          ██████████████████
           ████████████████
            ██████████████
             ███████████
              █████████
               ███████
                █████
                 ██
                  █
veil|     PRIVACY    
     WITHOUT COMPROMISE.      
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
|   NO ICO. NO PREMINE. 
   X16RT GPU Mining. Fair distribution.  
|      The first Zerocoin-based Cryptocurrency      
   WITH ALWAYS-ON PRIVACY.  
|



                   ▄▄████
              ▄▄████████▌
         ▄▄█████████▀███
    ▄▄██████████▀▀ ▄███▌
▄████████████▀▀  ▄█████
▀▀▀███████▀   ▄███████▌
      ██    ▄█████████
       █  ▄██████████▌
       █  ███████████
       █ ██▀ ▀██████▌
       ██▀     ▀████
                 ▀█▌




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




     ▄▄█▀▀ ▄▄▄▄▄▄▄▄ ▀▀█▄▄
   ▐██▄▄██████████████▄▄██▌
   ████████████████████████
  ▐████████████████████████▌
  ███████▀▀▀██████▀▀▀███████
 ▐██████     ████     ██████▌
 ███████     ████     ███████
▐████████▄▄▄██████▄▄▄████████▌
▐████████████████████████████▌
 █████▄▄▀▀▀▀██████▀▀▀▀▄▄█████
  ▀▀██████          ██████▀▀
      ▀▀▀            ▀▀▀
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
May 12, 2016, 09:21:51 PM
 #683

I have spent my evening designing the job details page. It just shows some placeholder values (so please don't get confused), will link it to the real data this weekend.
Just wanted to show you how it looks like at the moment, and maybe get some input from the community:

Do you see that something very obvious is missing?
Imagine you have submitted your job to the blockchain ... is there something you would want to "monitor" on such an overview page?


nihilnegativum
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250


––Δ͘҉̀░░


View Profile WWW
May 12, 2016, 09:32:35 PM
 #684

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
May 12, 2016, 09:52:17 PM
 #685

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)
nihilnegativum
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250


––Δ͘҉̀░░


View Profile WWW
May 12, 2016, 09:54:36 PM
 #686

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)
Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
May 12, 2016, 10:01:09 PM
 #687

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)
Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.

Actually, I am not yet sure what would be the best way to go. There are currently three schemes on the table:

- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin. The more people try to get their jobs on the Elastic blockchain the more expensive one GFlop becomes.

I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.

 
bspus
Legendary
*
Offline Offline

Activity: 1862
Merit: 1000


View Profile
May 12, 2016, 10:11:44 PM
 #688


- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin. The more people try to get their jobs on the Elastic blockchain the more expensive one GFlop becomes.

I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.


I think automatic is the best of the 3 listed. I dont think (2) makes much sense when the supply of XEL is fixed .
But (1) should also be included. Perhaps have price auto adjusted and set that as the minimum but allow the job setter to increase his reward to attract workers.Perhaps only by a fixed amount (5 or 10%).
Might even have different price levels. "Normal" for the default auto-adjusted, "Value" (say 10% less) for people with non-urgent jobs who want to take advantage of times when there is little work available and much supply of processing.
And of course "Premium" for the opposite

Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
May 12, 2016, 10:12:39 PM
Last edit: May 12, 2016, 10:47:09 PM by Evil-Knievel
 #689

Also, for the bounties I thought about the following scheme:

Idea: There is a deposit with the job of which a fixed ratio of 60% goes to Proof-of-Works and 40% go to solution bounties. The job is finished when it runs out of money, so if the proof-of-works have collected all of the 60% deposit.

Problem: Not all solutions bounties are necessarily collected before the 60% Proof-of-Work deposit is spent entirely. In this case the remainder of the 40% bounty would be just refunded. Users might be discouraged to look for real solutions at all, if they suspect that bounties are very hard to find (maybe they have some heuristic to estimate this based on the statistics only). This could be possible with a variant of the FAA attack described in the paper.
Working on the function and never intending to submit any useful solution cannot be in the interest of the job author, so we have to save him from that.

Solution?: What if we force that the 40% have to be paid out. Let us say, solution submissions are first collected and they are at first in a "pending state". Then either when the Proof-of-Work money is paid out entirely and so the job is finished or the job is simply cancelled, the bounty (the 40% of the deposit) gets shared among all solution submissions. In the case of a cancellation, maybe only a portion of it.

This way we could enforce that the author of such job pays special attention to the design of his "useful solution space" (means, he makes sure that bounties actually can be found easily enough, otherwise he pays 40% for too few solutions) and meanwhile others (the workers) are fully encouraged to go for the bounties (instead only for the steady PoW payments).

Could this be a scheme that is superior to a fixed bounty per solution no matter how hard it was to get it?
nihilnegativum
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250


––Δ͘҉̀░░


View Profile WWW
May 12, 2016, 10:47:32 PM
 #690

It think that my offer of XEL per gigaflops, and my offer of XEL per gigaflops compared to other jobs would be needed, both for POW and bounties.

This is a very good point. Ideally with a convenient and easy way to quickly adjust it directly from the user interface ;-)
Oh yes, that would be very handy, so you can gradually increase pay to see if it attracts more power, I thought this would be fixed per job.

Actually, I am not yet sure what would be the best way to go. There are currently three schemes on the table:

- Users set the rewards themselves, so the whole thing behaves like an auction where people outbid each other ... offering more if the job is urgent
- All rewards are fixed for all jobs. One GFlop has one associated value in XEL and this never changes.
- We have an automatic adaption of the price per Gflop depending on how many competing jobs existed in the past X blocks and so how much demand was there. Similar to the difficulty adjustment in Bitcoin.

I think this is something we will have to decide on together, but we have plenty of time left for that as it can be swapped out last-minute if necessary.

 
This is an issue of computational profitabillity, that must be considered very carefully because it has immediate systemic effects.

First has thepositive that you can buy time, the negative is that non-profit research directly competes with profitable computation and is either more expensive than it would be or never gets done, or less profitable computation loses to more profitable (so Elastic becomes just an ether pool)
Second  makes XEL representative money, and its value tied to the value of a gflop, this would in time decrease the value as technology improves, but it makes it cheaper to get jobs done.
Third would be computational demand difficulty, this would increase payments with more jobs, so the more successful Elastic is, the more it would cost to use it, but it would attract miners until the price would be too high for jobs. (this has similar effects as the first option)

I think that the first and third aren't viable for Elastic, the second isn't optimal as well.
I have two ideas, but not really thought them through first a correction to the third option, adjustable algo based on two difficulties one determined by # of jobs one by # of computation, (small ammount of jobs = lower payouts (less competition cost), small ammount of computation = bigger payouts (to attract miners), so you get the market flexibility but don't increase costs as much. And second, perhaps some combination could be made, you compute on the higher-pay with higher frequency, but still compute the lesser (randomly so you can't switch it off at the times you're computing for lower pay, if thats possible at all to prevent). In any case, if it is done as generalized payout, a minimum should always be determined (or people will just tag along for free).
Selsonblue
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


View Profile
May 12, 2016, 10:55:12 PM
 #691

Also, for the bounties I thought about the following scheme:

Idea: There is a deposit with the job of which a fixed ratio of 60% goes to Proof-of-Works and 40% go to solution bounties. The job is finished when it runs out of money, so if the proof-of-works have collected all of the 60% deposit.

Problem: Not all solutions bounties are necessarily collected before the 60% Proof-of-Work deposit is spent entirely. In this case the remainder of the 40% bounty would be just refunded. Users might be discouraged to look for real solutions at all, if they suspect that bounties are very hard to find (maybe they have some heuristic to estimate this based on the statistics only). This could be possible with a variant of the FAA attack described in the paper.
Working on the function and never intending to submit any useful solution cannot be in the interest of the job author, so we have to save him from that.

Solution?: What if we force that the 40% have to be paid out. Let us say, solution submissions are first collected and they are at first in a "pending state". Then either when the Proof-of-Work money is paid out entirely and so the job is finished or the job is simply cancelled, the bounty (the 40% of the deposit) gets shared among all solution submissions. In the case of a cancellation, maybe only a portion of it.

This way we could enforce that the author of such job pays special attention to the design of his "useful solution space" (means, he makes sure that bounties actually can be found easily enough, otherwise he pays 40% for too few solutions) and meanwhile others (the workers) are fully encouraged to go for the bounties (instead only for the steady PoW payments).

Could this be a scheme that is superior to a fixed bounty per solution no matter how hard it was to get it?

Easiest and fairest is a fixed cost per job, paid entirely upfront but should prob be released as the job progresses. Work on the variable rate and or auction systems later on after ironing out the initial batch of defects you will uncover when people start using the software.

Just an opinion.

BTW, awesome work on this UI. I really like it

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


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


  ▀████
▀  ▀███  █
  ▀  ▀██  █
    ▀  ▀█  █
      ▀  ▀  █
      ▄  ▄  █
    ▄  ▄█  █
  ▄  ▄██  █
▄  ▄███  █
  ▄████
Abiky
Legendary
*
Offline Offline

Activity: 1400
Merit: 1018


Crypto-Games.net: Multiple coins, multiple games


View Profile
May 14, 2016, 12:31:26 AM
 #692

I like the idea of the Elastic supercomputer. It is a great way of making the blockchain even more useful than before. Can't wait for its official release. I have the feeling that this is going to be huge.  Cheesy


▄▄▄████████▄▄▄
▄██████████████████▄
▄██████████████████████▄
██████████████████████████
████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
████████████████████████████
██████████████████████████
▀██████████████████████▀
▀██████████████████▀
▀▀▀████████▀▀▀
   ███████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
██████████
███████
BTC  ◉PLAY  ◉XMR  ◉DOGE  ◉BCH  ◉STRAT  ◉ETH  ◉GAS  ◉LTC  ◉DASH  ◉PPC
     ▄▄██████████████▄▄
  ▄██████████████████████▄        █████
▄██████████████████████████▄      █████
████ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄ ████     ▄██▀
████ █████ ██████ █████ ████    ▄██▀
████ █████ ██████ █████ ████    ██▀
████ █████ ██████ █████ ████    ██
████ ▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀ ████ ▄██████▄
████████████████████████████ ████████
███████▀            ▀███████ ▀██████▀
█████▀                ▀█████
▀██████████████████████████▀
  ▀▀████████████████████▀▀ 
✔️DICE           
✔️BLACKJACK
✔️PLINKO
✔️VIDEO POKER
✔️ROULETTE     
✔️LOTTO
nihilnegativum
Sr. Member
****
Offline Offline

Activity: 435
Merit: 250


––Δ͘҉̀░░


View Profile WWW
May 14, 2016, 08:49:00 AM
 #693

Also, for the bounties I thought about the following scheme:

Idea: There is a deposit with the job of which a fixed ratio of 60% goes to Proof-of-Works and 40% go to solution bounties. The job is finished when it runs out of money, so if the proof-of-works have collected all of the 60% deposit.

Problem: Not all solutions bounties are necessarily collected before the 60% Proof-of-Work deposit is spent entirely. In this case the remainder of the 40% bounty would be just refunded. Users might be discouraged to look for real solutions at all, if they suspect that bounties are very hard to find (maybe they have some heuristic to estimate this based on the statistics only). This could be possible with a variant of the FAA attack described in the paper.
Working on the function and never intending to submit any useful solution cannot be in the interest of the job author, so we have to save him from that.

Solution?: What if we force that the 40% have to be paid out. Let us say, solution submissions are first collected and they are at first in a "pending state". Then either when the Proof-of-Work money is paid out entirely and so the job is finished or the job is simply cancelled, the bounty (the 40% of the deposit) gets shared among all solution submissions. In the case of a cancellation, maybe only a portion of it.

This way we could enforce that the author of such job pays special attention to the design of his "useful solution space" (means, he makes sure that bounties actually can be found easily enough, otherwise he pays 40% for too few solutions) and meanwhile others (the workers) are fully encouraged to go for the bounties (instead only for the steady PoW payments).

Could this be a scheme that is superior to a fixed bounty per solution no matter how hard it was to get it?
I think this idea would be great as a minimum requirement, so that the network decides the lowest pay per job price with 60/40 proportion, but after you can pay extra to get your work done faster.

I think its important to view Elastic as a supercomputer, that is as a whole so I'd much prefer that jobs are made to the network, and that the network pays miners not in individual case by case. With this in mind I have an idea for a scheme of job-network-miner interaction.

When you create a job you have a minimum of XEL per job determined by the network (60/40), and add extra to bounties if you want. Together you get your XEL/FLOP score. All the active XEL/FLOP scores together are 100% share of the computation of the network and are distributed on a Gauss curve, as a probability of being computated. Miner starts mining on the low XEL/FLOP scores and gradually move towards higher, then continue towards lower, and repeat the cycle in a way that keeps them focused on higher paid jobs.

Pro: You're not buying some computational power, you're hiring a supercomputer. All jobs that are above the required threshold are done. Surplus value comes from bounties while keeping the pow price as low as possible.

Problems: Miners could switch off when computing lower XEL/FLOP scores.
Solution 1: Job obfuscation
Solution 2: Disconect Hell: miners that connect are first stuck computing lower scores.

Tell me if you see more problems and why/how its a bad/unfeasable idea.
andrepierre
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500



View Profile
May 14, 2016, 11:58:29 AM
 #694

I like the idea of the Elastic supercomputer. It is a great way of making the blockchain even more useful than before. Can't wait for its official release. I have the feeling that this is going to be huge.  Cheesy

Invested in this project already, considering to invest more now Smiley
GTTIGER
Sr. Member
****
Offline Offline

Activity: 492
Merit: 250


View Profile
May 16, 2016, 08:59:41 PM
 #695

Interesting concept and interesting execution so far. I can't say that I like that escrow wasn't accepted but it seems that you have reasons. Also, as an investor, I don't mind the added risk because it keeps out others.

Nomad88
Legendary
*
Offline Offline

Activity: 1092
Merit: 1088


View Profile WWW
May 17, 2016, 11:20:14 AM
 #696

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?
cryptoheadd
Hero Member
*****
Offline Offline

Activity: 868
Merit: 500


View Profile WWW
May 17, 2016, 11:22:43 AM
 #697

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?
mentalpanda
Legendary
*
Offline Offline

Activity: 1400
Merit: 1002


View Profile WWW
May 17, 2016, 12:22:32 PM
 #698

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?
yes mostly mixing
https://blockchain.info/tr/address/1BeyK8UPBAuvKahaeLbdDBwuqu1WJRdnca
https://blockchain.info/tr/address/1C1ZXeQUJQGi8GL7iyjoi6zfGd4EC25981
https://blockchain.info/tr/address/1K4iZ9FFDx5CyAWKgfTH3hSCnVRtrmm1eS
https://blockchain.info/tr/address/1Gx4nmEt8VyNeSjn675o3bHZ7VSaZjS5yk
https://blockchain.info/tr/address/1Q4Z1fueBbhL3Jcgv8SssLPUt8HgmCntCA
https://blockchain.info/tr/address/13ckSm9CJL2SPqiQVrDC2C1UxLBUV2Y1Xe
https://blockchain.info/tr/address/14MKronX9pQJui5vVENveDqwKFE6bxWVk4
https://blockchain.info/tr/address/1BrKwsVmHvHxnbgGnnQ4U2KC4rV1a2nUS3


Nomad88
Legendary
*
Offline Offline

Activity: 1092
Merit: 1088


View Profile WWW
May 17, 2016, 03:28:22 PM
 #699

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?


Simple enough, all donations above 0,5btc are untraceable due to mixing. Is it just a coincidence? I have a feeling that those donations are made by the project owners. Do i need to be more clear?
bitbitch
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
May 17, 2016, 03:39:46 PM
 #700

There is one think i am trying to understand, there is a mixer involved for every donation above 0,5btc which makes them very suspicious. Am i missing something here or is it just a coincides?

What do you mean?


Simple enough, all donations above 0,5btc are untraceable due to mixing. Is it just a coincidence? I have a feeling that those donations are made by the project owners. Do i need to be more clear?

to be clear, you are saying that every donation that has been made that is greater in value than 0.5 btc went through a mixer before being donated?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 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 ... 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!