[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[nightwishx]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

The relatively perfect elastic needs to wait for how long?

[1713872243]

1713872243

[1713872243]

1713872243

[1713872243]

1713872243

[1713872243]

1713872243

[mr.coinzy]

What the hell is this??? you are going on with lite client launch without making even a vote on it by the community and making proper consult with EK?
Negligent idiotic douchebags!

[Evil-Knievel]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

The relatively perfect elastic needs to wait for how long?

This is hard to say! Every testnet iteration started with the thought "this might be it", then experienced some bugs and some more ideas how to improve little less-perfect things that should be improved, and ended with a TODO list. Then, after implementing everything from the TODO list, the whole process started over, leading to new observations and new bugs. I don't think that we have that many open points at this point, but there are some and as we know from the past ... new TODO lists will come for sure.

No idea how to estimate how many iterations we need until everything works as we all want it. Maybe 10, maybe 15. Sometimes new testnets can be rolled out within one day, sometimes they need 3 or 4. But hell, if a task is tough that it might take a week as well.

[mr.coinzy]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

I'm sure the entire community would love to see an EK-approved lite-version. I'm not sure who has the control over the master repo, but I'm sure you have a big hand in what actually gets pulled in, as you should.

I personally think we should just list the coin on the exchange without a lite-version of the elastic functionality. If we give them everything at once, and then have even a minor hiccup, expectations were already set too high. I think a coin, then a polished/tested lite version, and that's as far in the future as we even need to think right now.

The fact that you think so doesn't mean can should just go with it and give a big fat F you in the face of everyone else who invested in this project. That is why there is a voting system and the community took decisions together. If the majority of the holders want to go with a lite client it will be done.

[by rallier]

What the hell is this??? you are going on with lite client launch without making even a vote on it by the community and making proper consult with EK?
Negligent idiotic douchebags!

1. We can arrange voting no problem with that
2. Ek said a lot of months ago, he won't  launch elastic. He left to us for launch mainnet.
3. We didn't launch mainnet just we are working & trying and prepare to next step

So, we are working for mainnet. It's good process. A lot of people want to part of elastic community we need to reach more people

BTW @EK can you help stable lite functionality wallet? I created lite branch on XEL repo. You can create too.

[techwriterjoe]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

I'm sure the entire community would love to see an EK-approved lite-version. I'm not sure who has the control over the master repo, but I'm sure you have a big hand in what actually gets pulled in, as you should.

I personally think we should just list the coin on the exchange without a lite-version of the elastic functionality. If we give them everything at once, and then have even a minor hiccup, expectations were already set too high. I think a coin, then a polished/tested lite version, and that's as far in the future as we even need to think right now.

The fact that you think so doesn't mean can should just go with it and give a big fat F you in the face of everyone else who invested in this project. That is why there is a voting system and the community took decisions together. If the majority of the holders want to go with a lite client it will be done.

I thought we were voting??

You are putting a lot of words in my mouth that I never said.
I am voicing my opinion as part of the community. It's an open source project. I think a vote is the best way to decide.

[mr.coinzy]

What the hell is this??? you are going on with lite client launch without making even a vote on it by the community and making proper consult with EK?
Negligent idiotic douchebags!

1. We can arrange voting no problem with that
2. Ek said a lot of months ago, he won't  launch elastic. He left to us for launch mainnet.
3. We didn't launch mainnet just we are working & trying and prepare to next step

So, we are working mainnet. It's good process.

BTW @EK can you help stable lite functionality wallet? I created lite branch on XEL repo. You can create too

And will you hold your horses and wait if the majority of the holders decide to wait for an MVP for the mainnet release?
I think that before EK works on getting a lite client for launch, this should be voted on so no time is wasted on a decision that is not taken.

[nightwishx]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

The relatively perfect elastic needs to wait for how long?

This is hard to say! Every testnet iteration started with the thought "this might be it", then experienced some bugs and some more ideas how to improve little less-perfect things that should be improved, and ended with a TODO list. Then, after implementing everything from the TODO list, the whole process started over, leading to new observations and new bugs. I don't think that we have that many open points at this point, but there are some and as we know from the past ... new TODO lists will come for sure.

No idea how to estimate how many iterations we need until everything works as we all want it. Maybe 10, maybe 15. Sometimes new testnets can be rolled out within one day, sometimes they need 3 or 4. But hell, if a task is tough that it might take a week as well.

Very thank you for your hard work!
I will to save the polar bears.

[techwriterjoe]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

The relatively perfect elastic needs to wait for how long?

This is hard to say! Every testnet iteration started with the thought "this might be it", then experienced some bugs and some more ideas how to improve little less-perfect things that should be improved, and ended with a TODO list. Then, after implementing everything from the TODO list, the whole process started over, leading to new observations and new bugs. I don't think that we have that many open points at this point, but there are some and as we know from the past ... new TODO lists will come for sure.

No idea how to estimate how many iterations we need until everything works as we all want it. Maybe 10, maybe 15. Sometimes new testnets can be rolled out within one day, sometimes they need 3 or 4. But hell, if a task is tough that it might take a week as well.

Are we at a place where we can freeze any new feature work?

In corporate environments, usually there is a code freeze. Bugs that are a necessity to be fixed get fixed. Everybody chills for about a week or two, then a release. After the release there is a small party, then the next version begins.

[mr.coinzy]

EK - can you please share what you would include as mandatory functionalities if we where to release an MVP before a full client?
Also, what would be your estimation regarding time frames for such release? where are we standing now in regard to such a client?
Your voice is highly needed.

[techwriterjoe]

techwriterjoe: I meant that if you take an unfinished code base with fixes and patches being continuously checked in to try them out trial-and-error-style and just flip out "testnet=true" by "testnet=false", I can guarantee you that the whole thing fails within 1 minute.

I can help getting the "lite functionality" working in a stable branch, but that is at least a week of work.

The relatively perfect elastic needs to wait for how long?

This is hard to say! Every testnet iteration started with the thought "this might be it", then experienced some bugs and some more ideas how to improve little less-perfect things that should be improved, and ended with a TODO list. Then, after implementing everything from the TODO list, the whole process started over, leading to new observations and new bugs. I don't think that we have that many open points at this point, but there are some and as we know from the past ... new TODO lists will come for sure.

No idea how to estimate how many iterations we need until everything works as we all want it. Maybe 10, maybe 15. Sometimes new testnets can be rolled out within one day, sometimes they need 3 or 4. But hell, if a task is tough that it might take a week as well.

Are we at a place where we can freeze any new feature work?

In corporate environments, usually there is a code freeze. Bugs that are a necessity to be fixed get fixed. Everybody chills for about a week or two, then a release. After the release there is a small party, then the next version begins.

To be clear, I am detailing our options, so that they can be put to a vote. I am not saying do this and only this right now.

[nightwishx]

What the hell is this??? you are going on with lite client launch without making even a vote on it by the community and making proper consult with EK?
Negligent idiotic douchebags!

1. We can arrange voting no problem with that
2. Ek said a lot of months ago, he won't  launch elastic. He left to us for launch mainnet.
3. We didn't launch mainnet just we are working & trying and prepare to next step

So, we are working for mainnet. It's good process. A lot of people want to part of elastic community we need to reach more people

BTW @EK can you help stable lite functionality wallet? I created lite branch on XEL repo. You can create too.

You didn't do wrong, just hurry. IMO

[Evil-Knievel]

EK - can you please share what you would include as mandatory functionalities if we where to release an MVP before a full client?
Also, what would be your estimation regarding time frames for such release? where are we standing now in regard to such a client?
Your voice is highly needed.

From what I see, this is the current open points list:

- UI sucks. It must be redesigned to support all new features. Probably a weekend task.
- We need a decision what to do with our PoW payments. Bounties only means that people only earn XEL if they find a bounty (a solution to the task). This may be frustrating for jobs that have really hard-to-find bounties. I mean, the miner-software will evolve and people can configure "preferences" and start skipping jobs with too-long-to-get bounties and move to other jobs, but this still does not mean a guaranteed steady payout. Remember: the steady payout (the PoW payments) were originally meant to keep "miners" around and not let them give up working towards a bounty that quick.
- If we keep the PoW, we need a new scaling concept. The PoW retargeting mechanism works far from good at the moment - even though there way a multi-BTC contest for the best retargeting algorithm a few months ago. This is the most challenging think I guess.
- We need to make the supernode software super stable
- We need to think about the unsigned / signed integer problem that was identified lately in the ElasticPL parser/VM. Hopefully coralreefer could assist here. My "quick and dirty fix" is ... well ... "quick and dirty".
- We need to write test cases for all possible attacks that one might think of.

This is the minimum that is needed, I'd say.

[coralreefer]

- We need to think about the unsigned / signed integer problem that was identified lately in the ElasticPL parser/VM. Hopefully coralreefer could assist here. My "quick and dirty fix" is ... well ... "quick and dirty".

I will help out with this in order to keep things moving along.  But like everything in "Elastic" there are various solutions with varying levels of complexity.  I know how I'd like to fix it, but it would take a major rewrite of the vm memory model...and that is what I want to avoid right now.  But at least all ElasticPL logic is housed in the miner code so maybe it can be released in phases without impacting the core server.

EK, please send me the details of what the original problem was that you encountered (I think I have an idea of what it was), but I'd like to make sure I fully understand it.

[LaBlanj]

EK - can you please share what you would include as mandatory functionalities if we where to release an MVP before a full client?
Also, what would be your estimation regarding time frames for such release? where are we standing now in regard to such a client?
Your voice is highly needed.

From what I see, this is the current open points list:

- UI sucks. It must be redesigned to support all new features. Probably a weekend task.
- We need a decision what to do with our PoW payments. Bounties only means that people only earn XEL if they find a bounty (a solution to the task). This may be frustrating for jobs that have really hard-to-find bounties. I mean, the miner-software will evolve and people can configure "preferences" and start skipping jobs with too-long-to-get bounties and move to other jobs, but this still does not mean a guaranteed steady payout. Remember: the steady payout (the PoW payments) were originally meant to keep "miners" around and not let them give up working towards a bounty that quick.
- If we keep the PoW, we need a new scaling concept. The PoW retargeting mechanism works far from good at the moment - even though there way a multi-BTC contest for the best retargeting algorithm a few months ago. This is the most challenging think I guess.
- We need to make the supernode software super stable
- We need to think about the unsigned / signed integer problem that was identified lately in the ElasticPL parser/VM. Hopefully coralreefer could assist here. My "quick and dirty fix" is ... well ... "quick and dirty".
- We need to write test cases for all possible attacks that one might think of.

This is the minimum that is needed, I'd say.

too many works... approximate mainnet release date will be August, imo

[Soul_eater_123]

What the hell is this??? you are going on with lite client launch without making even a vote on it by the community and making proper consult with EK?
Negligent idiotic douchebags!

Seems to me these people are so eager to get in on the current altcoin pump that they have lost their senses. If it were up to me I would allow EK to proceed as he sees best.  If you want to get in on playing markets and pumping and dumping there are plenty of coins to choose from.  If you really want to help with raising funds contribute some bitcoins to help - if I had some to spare right now I would donate in a heartbeat.

A functioning product that works would be something completely new in cryptoland when it comes to app based cryptocurrency - we would be the first and that would give us a lot more momentum and attention than going the usual route of releasing a wallet with nothing behind it.

You either break the mould or you are like everyone else.

Anyway you all do what you like. 

[nightwishx]

EK - can you please share what you would include as mandatory functionalities if we where to release an MVP before a full client?
Also, what would be your estimation regarding time frames for such release? where are we standing now in regard to such a client?
Your voice is highly needed.

From what I see, this is the current open points list:

- UI sucks. It must be redesigned to support all new features. Probably a weekend task.
- We need a decision what to do with our PoW payments. Bounties only means that people only earn XEL if they find a bounty (a solution to the task). This may be frustrating for jobs that have really hard-to-find bounties. I mean, the miner-software will evolve and people can configure "preferences" and start skipping jobs with too-long-to-get bounties and move to other jobs, but this still does not mean a guaranteed steady payout. Remember: the steady payout (the PoW payments) were originally meant to keep "miners" around and not let them give up working towards a bounty that quick.
- If we keep the PoW, we need a new scaling concept. The PoW retargeting mechanism works far from good at the moment - even though there way a multi-BTC contest for the best retargeting algorithm a few months ago. This is the most challenging think I guess.
- We need to make the supernode software super stable
- We need to think about the unsigned / signed integer problem that was identified lately in the ElasticPL parser/VM. Hopefully coralreefer could assist here. My "quick and dirty fix" is ... well ... "quick and dirty".
- We need to write test cases for all possible attacks that one might think of.

This is the minimum that is needed, I'd say.

POW payments bounty，1G hash=XX xel/day,Set a minimum pay limitation.Dynamic price,Fixed price.  e.g nicehash
What do you think?

[cryptodv]

Technically the funds were donations, and nothing was really promised. So the devs can do what they please, which I think is wait until the project is finished to launch, but I'm not in need to dump any of my XEL. Others may for personal reasons.  

[techwriterjoe]

Technically the funds were donations, and nothing was really promised. So the devs can do what they please, which I think is wait until the project is finished to launch, but I'm not in need to dump any of my XEL. Others may for personal reasons.  

I have no need for a timeline. Someone mentioned August, that sounds about right. Doesn't matter to me.

Talking about the next steps of a project is not the same as setting deadlines. Dates are a joke in software.

I think it is awesome that EK put an MVP list out there. Now the community has a really good idea where it can/should be helping right now.

[cybterpunk]

i think a voting is good solution for sure.