Bitcoin Forum
November 19, 2017, 12:13:28 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 347 »
  Print  
Author Topic: [ANN][CRYPT] CryptCoin x11 + PoS | P2P Anonymity | 0% Premine | Commander  (Read 505960 times)
KingTuna
Newbie
*
Offline Offline

Activity: 23


View Profile
June 06, 2014, 04:57:38 AM
 #701

Great work Devs! Whitepaper looks fantastic. CRY has a bright future!  Grin
There are several different types of Bitcoin clients. Header-only clients like MultiBit trust that the majority of mining power is honest for the purposes of enforcing network rules such as the 21 million BTC limit. Full clients do not trust miners in this way.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511050408
Hero Member
*
Offline Offline

Posts: 1511050408

View Profile Personal Message (Offline)

Ignore
1511050408
Reply with quote  #2

1511050408
Report to moderator
pnosker
Sr. Member
****
Offline Offline

Activity: 462


View Profile
June 06, 2014, 05:11:57 AM
 #702

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 Smiley


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.

Support the VeriFund Endowment.
VRC: VFEndownxxnHea9mv59kZx8c7TysGbndYx
ccryptcoin
Member
**
Offline Offline

Activity: 92

CRYPT Developer


View Profile WWW
June 06, 2014, 05:28:09 AM
 #703

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 Smiley


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.

But in your thread you posted very bad things!!

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?  Smiley


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.

Lead Dev of CRYPT -- http://www.cryptco.org/ -- @CryptCoinTeam
KickAzzDude
Hero Member
*****
Offline Offline

Activity: 514


View Profile
June 06, 2014, 05:32:40 AM
 #704

Just an error I caught in the whitepaper pdf,

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.

not a big deal, but if you want professionalism, it's best to not have grammar mistakes on that

cryptoholic11
Sr. Member
****
Offline Offline

Activity: 476


View Profile
June 06, 2014, 05:41:26 AM
 #705

I have to be honest here. That white paper is really vague and you can't  tell me you spent a whole week writing that up. That looks like a last second type up. If I am wrong, please excuse me.
Too much shadyness, with hype this hype that, now Moosa is hyping shit up. I'm out. First the whole debacle with the XC dev, now this bs. Even if this is a legit project, there is too much bashing other coins, hype and overall sketchy business. I genuinely wish you guys the best though. Good luck.


tristartek
Full Member
***
Offline Offline

Activity: 140


View Profile
June 06, 2014, 05:53:39 AM
 #706

I have to be honest here. That white paper is really vague and you can't  tell me you spent a whole week writing that up. That looks like a last second type up. If I am wrong, please excuse me.
Too much shadyness, with hype this hype that, now Moosa is hyping shit up. I'm out. First the whole debacle with the XC dev, now this bs. Even if this is a legit project, there is too much bashing other coins, hype and overall sketchy business. I genuinely wish you guys the best though. Good luck.



A whitepaper is really just a promo for a stock/currency.  Its not really meant to be a detailed writeup of every nook and cranny of the technology.  Maybe dev is spending more time implementing and testing vs a perfect write up for everyone.  Actions speak louder then words.

BTC: 1KTg6RkiHjovXqVfVB1a74NPPXLnoL1HNf
sdmathis
Hero Member
*****
Offline Offline

Activity: 546


AKA The Rubber Monkey


View Profile
June 06, 2014, 05:59:17 AM
 #707

To all the people selling CRY for VRC...

Our anon feature is better than the one VRC is implementing (the copy paste one)   (edit for vrc devs: the rumors that it is copy of fedora or xc implementation seem to be wrong, apologies if so.)

It's in testing right now. wp IS coming.

We already have a multipool that pays out in CRY, supported by the biggest out there.. multipool.us

Sell now, CRY later. Smiley




You should really check your facts before posting false information.

WheresMyWallet
Member
**
Offline Offline

Activity: 84


View Profile
June 06, 2014, 07:56:01 AM
 #708

A very interesting white paper, well written for a first draft.
Definitely a coin to be keeping in your bags.
SushiChef
Full Member
***
Offline Offline

Activity: 126


View Profile
June 06, 2014, 08:46:48 AM
 #709




New Update!!  6/5/2014



Revision 1 of our CryptCast anonymous sending whitepaper is now available.

A unique, fully autonomous, anonymous design with no centralized control or monitoring.

http://cryptco.org/Cryptcoin-CryptCast-Anonymous-Whitepaper.pdf


Biggest BS ever! Glad I sold with huge profit.. ain't buying back, this is a joke. Paper looks like it is written by a teenager wanting to make a quick buck.
sdersdf2
Full Member
***
Offline Offline

Activity: 224


View Profile
June 06, 2014, 08:54:05 AM
 #710

This coin looks dead/dying.



To all the people selling CRY for VRC...

Our anon feature is better than the one VRC is implementing (the copy paste one)   (edit for vrc devs: the rumors that it is copy of fedora or xc implementation seem to be wrong, apologies if so.)

It's in testing right now. wp IS coming.

We already have a multipool that pays out in CRY, supported by the biggest out there.. multipool.us

Sell now, CRY later. Smiley




You should really check your facts before posting false information.
ccryptcoin
Member
**
Offline Offline

Activity: 92

CRYPT Developer


View Profile WWW
June 06, 2014, 08:55:29 AM
 #711




New Update!!  6/5/2014



Revision 1 of our CryptCast anonymous sending whitepaper is now available.

A unique, fully autonomous, anonymous design with no centralized control or monitoring.

