https://bitcointalksearch.org/topic/anncrypt-cryptcoin-x11-pos-p2p-anonymity-0-premine-commander-618377http://cryptco.org/Cryptcoin-CryptCast-Anonymous-Whitepaper.pdfCrypt.
Here is catch.
1) Is encrypted msg written to blockchain ?
probably not.
==> need to be online both.
2) Mixer without real payee.
Xnode announce itself to network, Crypt do reversal.
Crypt payer announce to payee, where coins to go ?
O ho...
Hello.
I was invited to check the implementation of XC compared to FedoraCoin's codebase in order to find possible similarities between them.
First of all, I visited FedoraCoin's repository and checked the specific file mentioned (mixerann.cpp and the header file).
Then, I was invited to Developer's station with a Teamviewer session and saw the code that implements the specific feature.
The code is in no way similar between the two coins.
But, I believe that one must trusts his own eyes (and compiler). Just download the source code from FedoraCoin and create a working wallet that has all the features of XC enabled. That would prove whether the claim is correct or false.
Now, I do not know who claimed that Fedora and XC share the same codebase. If someone claims that some principles are the same, then I'm afraid that someone hasn't heard of Bitcoin and the blockchain concept (or the transaction concept, or the pubkey->wallet address concept, or... the list goes on forever).
Hi everyone.
This is my first post in here (actually I should never really have to post
) but I feel obligated to do so, in order to make some clarifications
First of all, excuse my English, as it is not my native.
The pdf document that has been published, is just a rough draft to describe the process in a very simple manner so everyone can understand.
It was not originally meant to be a "Whitepaper".
It is not a protocol description, nor the logic flaw of the application fully detailed.
As it has already been mentioned, it is work in progress.
For those who are familiar with developing cycles, when a product is designed and hits the development department, the final product from the original design many times have lots of differences. And that's to overcome original design flaws, dead ends in the logic or other problems that are part of the development process and needs to be addressed, so that final product meets original specifications.
Saying that, I welcome the comments made to that draft and most of them are valid points and have already been acknowledged and has being or will be addressed.
Remember, it's still work in progress.
If I may comment regarding the best way to do things (for example hard-to-trace transactions), I do not believe that there is an objective "best" way to do it. If there are more than one ways, there will be preference according to specific needs. Every solution will have pros and cons. Some are affected more and others less. It all depends and it's a matter of which solutions works best for each individual.
I respect everyone's work and I am not afraid to admit that I am trying to learn from other ideas and extend them. Isn't that the purpose of open source projects?
I do not believe into "I know it all" people and I never said I am one. Nor any of the team members, from my interaction with them.
Mistakes will be made and be corrected as fast as they are spotted. So it's good to have more eyes to spot them for me and let me know of any error or flaw in my implementation. It speeds things up and also helps me learn more.
So, I always believed that a mixture of ideas can get the best possible result, as long as there's cooperation and good will. That's how this team works and I really believe that we will give the best possible results on each development cycle and on each version release.
From my reading of the whitepaper, it appears the recipient wallet must be online (i.e. running the wallet software) in order to receive coins anonymously. If so, this isn't a workable anonymity solution. Can the dev please clarify?
In order for the transaction to take place, in this initial draft, the wallet has to come online and give "directions" to the sender regarding the destination addresses. The "trigger message" will be valid for some time before it times out. I am testing various scenarios on how to make it work with the best possible (to my knowledge) way.
Now, whether it's workable or not, I guess one must weight the pros and cons. As another developer said (and he's right all the way): there are no true passwords, nor true encryption. Everything can be broken with enough computational power.
So I make myself this question: who do I trust to deliver my coins?
As I said previously, it's a matter of preference. Also, I'm sure that more ideas will come from this, as there's always room for improvement to every design