Awesome, whitepaper is greatly written and i cant wait for the full product from this awesome team. Damn pros here!
Thank you kindly,
I and the CryptCoin team will continue to update on the progress regarding CRYPT, we also plan to implement a encrypted messaging service along with our Anon send function, as well as many other features to set Crypt apart from the competition
Best Regards
ccryptcoin
Nice paper. Want to PM me and I can discuss it with you? We looked into doing it the way you're planning and I might be able to help.
Since CRY was so nice to accuse us of stealing ANON from others and saying how theirs is better, I figured I would write a quick analysis on theirs.
Firstly, I love their stick figures.
Anyway, their implementation is not possible.
Let's go through their list point by point (my commentary in bold):
CryptCast Synopsis
● Wallet A wants to send an anonymous transaction to Wallet B.
● Wallet A (sender) encrypts a message towards Wallet B (recipient) by
using private/public key concept, with Wallet B’s public key.
I'm not sure if CRY is talking about using the CRY public/private keys as in addresses and private keys, but I looked very heavily into that and it's not possible. The pubkey (or address) is actually a hash of the privatekey and cannot serve as a private key. It's possible to get Wallet B's public key, but only if it has sent a transaction before and thus it's in the blockchain. There's no transmission system to send that public key. ● The message is broadcasted through the nodes connected to Wallet A, and
will reach will reach Wallet B via the broadcasting system that already
exists in the Bitcoin protocol.
What I presume CRY is discussing here is probably the OP_RETURN function being integrated into BitCoin right now. It is not in the CRY codebase and is tough to integrate. More importantly, it only can store 40 bytes of data: https://bitsharestalk.org/index.php?topic=3830.0. That is not close to enough to do what is being proposed.● Wallet B is the only one that can decrypt the message with Wallet B’s
private key.
● Wallet B receives the request for secure transaction from Wallet A.
There is no mention of how this will be done and is not easily done.● The message contains the total number of transactions that are capable
of transmitting, and the total amount of coins.
I'm surprised there are no checksums, address verification, etc.● E.g., if Wallet A wishes to send 3 transactions and Wallet B accepts it,
it returns 3 new addresses (encrypted message with pubkey of wallet A.)
As I said before, this is not possible to send in 40 bytes. Not only that, but where is the pubkey of wallet A going to come from? ● The message is again broadcasted till it reaches wallet A.
Broadcast until it reaches? What if Wallet A is turned off? How does it stop wallet B from broadcasting? Is there an ack? Otherwise this is certainly going to flood the blockchain. Can someone say 1 TB drives for a coin wallet?● Wallet A decrypts the message, receives the new addresses and creates 3
transactions for each IN transaction it has, sending them to each new
address it got from the new wallet.
● Multi-transaction time-delay will be optional for maximum anonymity if
speed is not required.
● If Wallet B does not accept any type of secure transaction, it encrypts
again a message with decline response
● Wallet A then has the option of sending plain, non-secure transaction,
or to not send it at all.
I got tired of analyzing more but frankly this is impossible to do without completely restructuring the blockchain and requiring a very serious hard fork.
RE: Cryptcoin Anonymous Sending
We will have full answers to your questions tomorrow, things are busy right now.
We have this working right now in testing and there are solutions to all of these issues. It explicitly says in the paper that it isn't a complete explanation. and yes, we will be doing a hard forking.
It is a very interesting method of anon sending, and we will be open sourcing it eventually, also.
It's funny that nobody in the crypto community realizes that every method of "anonymous" sending is just a proxied mixer setup which was implemented by fedoracoin all the way back in February. But nobody cared about fedoracoin. All the current implementations are merely centralized mixers, with everyone racing to this same solution. CRY is looking forward to new things.So far we have met all our promises. We will give more through explanations in the coming day or two - it is a busy time.
Shouldn't you be working on your own "anon" features?
Why do you post it is good idea and you want to help in CRY thread but fud in VRC thread? Its not proper business.
