[ANN][VRC] VeriCoin Proof of Stake-Time Currency | New Roadmap Released

[Kevondo]

Has anybody gotten any payouts for the vericoin multipool while mining X11?

I've been mining for 24h and haven't received anything yet. My address is correct.

The MultiPool is still in Alpha. Which means, it may shut down periodically for adjustments. All Shares R being recorded. U will be paid for the hash you have put into the pool.

I have had my rig aimed @ the multipool for 4 days. I have received payouts twice in the late evening and the early morning. I did not receive a payment yesterday.

pnosker, a Dev, stated earlier today there will be double payout tonight. Probably

The rub is that the auto-pay module is not working smoothly. All payouts have to be done manually, this is temporary.

The 2 Dev's also hold down full time jobs. The spend an inordinate amount of time here or on IRC. They have recently hired an accomplished, respected software , crypto guy to help.

They R known for delivering what they say they will, and give frank and honest replies.

The wallet is polished and bullet proof.

The next priority is the MultiPool . Take some time to read the last 10-15 pages of this thread. It will address  a lot  of your concerns and give you a feel for what VRC is doing.

When fully functional the MultiPool will payout @ yet to be determined intervals and occasions daily. For now it's done manually.

Presently, data from M/P such as coins per MG/h R unavailable. All features common to other MP's will eventualluy be instituted.

What makes VRC special is,The Anon apps, sms transfers, world wide distribution, coin-mixing and OBA (Optimized Buying Algorithum) and other stuff they have yet to announce.

U can learn about all these things by putting some time in reading the past pages on this thread

Put some time in and become part of a committed community inspired by a Development team making true innovations. Integrity, Hard work, and transparency R their hallmarks.

And........ U just might make some money    

[1713536531]

1713536531

[1713536531]

1713536531

[1713536531]

1713536531

[1713536531]

1713536531

[1713536531]

1713536531

[1713536531]

1713536531

[CryptoClub]

So the innovation here is the dynamic interest rate. The way it works is that the interest rate scales according to network stake. If there's a higher amount of staked coins, the interest rate goes up. That means the more "invested" you are in the coin, the more interest you will make.

This essentially gives incentive for you to hold your coin in your wallet rather than keeping it on an exchange, gives you reason to tell your friends to acquire some coin and keep it staking, etc. because it helps both you and them. It's the only coin that provides additional reward for keeping the coin.

This part is good and got me interested. I am an investor, not a trader.

It also provides a reasonable interest rate compared to Blackcoin (1%) and other PoS coins (10%+ interest). Most stable economies have higher inflation than 1% so assuming the coin's value keeps steady it makes more sense to put it in FIAT and earn traditional interest. With the dynamic scaling interest rate, you're likely to make 2-2.5% interest which is much more in line with mature economies.

This part turned me off. Here's why:

Coin devs need to understand that 20% APR is not attractive for a long term investment, when MINT can lose/gain over 100% in one day.

We are NOT in real life. We are in Cryptoland. You don't expect the price of cookie to triple in one day (or even to goes up by 10%). Hence the low interest.
In Cryptoland, rules are different. Coins using real-life interests for crypto miss the point.

So, relaunch or clone with a higher stake, or just live your pump and dump life.

You are clearly a huge fan of Monero. I have not followed it that closely, but, as a POW coin, it is CPU mined, right? What is to prevent it from being dumped by miners (or mined by bot farms) if the value ever goes up much? FLT and MYR are both very innovative, but no matter what they do, they face miners dumping on every "pump." POS coins with low interest maintain value better in the real world, and in cryptoland. I am sure XMR is great, but your advice on interest rates is really off the mark. The most successful POS coins have the lowest rates. Just look at the CMC and this is fact. No debating it, all the top POS coins have the lowest rates, no doubt, no question, that is reality. NXT/PPC/BC

[PUMPBANDIT]

I can see this coin hitting 200 - 300 in 24-48
Went up x3 in 12 hrs.


But who ever is putting out the bids on Minty should be sacked!!!!
To big a gap looks like your trying too hard and people walk.

[pnosker]

2 updates:

1. Ask us questions at the VeriCoin subreddit: http://www.reddit.com/r/vericoin/comments/27g128/we_are_vericoin_ask_us_almost_anything/

2. We released a "white" presentation with more details about our Anon system: www.pnosker.com/vericoin-anon.pdf

[coine_smithe]

2 updates:

1. Ask us questions at the VeriCoin subreddit: http://www.reddit.com/r/vericoin/comments/27g128/we_are_vericoin_ask_us_almost_anything/

2. We released a "white" presentation with more details about our Anon system: www.pnosker.com/vericoin-anon.pdf

Expect a dump to reward your troubles. That way profiteers can accumulate this great coin before takeoff. 

[pnosker]

2 updates:

1. Ask us questions at the VeriCoin subreddit: http://www.reddit.com/r/vericoin/comments/27g128/we_are_vericoin_ask_us_almost_anything/

2. We released a "white" presentation with more details about our Anon system: www.pnosker.com/vericoin-anon.pdf

Expect a dump to reward your troubles. That way profiteers can accumulate this great coin before takeoff. 

Please, anyone who gained something from VeriCoin so far, please donate to help us keep stuff going:

VDbSLcgkVZSeRQyK3YwMFzPaLHEXWgLHFi or 13j9bCMHtYM3xkbyYDg9UgJ757SkAryKHg

