Any news on the logo vote ?
Round#1 is finished, with slide=03 on top. Unvoid wanted to do another round with only the Top10.
Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 52. (Read 450520 times)
Round#1 is finished, with slide=03 on top. Unvoid wanted to do another round with only the Top10.
Why is the website http://www.elastic.pro/ offline?
Because guy who was responsible for this website is offline.no one is responsible for this fault but here is only system can be responsible.
Any news on the logo vote ?
Round#1 is finished, with slide=03 on top. Unvoid wanted to do another round with only the Top10.
I'm suprised the guy that stole the 700 bitcoins can't be found. Did the team actually never meet him?
Nobody stole anything here! Just stop it!
I'm sorry what
http://www.elastic.pw/blog/2017-04-15-status-of-lannister-and-ico/
There was NO ICO, only voluntary DONATIONS. Stop this already. Also STOP accusing people without checking the facts and without any proofs.
I'm suprised the guy that stole the 700 bitcoins can't be found. Did the team actually never meet him?
Nobody stole anything here! Just stop it!
I'm sorry what
http://www.elastic.pw/blog/2017-04-15-status-of-lannister-and-ico/
There are no ICO funds, there never even was an ICO.
What are you trying here?
Any news on the logo vote ?
I'm suprised the guy that stole the 700 bitcoins can't be found. Did the team actually never meet him?
Nobody stole anything here! Just stop it!
I'm sorry what
http://www.elastic.pw/blog/2017-04-15-status-of-lannister-and-ico/
There are no ICO funds, there never even was an ICO.
What are you trying here?
I'm suprised the guy that stole the 700 bitcoins can't be found. Did the team actually never meet him?
Nobody stole anything here! Just stop it!
I'm sorry what
http://www.elastic.pw/blog/2017-04-15-status-of-lannister-and-ico/
I'm suprised the guy that stole the 700 bitcoins can't be found. Did the team actually never meet him?
Nobody stole anything here! Just stop it!
I'm suprised the guy that stole the 700 bitcoins can't be found. Did the team actually never meet him?
Firstly I will setup a crowd fund raising; Where we at least have to bring in 200 BTC with the community so we establish a strong foundation to pay devs, pr, website and other costs.
200 BTC is not for JUST a website. read it again. forget it, let me bullet point it for you. it is to
* Pay Devs (current and future Devs we might need to help EK)
* PR campaign (publish articles, twitter campaign, BTC sig campaign etc)
* Website (to build professional elastic website, to run elastic forum, elastic reddit & elastic slack)
* Other (Pay listing fees to exchanges like bittrex)
So what I see from several community member is a NO, but not coming with an alternative solution. Guys if we want this project to succeed we really have to start adding value to it. By skills, knowledge and funds.
This 200 BTC will be indeed used for many things such as stated above. And there will be a lot of costs which are unseen at the moment but where we need funds for. 200BTC is still not that much, its an start of creating a strong foundation from where we can start building the project.
The funds can be held by several trusted members in the community.
Another sure thing is that we need an manager who will steer the ship. It can be me or someone else who think he can do the job in a great way. And for this task I think its very appropriate the person get something in return for his efforts. Just like it is appropriate that the people who will build the website, write content, do marketing and the devs all get something in return for their efforts. By creating the foundation, we can pay everybody for all their hard work. I think this is more then normal.
Looking forward to the reply's and hope we can make this happen, I think it will boost the project in an very positive way to the right direction.
I personally like twistelaar's suggestion, but I must qualify that I don't have any BTC to donate to a foundation, and even though right now I'm currently helping to recode the ElasticPL engine, I don't personally want to be part of running a foundation...I'm just in the background and may help out as / when I have time and the interest to do so.
The idea of a foundation has been around for a while and hasn't gotten any traction, but it's very clear that this project needs some sort of leadership. I don't think EK can be any clearer about his stance on this issue, but it seems everyone keeps looking to him to run this project.
Firstly I will setup a crowd fund raising; Where we at least have to bring in 200 BTC with the community so we establish a strong foundation to pay devs, pr, website and other costs.
200 BTC is not for JUST a website. read it again. forget it, let me bullet point it for you. it is to
* Pay Devs (current and future Devs we might need to help EK)
* PR campaign (publish articles, twitter campaign, BTC sig campaign etc)
* Website (to build professional elastic website, to run elastic forum, elastic reddit & elastic slack)
* Other (Pay listing fees to exchanges like bittrex)
So what I see from several community member is a NO, but not coming with an alternative solution. Guys if we want this project to succeed we really have to start adding value to it. By skills, knowledge and funds.
This 200 BTC will be indeed used for many things such as stated above. And there will be a lot of costs which are unseen at the moment but where we need funds for. 200BTC is still not that much, its an start of creating a strong foundation from where we can start building the project.
The funds can be held by several trusted members in the community.
Another sure thing is that we need an manager who will steer the ship. It can be me or someone else who think he can do the job in a great way. And for this task I think its very appropriate the person get something in return for his efforts. Just like it is appropriate that the people who will build the website, write content, do marketing and the devs all get something in return for their efforts. By creating the foundation, we can pay everybody for all their hard work. I think this is more then normal.
Looking forward to the reply's and hope we can make this happen, I think it will boost the project in an very positive way to the right direction.
Guys, please stop with ur greedy behaviour and let the project ripe.
Thanks for everything, devs.
You are right. Seems some people try to take advantage from this project. No more fun. Thanks for everything, devs.
If there is a foundation there needs to be 4-5 credible people holding 1 part each of a 4-5 part multisig address. This prevents 1 person controlling all , or running away with collected funds, or spending them pointlessly .
voted and nominated for by the community
a constant intention of working towards a solution that removes centralization from the foundation thru automation or network voting , or a mixture of both. so plans for the foundation to become decentralized.
If a thread is made on the elastic forum or somewhere else to hold a nomination process for potential candidates to be in collective control of said foundation , set up the voting like the other matters that have been voted on . we could have the people chosen , a donation address running and a place where they can all discuss stuff. Working towards getting a decent roadmap together for the other stuff that isn't coin core , while at the same time increasing interest and user base by advertising , sorting out social media , articles , websites and other stuff to bring in more skilled coders wishing to help develop the coin core.
This could all be started at least very cheaply. then once we get a foundation in place and have started working towards the first few goals of the roadmap we can then start to perhaps raise funds , let the foundation show the people what they have planned and them working towards something concrete before pouring donations into something that could potentially be a huge leak of cash for little benefit to the coin.
We want to expand our base and increase the overall interest in the project hopefully with a wide net approach we will be able to attract not just investors or designers of websites or ideas of how to use the network , but core coin coders understanding and wishing to advance on what EK has already worked his ass off to get to.
Again to begin with this doesn't require lots of money for the foundation only for those that are voted on to the foundation to put their effort and time into it and pool collective resources together
voted and nominated for by the community
a constant intention of working towards a solution that removes centralization from the foundation thru automation or network voting , or a mixture of both. so plans for the foundation to become decentralized.
If a thread is made on the elastic forum or somewhere else to hold a nomination process for potential candidates to be in collective control of said foundation , set up the voting like the other matters that have been voted on . we could have the people chosen , a donation address running and a place where they can all discuss stuff. Working towards getting a decent roadmap together for the other stuff that isn't coin core , while at the same time increasing interest and user base by advertising , sorting out social media , articles , websites and other stuff to bring in more skilled coders wishing to help develop the coin core.
This could all be started at least very cheaply. then once we get a foundation in place and have started working towards the first few goals of the roadmap we can then start to perhaps raise funds , let the foundation show the people what they have planned and them working towards something concrete before pouring donations into something that could potentially be a huge leak of cash for little benefit to the coin.
We want to expand our base and increase the overall interest in the project hopefully with a wide net approach we will be able to attract not just investors or designers of websites or ideas of how to use the network , but core coin coders understanding and wishing to advance on what EK has already worked his ass off to get to.
Again to begin with this doesn't require lots of money for the foundation only for those that are voted on to the foundation to put their effort and time into it and pool collective resources together
To become a bit more productive, here the new model for the POW submissions.
The Problem:
The problem was, that we need to incentivize miners to work on jobs that have really hard-to-solve bounties. With a too low chance of finding a bounty, there is no real incentive to work on that jobs, except we have so-called POW payments, which occur periodically and pay out small amounts of XEL to the workers.
These POW submissions need to be rate limited so a work author can specify to pay out x XEL / hour - this is what we earlier tried to achieve with the retargeting algorithm. The problem was, that POW submissions were regular transactions. If multiple jobs are live, which require different times to be executed, it was really hard to rate limit them individually. Also, block times are not predictible which makes things even harder. Means: We want that both the long and the short jobs are both limited in a way, that both jobs generate x POW packages per time frame.
The Solution:
We have multiple internal blockchains: every job has its own internal blockchain which consists only of POW blocks. These can be rate limited easily by a KGW or DGW. This is a simple outline of the procedure:
- Work is started
- A new "internal" blockchain for this work is created and POWs are generating blocks in this chain. That is a blockchain that is not visible to the average user, it is just there to throttle the rate at which POWs are generated
- KGW limits block time to 1 min (or whatever value)
- All POW blocks that are already confirmed in the inofficial internal POW-blockchain remain as "unconfirmed transactions" in the real XEL blockchain.
- Once included in a real block, the POW submitters get paid out and the "inofficial" blockchain gets a new "checkpoint" so it can't be forked backwards beyond that point.
First tests show, that we can rate limit multiple jobs with different complexities very precisely to a desired rate per time frame.
Just putting it here, so devs can discuss this and post their own ideas if any obvious flaws are visible to them.
Let's do what can't be done
https://www.youtube.com/watch?v=eUl-kUJoO4w
The Problem:
The problem was, that we need to incentivize miners to work on jobs that have really hard-to-solve bounties. With a too low chance of finding a bounty, there is no real incentive to work on that jobs, except we have so-called POW payments, which occur periodically and pay out small amounts of XEL to the workers.
These POW submissions need to be rate limited so a work author can specify to pay out x XEL / hour - this is what we earlier tried to achieve with the retargeting algorithm. The problem was, that POW submissions were regular transactions. If multiple jobs are live, which require different times to be executed, it was really hard to rate limit them individually. Also, block times are not predictible which makes things even harder. Means: We want that both the long and the short jobs are both limited in a way, that both jobs generate x POW packages per time frame.
The Solution:
We have multiple internal blockchains: every job has its own internal blockchain which consists only of POW blocks. These can be rate limited easily by a KGW or DGW. This is a simple outline of the procedure:
- Work is started
- A new "internal" blockchain for this work is created and POWs are generating blocks in this chain. That is a blockchain that is not visible to the average user, it is just there to throttle the rate at which POWs are generated
- KGW limits block time to 1 min (or whatever value)
- All POW blocks that are already confirmed in the inofficial internal POW-blockchain remain as "unconfirmed transactions" in the real XEL blockchain.
- Once included in a real block, the POW submitters get paid out and the "inofficial" blockchain gets a new "checkpoint" so it can't be forked backwards beyond that point.
First tests show, that we can rate limit multiple jobs with different complexities very precisely to a desired rate per time frame.
Just putting it here, so devs can discuss this and post their own ideas if any obvious flaws are visible to them.
Let's do what can't be done
https://www.youtube.com/watch?v=eUl-kUJoO4w@EK :How miners know they work on jobs that have really hard-to-solve bounties ?
Firstly I will setup a crowd fund raising; Where we at least have to bring in 200 BTC with the community so we establish a strong foundation to pay devs, pr, website and other costs.
200 BTC is not for JUST a website. read it again. forget it, let me bullet point it for you. it is to
* Pay Devs (current and future Devs we might need to help EK)
* PR campaign (publish articles, twitter campaign, BTC sig campaign etc)
* Website (to build professional elastic website, to run elastic forum, elastic reddit & elastic slack)
* Other (Pay listing fees to exchanges like bittrex)
Firstly I will setup a crowd fund raising; Where we at least have to bring in 200 BTC with the community so we establish a strong foundation to pay devs, pr, website and other costs.
200 BTC is not for JUST a website. read it again. forget it, let me bullet point it for you. it is to
* Pay Devs (current and future Devs we might need to help EK)
* PR campaign (publish articles, twitter campaign, BTC sig campaign etc)
* Website (to build professional elastic website, to run elastic forum, elastic reddit & elastic slack)
* Other (Pay listing fees to exchanges like bittrex)
To become a bit more productive, here the new model for the POW submissions.
The Problem:
The problem was, that we need to incentivize miners to work on jobs that have really hard-to-solve bounties. With a too low chance of finding a bounty, there is no real incentive to work on that jobs, except we have so-called POW payments, which occur periodically and pay out small amounts of XEL to the workers.
These POW submissions need to be rate limited so a work author can specify to pay out x XEL / hour - this is what we earlier tried to achieve with the retargeting algorithm. The problem was, that POW submissions were regular transactions. If multiple jobs are live, which require different times to be executed, it was really hard to rate limit them individually. Also, block times are not predictible which makes things even harder. Means: We want that both the long and the short jobs are both limited in a way, that both jobs generate x POW packages per time frame.
The Solution:
We have multiple internal blockchains: every job has its own internal blockchain which consists only of POW blocks. These can be rate limited easily by a KGW or DGW. This is a simple outline of the procedure:
- Work is started
- A new "internal" blockchain for this work is created and POWs are generating blocks in this chain. That is a blockchain that is not visible to the average user, it is just there to throttle the rate at which POWs are generated
- KGW limits block time to 1 min (or whatever value)
- All POW blocks that are already confirmed in the inofficial internal POW-blockchain remain as "unconfirmed transactions" in the real XEL blockchain.
- Once included in a real block, the POW submitters get paid out and the "inofficial" blockchain gets a new "checkpoint" so it can't be forked backwards beyond that point.
First tests show, that we can rate limit multiple jobs with different complexities very precisely to a desired rate per time frame.
Just putting it here, so devs can discuss this and post their own ideas if any obvious flaws are visible to them.
Let's do what can't be done https://www.youtube.com/watch?v=eUl-kUJoO4w
The Problem:
The problem was, that we need to incentivize miners to work on jobs that have really hard-to-solve bounties. With a too low chance of finding a bounty, there is no real incentive to work on that jobs, except we have so-called POW payments, which occur periodically and pay out small amounts of XEL to the workers.
These POW submissions need to be rate limited so a work author can specify to pay out x XEL / hour - this is what we earlier tried to achieve with the retargeting algorithm. The problem was, that POW submissions were regular transactions. If multiple jobs are live, which require different times to be executed, it was really hard to rate limit them individually. Also, block times are not predictible which makes things even harder. Means: We want that both the long and the short jobs are both limited in a way, that both jobs generate x POW packages per time frame.
The Solution:
We have multiple internal blockchains: every job has its own internal blockchain which consists only of POW blocks. These can be rate limited easily by a KGW or DGW. This is a simple outline of the procedure:
- Work is started
- A new "internal" blockchain for this work is created and POWs are generating blocks in this chain. That is a blockchain that is not visible to the average user, it is just there to throttle the rate at which POWs are generated
- KGW limits block time to 1 min (or whatever value)
- All POW blocks that are already confirmed in the inofficial internal POW-blockchain remain as "unconfirmed transactions" in the real XEL blockchain.
- Once included in a real block, the POW submitters get paid out and the "inofficial" blockchain gets a new "checkpoint" so it can't be forked backwards beyond that point.
First tests show, that we can rate limit multiple jobs with different complexities very precisely to a desired rate per time frame.
Just putting it here, so devs can discuss this and post their own ideas if any obvious flaws are visible to them.
Let's do what can't be done
https://www.youtube.com/watch?v=eUl-kUJoO4wEK, I love you <3
Firstly I will setup a crowd fund raising; Where we at least have to bring in 200 BTC with the community so we establish a strong foundation to pay devs, pr, website and other costs.
To become a bit more productive, here the new model for the POW submissions.
The Problem:
The problem was, that we need to incentivize miners to work on jobs that have really hard-to-solve bounties. With a too low chance of finding a bounty, there is no real incentive to work on that jobs, except we have so-called POW payments, which occur periodically and pay out small amounts of XEL to the workers.
These POW submissions need to be rate limited so a work author can specify to pay out x XEL / hour - this is what we earlier tried to achieve with the retargeting algorithm. The problem was, that POW submissions were regular transactions. If multiple jobs are live, which require different times to be executed, it was really hard to rate limit them individually. Also, block times are not predictible which makes things even harder. Means: We want that both the long and the short jobs are both limited in a way, that both jobs generate x POW packages per time frame.
The Solution:
We have multiple internal blockchains: every job has its own internal blockchain which consists only of POW blocks. These can be rate limited easily by a KGW or DGW. This is a simple outline of the procedure:
- Work is started
- A new "internal" blockchain for this work is created and POWs are generating blocks in this chain. That is a blockchain that is not visible to the average user, it is just there to throttle the rate at which POWs are generated
- KGW limits block time to 1 min (or whatever value)
- All POW blocks that are already confirmed in the inofficial internal POW-blockchain remain as "unconfirmed transactions" in the real XEL blockchain.
- Once included in a real block, the POW submitters get paid out and the "inofficial" blockchain gets a new "checkpoint" so it can't be forked backwards beyond that point.
First tests show, that we can rate limit multiple jobs with different complexities very precisely to a desired rate per time frame.
Just putting it here, so devs can discuss this and post their own ideas if any obvious flaws are visible to them.
Let's do what can't be done https://www.youtube.com/watch?v=eUl-kUJoO4w
The Problem:
The problem was, that we need to incentivize miners to work on jobs that have really hard-to-solve bounties. With a too low chance of finding a bounty, there is no real incentive to work on that jobs, except we have so-called POW payments, which occur periodically and pay out small amounts of XEL to the workers.
These POW submissions need to be rate limited so a work author can specify to pay out x XEL / hour - this is what we earlier tried to achieve with the retargeting algorithm. The problem was, that POW submissions were regular transactions. If multiple jobs are live, which require different times to be executed, it was really hard to rate limit them individually. Also, block times are not predictible which makes things even harder. Means: We want that both the long and the short jobs are both limited in a way, that both jobs generate x POW packages per time frame.
The Solution:
We have multiple internal blockchains: every job has its own internal blockchain which consists only of POW blocks. These can be rate limited easily by a KGW or DGW. This is a simple outline of the procedure:
- Work is started
- A new "internal" blockchain for this work is created and POWs are generating blocks in this chain. That is a blockchain that is not visible to the average user, it is just there to throttle the rate at which POWs are generated
- KGW limits block time to 1 min (or whatever value)
- All POW blocks that are already confirmed in the inofficial internal POW-blockchain remain as "unconfirmed transactions" in the real XEL blockchain.
- Once included in a real block, the POW submitters get paid out and the "inofficial" blockchain gets a new "checkpoint" so it can't be forked backwards beyond that point.
First tests show, that we can rate limit multiple jobs with different complexities very precisely to a desired rate per time frame.
Just putting it here, so devs can discuss this and post their own ideas if any obvious flaws are visible to them.
Let's do what can't be done
https://www.youtube.com/watch?v=eUl-kUJoO4wEK, you are a true champion! It is inspiring to see your dedication and your work, and it is my great honor to be part of this amazing community with this amazing project.
I thank you deeply and sincerely!
Jump to: