Topic: [ANN][VRC] VeriCoin Proof of Stake-Time Currency | New Roadmap Released - page 868. (Read 1356163 times)

It is a "mixing-type" of anon. It's pseudo-centralized. Centralized in the sense that it requires some sort of "master node" like system, but since we're releasing the API code to anyone, anybody can create a ring-node system. In fact we would greatly prefer that-- then we can not run our own if need be. Honestly, I would have preferred not having to run the supernodes/blockchain explorer/etc. myself... it's getting expensive and time consuming.

As for traceable, when it's deployed I'll offer a bounty to trace a single transaction. The identity of the TX Send address will unlock a zip file containing a privatekey good for some amount of VRC. I don't think it will be possible to do.

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

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

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

sell your holdings right now

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

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 see you regret your decision to bark up this tree. 

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.

耐心。

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?  

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).

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

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.

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

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.

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

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

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.

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