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.
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.
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 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.
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.
Thank you for your interest in the internals of our technology. Right now, we are talking about generating an address:
1. Private keys are 32 byte, randomly generated by a secure random class, same as bitcoin.
2. The ECDSA curve used here is sepc256k1.
3. The 64 byte point is the curve's generator multiplied n times (where n=private key). Then you have 32 bytes for the X coordinate and 32 for the Y.
4. These 64 bytes are split into 4 chunks of 16 bytes, where each position is added up modulo 256, resulting in 16 bytes.
5. Network bytes are used to identify the network (testnet/mainnet/other) and to validate the address (instead of checksum). The network bytes are also added up modulo 256.
6. If all 16 bytes are below 100, then it's a valid address. This does not reduce entropy of the private key generator, it's not even related to that. If you check it, it makes it difficult to generate the address therefore making it difficult to brute-force attack it.
Hope that helps.