I've been paying the supernode costs out of pocket as well as hiring our latest dev. We didn't premine/IPO and could really use some donations now for the new dev.

[foxy]

2 updates:

1. Ask us questions at the VeriCoin subreddit: http://www.reddit.com/r/vericoin/comments/27g128/we_are_vericoin_ask_us_almost_anything/

2. We released a "white" presentation with more details about our Anon system: www.pnosker.com/vericoin-anon.pdf

VeriCoinPorn eh? nice example LOL
sent 2k VRC to your donation address. keep the news coming, good job guys.

[pnosker]

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.

[CryptoClub]

2 updates:

1. Ask us questions at the VeriCoin subreddit: http://www.reddit.com/r/vericoin/comments/27g128/we_are_vericoin_ask_us_almost_anything/

2. We released a "white" presentation with more details about our Anon system: www.pnosker.com/vericoin-anon.pdf

Expect a dump to reward your troubles. That way profiteers can accumulate this great coin before takeoff. 

Expected and observed. I feel sorry for panic sellers, but, lessons are learned the hard way.

[coine_smithe]

...

Thanks for the analysis. It's very interesting to hear an expert's take on a dev's claims. I think you seem pretty impartial here and since you didn't initiate the attacks I don't think people will look down on you. That said as an investor I feel much more confident in VRC than CRY from the get go even without this back and forth. CRY has anonymous devs for one and their plan is much more vague. They also don't have any innovations like variable interest and SMS, so I really think this is like DRK/XC situation except instead it would be like XC (CRY) first attacking DRK (VRC).

[ccryptcoin]

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?  

[ScottAllyn]

什么情况？ 我早上买的时候  2014-06-05 22:44:53   BUY   0.00012220
               现在的价格2014-06-06 05:17:17   BUY   0.00007600
     在搞什么啊？这是要害死人的啊～～～·

耐心。

[pnosker]

...

Thanks for the analysis. It's very interesting to hear an expert's take on a dev's claims. I think you seem pretty impartial here and since you didn't initiate the attacks I don't think people will look down on you. That said as an investor I feel much more confident in VRC than CRY from the get go even without this back and forth. CRY has anonymous devs for one and their plan is much more vague. They also don't have any innovations like variable interest and SMS, so I really think this is like DRK/XC situation except instead it would be like XC (CRY) first attacking DRK (VRC).

VRC and I don't gain anything with attacks. I'm genuinely interested in saving the dev some time since I spent countless hours studying how to implement ANON. It's just not possible the way he wants to do it. That might also be why there's no details on his "whitepaper" (which by the way looks nothing like a REAL whitepaper). When we finish our code up for ANON it'll be public. Anyone can write something that fits the API commands and start their own ring-nodes which in turn would help keep the network even more secure.

I'm all about innovation. Yes, I didn't like when we were accused of stealing ANON from Fedora or XC. I also didn't like how he said ours was worse. The one thing I can say is that the CRY team is going to basically have to reinvent the blockchain to get their system working. Not that it can't be done, but it will most likely require a hard fork and a lot of dev and testing time.

[coine_smithe]

Shouldn't you be working on your own "anon" features? 

I see you regret your decision to bark up this tree. 

[pnosker]

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.

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?  

There's no "truely anon" anon, just like there's no "perfect" passwords. With enough computing power you can crack anything. And that includes a decentralized system. Anyway I look forward to it. I'm happy to discuss privately if you'd like. We had a short term VRC testnet with a different merkel hash where we tested trying to send encrypted data via the message tx values but it was impossible to have efficient sends/receives. But please, before you release more details, feel free to PM me. I won't leak anything and will let you know what I think if you're interested.

SMS wallet is our top priority right now but yes we are working on our own anon features.

[battbot]

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?  

Let's get our facts straight here -- XC has already implemented xnodes which offers a 100% decentralized solution.  

[cyberhacker]

什么情况？ 我早上买的时候  2014-06-05 22:44:53   BUY   0.00012220
               现在的价格2014-06-06 05:17:17   BUY   0.00007600
     在搞什么啊？这是要害死人的啊～～～·

sell your holdings right now

[ccryptcoin]

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.

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?  

There's no "truely anon" anon, just like there's no "perfect" passwords. With enough computing power you can crack anything. And that includes a decentralized system. Anyway I look forward to it. I'm happy to discuss privately if you'd like. We had a short term VRC testnet with a different merkel hash where we tested trying to send encrypted data via the message tx values but it was impossible to have efficient sends/receives. But please, before you release more details, feel free to PM me. I won't leak anything and will let you know what I think if you're interested.

SMS wallet is our top priority right now but yes we are working on our own anon features.

I was disturbed because you posted friendly message in CRY thread:

"Quote from: pnosker on Today at 05:11:57 AM
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 then made very bad comments in your thread. This is not proper, and I am wary to discuss plans with you. Yes, there are some things being ironed out. But the feature is working and we are moving forward with our method at a steady pace. At the very worst, we would implement the node/mixer tech which is very simple. But we prefer to do a New type of anon send.

I wish you luck with your project, and I know we will be watching each others progress

[tristartek]

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.

But isn't VRC just a mixer?  Its still centralized and traceable.

[MrWHALE]

rofl, CRY's whitepaper is such a piece of shit.  Evidence of a total scam -- they can't even make a proper whitepaper.