http://cryptco.org/Cryptcoin-CryptCast-Anonymous-Whitepaper.pdf


Biggest BS ever! Glad I sold with huge profit.. ain't buying back, this is a joke. Paper looks like it is written by a teenager wanting to make a quick buck.

It is a draft, a rough explanation. It was transmitted from our lead anon tech dev to a marketing group, in an attempt to being to explain the ideas to the public. He is working hard on the project - it is massive - and does not have time to write papers. Everyone was growing antsy so we wished to share some of the generalities. Not as a final technical paper.

Please stay tuned as our lead anonymous technology developer is about to post from his real account to clear up these worries. He is one of the most talented and respected devs currently working in the altcoin world.


Edit: Costas (Mindfox) post is below.




Lead Dev of CRYPT -- http://www.cryptco.org/ -- @CryptCoinTeam
Boomsling
Member
**
Offline Offline

Activity: 113


View Profile
June 06, 2014, 09:22:22 AM
 #712



I've looked though both threads for both coins and the correspondence between devs, it such a shame to see two very promising coins go into a dick waving contest. They way that the CRY team have carried themselves thorough this is a credit to them.

pnosker, I now find myself re-evaluating my position with VRC, I cannot morally justify my support a coin or development team that would swoop to underhand tactics to try to better position themselves from the competition, you should calm this down. It would be better for crypto on a whole if you could perhaps work together?
drkman
Sr. Member
****
Offline Offline

Activity: 378


View Profile
June 06, 2014, 09:23:50 AM
 #713

IE is that you?
SpringfieldM1A
Hero Member
*****
Offline Offline

Activity: 658


GET IN - Smart Ticket Protocol - Live in market!


View Profile
June 06, 2014, 09:41:25 AM
 #714



I've looked though both threads for both coins and the correspondence between devs, it such a shame to see two very promising coins go into a dick waving contest. They way that the CRY team have carried themselves thorough this is a credit to them.

pnosker, I now find myself re-evaluating my position with VRC, I cannot morally justify my support a coin or development team that would swoop to underhand tactics to try to better position themselves from the competition, you should calm this down. It would be better for crypto on a whole if you could perhaps work together?


Nail on the head + 1


               ████
             ███  ███
           ████     ███
         ███  ███    ███
       ████     ███    ███
     ███  ███     ███    ███
   ████     ███     ███   ██
 ███  ███     █████████████████
███     ███     ███           ██
 ███      ███     ██          ██
   ███      ██████████      ███
     ███      ██████      ███
       ███      ██      ███
         ███          ███
           ███      ███
             ███  ███
               ████

GUTS
    ███
███
███
███
███
███
███
███
███
███
███
███
███
███
   
smart-ticket protocol for events
live product with market traction!
    ███
███
███
███
███
███
███
███
███
███
███
███
███
███
   
  BTC ANN
  WEBSITE
  BLOG
   
  SANDBOX
  WHITEPAPER
  BOUNTY
   
mindfox
Sr. Member
****
Offline Offline

Activity: 280


Donate to put a smile on my face :)


View Profile WWW
June 06, 2014, 09:41:42 AM
 #715

Hi everyone.

This is my first post in here (actually I should never really have to post Smiley ) 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.
TenaciousC
Hero Member
*****
Offline Offline

Activity: 609



View Profile
June 06, 2014, 09:43:45 AM
 #716

People seem to be giving away their CryptCoin stash for free at Poloniex, well thank you all! I'll put them safely in my wallet and wait until we reach 0.002






██████████████████████████████████████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████████████▄▄▄███████████████████████
███████████████████████████████████████████████████████████████████████▀▀▀████████████████████████
██████████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████████





...INTRODUCING WAVES........
...ULTIMATE ASSET/CUSTOM TOKEN BLOCKCHAIN PLATFORM...






WheresMyWallet
Member
**
Offline Offline

Activity: 84


View Profile
June 06, 2014, 09:46:32 AM
 #717

Ohhhh nice ... Mindfox is the anon dev ... why do I not have more BTC to buy now!
inmymem
Member
**
Offline Offline

Activity: 79


View Profile
June 06, 2014, 09:47:12 AM
 #718

Hi everyone.

This is my first post in here (actually I should never really have to post Smiley ) 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.


Thank you for the update.
Can you elaborate on how well the tests are going and is it functional/ is the release date in sight?
Thank you

SUM2 - First coin with Navajo Anonymous Technology
jacoo
Full Member
***
Offline Offline

Activity: 181


View Profile
June 06, 2014, 09:48:04 AM
 #719

Hi everyone.

This is my first post in here (actually I should never really have to post Smiley ) 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.



 Grin Grin Grin
cryptowest
Sr. Member
****
Offline Offline

Activity: 437


View Profile
June 06, 2014, 09:58:44 AM
 #720

Hi everyone.

This is my first post in here (actually I should never really have to post Smiley ) 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.


Wow I knew Mindfox was THE man but the polo box just went crazy for him, lol:

Delboy: Alchemy, His name is Mindfox, he has taken on projects that no-one else could do and never failed to deliver
macdever: Delboy, mindfox is new CRY dev?
Delboy: macdever, He has joined the team yes
Delboy: macdever, Definitely one feather for the cap in CRY
macdever: yeah, i'd hire him if i was gonna release soemthing
smille: Mindfox is the bees knees
TheGift73: Awesome to hear that mindfox has joined the CRY team. Awesome dev.

Very excited for CRY now...  if mindfox is behind it, its getting done.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 347 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!