Today open the trade.
https://eichain.com
Topic: [ANN] [XEL] :: XEL - The Decentralized Supercomputer :: - page 105. (Read 253604 times)
China people now can buy xel in new china exchange market.
Today open the trade.
https://eichain.com
Today open the trade.
https://eichain.com
I bought the ICO last year total 8 btc and sold OTC for 25k sats and now I bought all my XEL again 
Excellent. :-)
@IMI can we link to this on the front page of this thread?
At the beginning of the year Stratis came out as a great force, as Elastic is at the moment and I didn't buy some Stratis because I thought it was too soon and suddenly things happened and I missed the big train... I'll not let it happen again , I started Elastic shopping.
True, I'm a Stratis ico holder. Never sold. I have invested in two ico's Stratis and Elastic for long term last year. Always believe in tech not the hype and hold long term not for short gains. Both Stratis and Elastic haven't reached their full potential. So wait for that as it may take more 1-2 yrs.
You have good insight. Patience is bitter but its fruit is sweet.
At the beginning of the year Stratis came out as a great force, as Elastic is at the moment and I didn't buy some Stratis because I thought it was too soon and suddenly things happened and I missed the big train... I'll not let it happen again , I started Elastic shopping.
True, I'm a Stratis ico holder. Never sold. I have invested in two ico's Stratis and Elastic for long term last year. Always believe in tech not the hype and hold long term not for short gains. Both Stratis and Elastic haven't reached their full potential. So wait for that as it may take more 1-2 yrs.
Agreed, this is a good time to jump in while the price still below 10k satoshi
True I have picked up a few to trade with and to fund projects.
Nice to see Elastic keep moving forward in development, slow but sure.
Agreed, this is a good time to jump in while the price still below 10k satoshi
At the beginning of the year Stratis came out as a great force, as Elastic is at the moment and I didn't buy some Stratis because I thought it was too soon and suddenly things happened and I missed the big train... I'll not let it happen again , I started Elastic shopping.
Agreed, this is a good time to jump in while the price still below 10k satoshi
looking promising (devs working hard)
price is still very low imo
price is still very low imo
Just to give a small update on what we are currently working on:
Preface:
The current approach has totally disconnected the verification of work from the remaining verification routines (which are required to verify the consensus critical PoS operations). The reason for this approach were on the one hand some concerns, that people were feeling unsafe to execute "untrusted" code. On the other hand, the verification on each node would limit the amount of time a work-task may run: imagine, that a pretty complex job is on the network which takes around 5 minutes to execute. If miners work 5 minutes on it, everything is just fine. But if every node needs 5 minutes to verify the solution, it wouldn't take long until the entire network stalls.
So the solution was to use "super nodes" which do this complex verification stuff. Super nodes were meant to be super-efficient very fast computers capable of doing many many verification if a very short time. However, and you all are right, this means centralization and "blind trust". But in fact, a decentralized system is what we want.
Codebase:
Supernodes were working fine (see PoC from a few months ago) and they were using the native xel_miner application (written in C) to do the verification. Xel_miner was not only encapsulating the entire mining logic but also provided an API for super nodes, which could enqueue the transactions seen on the XEL network and semlessly receive the verification result for further processing.
Goal:
We worked out a different (asymetric) verification method. This clearly limits the use cases to some extent but on the other hand it vastly increases the integrity of the entire blockchain.
The asymetric verification will allow us to code arbitrarily complex ElasticPL programs (they may run for hours) and define separate, much less complex verification functions (which finish in a blick of an eye). Verifcation routines must be coded very carefully (to avoid unwanted "trapdoor" solutions which do not reflect what we actually want) but there will be a developers guide sooner or later.
Now, this scheme allows us to move the verification back into the java code base and again perform the verification on all nodes. (All is not strictly correct, as you will learn in the next point). This way, we drop any super nodes and guard nodes, and avoid any kind of centralization at all.
Work should not be consensus critical:
In an early version of Elastic (way before the super node proof-of-concept) work transactions were regular transactions and were consensus critical. Probably everyone of those who followed the progress remember the chain forks due to some unforseeable error (differencies in floating point operations on different platforms could lead to a hard fork ... yes).
We do not want this, so we:
1. Do not model the work communication as actual transactions but as binary messages transmitted over the Elastic messaging system.
2. Only do work processing when a "work=true" flag is set in the config. If you do not want to participate in any working activity, you can leave this feature off and you will not participate in any verification whatsoever (good for those who do not trust any code). But if you decide to turn it on later on, you can just catch up by synching all new "unparsed" messages of this kind. This is possible, because the "sort-of parallel chain encoded in those binary messages" and the actual blockchain do not need to be in sync at any point. Well, let's not become too technical here!
The cool thing is: If something goes wrong with one work package, other work packages and, even more important, the entire blockchain remains unaffected by it. How the work-payments will be modelled in this "unconventional approach" will be revealed at a later point in time :wink:
Now comes the actual task:
And now comes the task, which causes so much work at the moment and which eats up every free second that we have: We have to port the C ElasticPL to JAVA ElasticPL - in a way, that both work in the same way, in all cases on all platforms.
I am half way through (all of it was done in the last week alone - it's been "burnout-ish"):
github.com20
OrdinaryDude/ElasticPLJava
Contribute to ElasticPLJava development by creating an account on GitHub.
What is there is the Tokenizing (splitting up code into tokens) and the construction of the Abstract Syntax Tree.
This was pretty hard - and this basically defines the entire ElasticPL language. What is still missing is the interpreter, and this is what I will be doing next.
If someone wants to play around, just open the project linked above in IntelliJ Idea and launch it. You will not see much, but those of you, who really want to dig into it, will quickly find out how to verify that the AST tree is actually built correctly. Also: feel free to report any bugs or any inconsistencies between the C and the Java version.
Disclosure: I currently do hold XEL coins.
Preface:
The current approach has totally disconnected the verification of work from the remaining verification routines (which are required to verify the consensus critical PoS operations). The reason for this approach were on the one hand some concerns, that people were feeling unsafe to execute "untrusted" code. On the other hand, the verification on each node would limit the amount of time a work-task may run: imagine, that a pretty complex job is on the network which takes around 5 minutes to execute. If miners work 5 minutes on it, everything is just fine. But if every node needs 5 minutes to verify the solution, it wouldn't take long until the entire network stalls.
So the solution was to use "super nodes" which do this complex verification stuff. Super nodes were meant to be super-efficient very fast computers capable of doing many many verification if a very short time. However, and you all are right, this means centralization and "blind trust". But in fact, a decentralized system is what we want.
Codebase:
Supernodes were working fine (see PoC from a few months ago) and they were using the native xel_miner application (written in C) to do the verification. Xel_miner was not only encapsulating the entire mining logic but also provided an API for super nodes, which could enqueue the transactions seen on the XEL network and semlessly receive the verification result for further processing.
Goal:
We worked out a different (asymetric) verification method. This clearly limits the use cases to some extent but on the other hand it vastly increases the integrity of the entire blockchain.
The asymetric verification will allow us to code arbitrarily complex ElasticPL programs (they may run for hours) and define separate, much less complex verification functions (which finish in a blick of an eye). Verifcation routines must be coded very carefully (to avoid unwanted "trapdoor" solutions which do not reflect what we actually want) but there will be a developers guide sooner or later.
Now, this scheme allows us to move the verification back into the java code base and again perform the verification on all nodes. (All is not strictly correct, as you will learn in the next point). This way, we drop any super nodes and guard nodes, and avoid any kind of centralization at all.
Work should not be consensus critical:
In an early version of Elastic (way before the super node proof-of-concept) work transactions were regular transactions and were consensus critical. Probably everyone of those who followed the progress remember the chain forks due to some unforseeable error (differencies in floating point operations on different platforms could lead to a hard fork ... yes).
We do not want this, so we:
1. Do not model the work communication as actual transactions but as binary messages transmitted over the Elastic messaging system.
2. Only do work processing when a "work=true" flag is set in the config. If you do not want to participate in any working activity, you can leave this feature off and you will not participate in any verification whatsoever (good for those who do not trust any code). But if you decide to turn it on later on, you can just catch up by synching all new "unparsed" messages of this kind. This is possible, because the "sort-of parallel chain encoded in those binary messages" and the actual blockchain do not need to be in sync at any point. Well, let's not become too technical here!
The cool thing is: If something goes wrong with one work package, other work packages and, even more important, the entire blockchain remains unaffected by it. How the work-payments will be modelled in this "unconventional approach" will be revealed at a later point in time :wink:
Now comes the actual task:
And now comes the task, which causes so much work at the moment and which eats up every free second that we have: We have to port the C ElasticPL to JAVA ElasticPL - in a way, that both work in the same way, in all cases on all platforms.
I am half way through (all of it was done in the last week alone - it's been "burnout-ish"):
github.com20
OrdinaryDude/ElasticPLJava
Contribute to ElasticPLJava development by creating an account on GitHub.
What is there is the Tokenizing (splitting up code into tokens) and the construction of the Abstract Syntax Tree.
This was pretty hard - and this basically defines the entire ElasticPL language. What is still missing is the interpreter, and this is what I will be doing next.
If someone wants to play around, just open the project linked above in IntelliJ Idea and launch it. You will not see much, but those of you, who really want to dig into it, will quickly find out how to verify that the AST tree is actually built correctly. Also: feel free to report any bugs or any inconsistencies between the C and the Java version.
Disclosure: I currently do hold XEL coins.
When you Quote someone or post something that has been posted by someone else before, please make sure you give the credit due to the original person who actually made the post. This was EK's update and should be referred to as such. Thanks.
anyone has an idea how much you can make forging for example 1000 xel?
Just to give a small update on what we are currently working on:
Preface:
The current approach has totally disconnected the verification of work from the remaining verification routines (which are required to verify the consensus critical PoS operations). The reason for this approach were on the one hand some concerns, that people were feeling unsafe to execute "untrusted" code. On the other hand, the verification on each node would limit the amount of time a work-task may run: imagine, that a pretty complex job is on the network which takes around 5 minutes to execute. If miners work 5 minutes on it, everything is just fine. But if every node needs 5 minutes to verify the solution, it wouldn't take long until the entire network stalls.
So the solution was to use "super nodes" which do this complex verification stuff. Super nodes were meant to be super-efficient very fast computers capable of doing many many verification if a very short time. However, and you all are right, this means centralization and "blind trust". But in fact, a decentralized system is what we want.
Codebase:
Supernodes were working fine (see PoC from a few months ago) and they were using the native xel_miner application (written in C) to do the verification. Xel_miner was not only encapsulating the entire mining logic but also provided an API for super nodes, which could enqueue the transactions seen on the XEL network and semlessly receive the verification result for further processing.
Goal:
We worked out a different (asymetric) verification method. This clearly limits the use cases to some extent but on the other hand it vastly increases the integrity of the entire blockchain.
The asymetric verification will allow us to code arbitrarily complex ElasticPL programs (they may run for hours) and define separate, much less complex verification functions (which finish in a blick of an eye). Verifcation routines must be coded very carefully (to avoid unwanted "trapdoor" solutions which do not reflect what we actually want) but there will be a developers guide sooner or later.
Now, this scheme allows us to move the verification back into the java code base and again perform the verification on all nodes. (All is not strictly correct, as you will learn in the next point). This way, we drop any super nodes and guard nodes, and avoid any kind of centralization at all.
Work should not be consensus critical:
In an early version of Elastic (way before the super node proof-of-concept) work transactions were regular transactions and were consensus critical. Probably everyone of those who followed the progress remember the chain forks due to some unforseeable error (differencies in floating point operations on different platforms could lead to a hard fork ... yes).
We do not want this, so we:
1. Do not model the work communication as actual transactions but as binary messages transmitted over the Elastic messaging system.
2. Only do work processing when a "work=true" flag is set in the config. If you do not want to participate in any working activity, you can leave this feature off and you will not participate in any verification whatsoever (good for those who do not trust any code). But if you decide to turn it on later on, you can just catch up by synching all new "unparsed" messages of this kind. This is possible, because the "sort-of parallel chain encoded in those binary messages" and the actual blockchain do not need to be in sync at any point. Well, let's not become too technical here!
The cool thing is: If something goes wrong with one work package, other work packages and, even more important, the entire blockchain remains unaffected by it. How the work-payments will be modelled in this "unconventional approach" will be revealed at a later point in time :wink:
Now comes the actual task:
And now comes the task, which causes so much work at the moment and which eats up every free second that we have: We have to port the C ElasticPL to JAVA ElasticPL - in a way, that both work in the same way, in all cases on all platforms.
I am half way through (all of it was done in the last week alone - it's been "burnout-ish"):
github.com20
OrdinaryDude/ElasticPLJava
Contribute to ElasticPLJava development by creating an account on GitHub.
What is there is the Tokenizing (splitting up code into tokens) and the construction of the Abstract Syntax Tree.
This was pretty hard - and this basically defines the entire ElasticPL language. What is still missing is the interpreter, and this is what I will be doing next.
If someone wants to play around, just open the project linked above in IntelliJ Idea and launch it. You will not see much, but those of you, who really want to dig into it, will quickly find out how to verify that the AST tree is actually built correctly. Also: feel free to report any bugs or any inconsistencies between the C and the Java version.
Disclosure: I currently do hold XEL coins.
Preface:
The current approach has totally disconnected the verification of work from the remaining verification routines (which are required to verify the consensus critical PoS operations). The reason for this approach were on the one hand some concerns, that people were feeling unsafe to execute "untrusted" code. On the other hand, the verification on each node would limit the amount of time a work-task may run: imagine, that a pretty complex job is on the network which takes around 5 minutes to execute. If miners work 5 minutes on it, everything is just fine. But if every node needs 5 minutes to verify the solution, it wouldn't take long until the entire network stalls.
So the solution was to use "super nodes" which do this complex verification stuff. Super nodes were meant to be super-efficient very fast computers capable of doing many many verification if a very short time. However, and you all are right, this means centralization and "blind trust". But in fact, a decentralized system is what we want.
Codebase:
Supernodes were working fine (see PoC from a few months ago) and they were using the native xel_miner application (written in C) to do the verification. Xel_miner was not only encapsulating the entire mining logic but also provided an API for super nodes, which could enqueue the transactions seen on the XEL network and semlessly receive the verification result for further processing.
Goal:
We worked out a different (asymetric) verification method. This clearly limits the use cases to some extent but on the other hand it vastly increases the integrity of the entire blockchain.
The asymetric verification will allow us to code arbitrarily complex ElasticPL programs (they may run for hours) and define separate, much less complex verification functions (which finish in a blick of an eye). Verifcation routines must be coded very carefully (to avoid unwanted "trapdoor" solutions which do not reflect what we actually want) but there will be a developers guide sooner or later.
Now, this scheme allows us to move the verification back into the java code base and again perform the verification on all nodes. (All is not strictly correct, as you will learn in the next point). This way, we drop any super nodes and guard nodes, and avoid any kind of centralization at all.
Work should not be consensus critical:
In an early version of Elastic (way before the super node proof-of-concept) work transactions were regular transactions and were consensus critical. Probably everyone of those who followed the progress remember the chain forks due to some unforseeable error (differencies in floating point operations on different platforms could lead to a hard fork ... yes).
We do not want this, so we:
1. Do not model the work communication as actual transactions but as binary messages transmitted over the Elastic messaging system.
2. Only do work processing when a "work=true" flag is set in the config. If you do not want to participate in any working activity, you can leave this feature off and you will not participate in any verification whatsoever (good for those who do not trust any code). But if you decide to turn it on later on, you can just catch up by synching all new "unparsed" messages of this kind. This is possible, because the "sort-of parallel chain encoded in those binary messages" and the actual blockchain do not need to be in sync at any point. Well, let's not become too technical here!
The cool thing is: If something goes wrong with one work package, other work packages and, even more important, the entire blockchain remains unaffected by it. How the work-payments will be modelled in this "unconventional approach" will be revealed at a later point in time :wink:
Now comes the actual task:
And now comes the task, which causes so much work at the moment and which eats up every free second that we have: We have to port the C ElasticPL to JAVA ElasticPL - in a way, that both work in the same way, in all cases on all platforms.
I am half way through (all of it was done in the last week alone - it's been "burnout-ish"):
github.com20
OrdinaryDude/ElasticPLJava
Contribute to ElasticPLJava development by creating an account on GitHub.
What is there is the Tokenizing (splitting up code into tokens) and the construction of the Abstract Syntax Tree.
This was pretty hard - and this basically defines the entire ElasticPL language. What is still missing is the interpreter, and this is what I will be doing next.
If someone wants to play around, just open the project linked above in IntelliJ Idea and launch it. You will not see much, but those of you, who really want to dig into it, will quickly find out how to verify that the AST tree is actually built correctly. Also: feel free to report any bugs or any inconsistencies between the C and the Java version.
Disclosure: I currently do hold XEL coins.
Project status update from EK:
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
Xel right on target.
This is great news indeed!!
I think this is a really good direction to be taking the project in and I am excited to see how it evolves further from here. still one of the most promising projects of 2017!
To help promote Elastic on youtube I am setting up a Raspberry Pi 3 1.2GHz 64bit (Model B) giveaway!!
What do you need to do? Make a video showing (step by step) instructions on how to setup an Elastic node on Raspberry PI and get a Raspberry Pi 3 shipped direct to your home for FREE!! This offer is available to anyone in the world but language should be in English.
**There are THREE Raspberry Pi 3 1.2GHz 64bit (Model B) up for grabs. First come first serve basis. Completed video file must be shared to me so it can be uploaded on youtube to further promote awareness of Elastic.**
You can find out more about the Raspberry Pi 3 here:
https://www.eyeboot.com/raspberry-pi.html
If you are interested then please post a reply here in the thread topic of elastictalk:
https://talk.elasticexplorer.org/t/raspberry-pi-3-1-2ghz-64bit-model-b-giveaway/
Project status update from EK:
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
Xel right on target.
Patience as they continue to develop XEL. I bet it will get added to more exchanges within the next few months. Meanwhile, I'm accumulating my bag on Trex for the time being. Long term holder here.
The switching of the code base is certainly interesting.
The switching of the code base is certainly interesting.
I enjoying what i read from your insight and from checking other onlien sources for this coin/project. I have bought a good amt since market all crashed last week and hope to see it rise big for value/price and tech in coming months and into 2018. No reason this one shouldn't fly to moon!
Project status update from EK:
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
Just to give a small update on what we are currently working on:
Preface:
The current approach has totally disconnected the verification of work from the remaining verification routines (which are required to verify the consensus critical PoS operations). The reason for this approach were on the one hand some concerns, that people were feeling unsafe to execute "untrusted" code. On the other hand, the verification on each node would limit the amount of time a work-task may run: imagine, that a pretty complex job is on the network which takes around 5 minutes to execute. If miners work 5 minutes on it, everything is just fine. But if every node needs 5 minutes to verify the solution, it wouldn't take long until the entire network stalls.
So the solution was to use "super nodes" which do this complex verification stuff. Super nodes were meant to be super-efficient very fast computers capable of doing many many verification if a very short time. However, and you all are right, this means centralization and "blind trust". But in fact, a decentralized system is what we want.
Codebase:
Supernodes were working fine (see PoC from a few months ago) and they were using the native xel_miner application (written in C) to do the verification. Xel_miner was not only encapsulating the entire mining logic but also provided an API for super nodes, which could enqueue the transactions seen on the XEL network and semlessly receive the verification result for further processing.
Goal:
We worked out a different (asymetric) verification method. This clearly limits the use cases to some extent but on the other hand it vastly increases the integrity of the entire blockchain.
The asymetric verification will allow us to code arbitrarily complex ElasticPL programs (they may run for hours) and define separate, much less complex verification functions (which finish in a blick of an eye). Verifcation routines must be coded very carefully (to avoid unwanted "trapdoor" solutions which do not reflect what we actually want) but there will be a developers guide sooner or later.
Now, this scheme allows us to move the verification back into the java code base and again perform the verification on all nodes. (All is not strictly correct, as you will learn in the next point). This way, we drop any super nodes and guard nodes, and avoid any kind of centralization at all.
Work should not be consensus critical:
In an early version of Elastic (way before the super node proof-of-concept) work transactions were regular transactions and were consensus critical. Probably everyone of those who followed the progress remember the chain forks due to some unforseeable error (differencies in floating point operations on different platforms could lead to a hard fork ... yes).
We do not want this, so we:
1. Do not model the work communication as actual transactions but as binary messages transmitted over the Elastic messaging system.
2. Only do work processing when a "work=true" flag is set in the config. If you do not want to participate in any working activity, you can leave this feature off and you will not participate in any verification whatsoever (good for those who do not trust any code). But if you decide to turn it on later on, you can just catch up by synching all new "unparsed" messages of this kind. This is possible, because the "sort-of parallel chain encoded in those binary messages" and the actual blockchain do not need to be in sync at any point. Well, let's not become too technical here!
The cool thing is: If something goes wrong with one work package, other work packages and, even more important, the entire blockchain remains unaffected by it. How the work-payments will be modelled in this "unconventional approach" will be revealed at a later point in time :wink:
Now comes the actual task:
And now comes the task, which causes so much work at the moment and which eats up every free second that we have: We have to port the C ElasticPL to JAVA ElasticPL - in a way, that both work in the same way, in all cases on all platforms.
I am half way through (all of it was done in the last week alone - it's been "burnout-ish"):
ElasticPL Java
What is there is the Tokenizing (splitting up code into tokens) and the construction of the Abstract Syntax Tree.
This was pretty hard - and this basically defines the entire ElasticPL language. What is still missing is the interpreter, and this is what I will be doing next.
If someone wants to play around, just open the project linked above in IntelliJ Idea and launch it. You will not see much, but those of you, who really want to dig into it, will quickly find out how to verify that the AST tree is actually built correctly. Also: feel free to report any bugs or any inconsistencies between the C and the Java version.
Disclosure: I currently do hold XEL coins.
Project status update from EK:
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
https://talk.elasticexplorer.org/t/status-update-porting-elasticpl-c-to-elasticpl-java/799
Hi all,
Just an invitation to take a look at the thread on the XEL forums with regards to setting up a fund to award for use cases as well as towards scientific/non-profit endeavours:
https://talk.elasticexplorer.org/t/competition-to-develop-example-use-cases-promote-xel/769/16?u=ikaros
Please participate in the discussion at this could be a really valuable investment of time and to give XEL some real usage in the real world.
Just an invitation to take a look at the thread on the XEL forums with regards to setting up a fund to award for use cases as well as towards scientific/non-profit endeavours:
https://talk.elasticexplorer.org/t/competition-to-develop-example-use-cases-promote-xel/769/16?u=ikaros
Quote
I was thinking it might be useful to have a competition to develop sample use cases for the platform.
This could initially be just to brainstorm ideas but could involve later rounds that evolve into actual functional development.
We could run it via social media (e.g. Twitter) and I could do a post on my Steemit blog (there are a lot of students and university people on there). Sometimes when you create a product having examples of how people can use it is helpful - people may even be unaware it is useful for them.
I was thinking of putting aside a 2000 XEL prize for this (other people can add to this too).
The thing is XEL isn't worth a lot or well known right now so a bitcoin based prize may be more enticing.
Not only would it be great advertising and promotion in itself but it could also bring in new developers to help EK and CoralReefer.
One further thing that I was thinking of, would be to approach various respected people in the field - e.g. distributed computation (and also cryptocurrency) in an advisory role.
What do others think?
This could initially be just to brainstorm ideas but could involve later rounds that evolve into actual functional development.
We could run it via social media (e.g. Twitter) and I could do a post on my Steemit blog (there are a lot of students and university people on there). Sometimes when you create a product having examples of how people can use it is helpful - people may even be unaware it is useful for them.
I was thinking of putting aside a 2000 XEL prize for this (other people can add to this too).
The thing is XEL isn't worth a lot or well known right now so a bitcoin based prize may be more enticing.
Not only would it be great advertising and promotion in itself but it could also bring in new developers to help EK and CoralReefer.
One further thing that I was thinking of, would be to approach various respected people in the field - e.g. distributed computation (and also cryptocurrency) in an advisory role.
What do others think?
Quote
I propose that part of this fund (say 20%) is kept in reserve to award/donate to scientific purposes or interesting projects that require some XEL tokens but shouldn't have to spend actual money for it. i.e. if someone from NASA (let's aim high here) wants to even try out the XEL project we could gift them some tokens so that they can at least have a play/tinker and use XEL without having to make any financial investment. Likewise, if there is some non-profit cause that requires use of XEL we could donate freely towards their cause.
Of course both of these would be the subject of some due-diligence and proof that they aren't just trying to get free money.
Seeing as @unvoid was the person who managed a lot of OTC transactions before we got listed on Bittrex, perhaps he would be up for managing the fund. I'm suggesting him as he is trusted.
Managing said fund would require both trust and some hard work, so we could perhaps propose a fee (2% or so) for the services rendered?
I'd propose that votes are made using the XEL wallet for each award, so the community gets to have some say.
Of course both of these would be the subject of some due-diligence and proof that they aren't just trying to get free money.
Seeing as @unvoid was the person who managed a lot of OTC transactions before we got listed on Bittrex, perhaps he would be up for managing the fund. I'm suggesting him as he is trusted.
Managing said fund would require both trust and some hard work, so we could perhaps propose a fee (2% or so) for the services rendered?
I'd propose that votes are made using the XEL wallet for each award, so the community gets to have some say.
Please participate in the discussion at this could be a really valuable investment of time and to give XEL some real usage in the real world.
Jump to: