You're being childish. Why don't you just explain the beauty of your concept instead of getting all fiery wild about how I understood your statement about receiving REC. That's how I understood it. All you have to do is explain it so no one else will misinterpret it the way I did.
You have all the information you need on the website, whitepaper and code. If you post any specific technical question, and it seems serious to us, you'll be answered.
Well it is not up to you to decide if we have all the information we need. That is up to your target audience.
But, let's go into a technical discussion, if that is what you want. I take this passage from your "whitepaper", which I would not really call a whitepaper, because it leaves out most of the details, and fails to connect the dots of information that are in it.
Addresses
Every account address is represented with 32 digits, and is created the following way:
1. A random private key is chosen
2. A point on the curve is calculated into a 64 byte array
3. The byte array is collapsed into a 16 byte array
4. A constant 16 byte array called “Network Bytes” is also added
5. If all bytes in the address are below 100, the address is valid and can be represented with digits only (32 digits for 16 bytes)
It takes some time to generate the address, yet it saves space on the chain and adds proof of work. While generating the address, the client may hit or recover one of the targets.
ad 1. What does the randomly generated private key look like? What are it's specifications?
ad 1. What does random mean in this case? What type/class of random generator are you using? Is it seeded, and if so: how?
ad 2. "A point on the curve is calculated into a 64 byte array". Many questions:
ad 2. What curve? what does a "point on the curve" mean? What point? what curve? What do you mean by "chosen" ? How does that work? Are there criteria to "choose" a point ?
ad 2. If you have 64 bytes, you have 64 bytes. An array is a representation of those bytes. What does that mean? How many elements are in your array? Is it associative or zero base indexed? How many bytes are used for the indices and how many bytes are for the data? The fact that the 64 bytes are an array implies that they are ordered. Why the ordering and how is the ordering preserved? Why the array representation? Sounds like bullshit to me but please prove me wrong.
ad 3. What do you mean by "collapsing a 64 byte array into a 16 byte array" ? Do you realise that if you reduce 64 bytes to 16 bytes, you are reducing entropy, thereby throwing away information? Lowering entropy is rarely a good idea in cryptographic systems. Please explain why this is a good idea in this case. Oh, and explain the "collapsing" algorithm.
ad 4. Why use 16 bytes for a constant? A constant is a constant. You are not using the 16 bytes entropy. Again: why is this a good idea? It does not add entropy nor information.
ad 4. What is the "Network Bytes" constant being used for? What is the purpose?
ad 5. Again lowering the entropy, by not using all bytes below '100' (assuming 100 in 10-base). Looks like you are throwing away all the advantages of high entropy in cryptographic systems, thereby making your system weaker with every step.
Please answer those questions, because they are a big big concern.
For the non-technical people: the "whitepaper" may seem to use some impressive words, but if you have a technical/cryptographical/software development background, it raises more questions than it answers. In fact, a number of sentences in the whitepaper are technical nonsense, and others are fundamentally wrong.