Cryptocurrency Privacy: Evolving... Zerocash (ZEC, ZCL, ZEN) vs All Other Coin
Rethreading these two former threads into a more General: Item... 1: Zerocash: Addressing Bitcoin's Privacy Problem GoogleTechTalks 2: Why I can't sleep soundly with blockchain, being the cypherpunk ########## https://zcoin.io/zcoins-privacy-technology-compares-competition/
Blockchain privacy is a particularly difficult thing to achieve as a public blockchain is designed so that all transactions are transparent and the supply of coins can be publicly verified. Privacy mechanisms have to ensure that these elements are preserved so it’s a conflicting mix of protecting privacy while maintaining public verifiability.
That's obsolete thinking. And to open coin comparisons with such statements misleads the reader into believing that supposedly "private" coins that retain elements of that thinking are an ok thing. The point of a cryptographically private coin is to hide everything that might permit traceability under the shield of strong crypto (including support for transport over anonymous networks). Unlike mix coins, crypto shielding is its privacy mechanism. One doesn't need to have, see, and verify for such a coin all the old traditional bits of a public ledger blockchain... transactions, utxo balances, addresses, coin supply... because the crypto should enforce those parts are working, and make them immune from attack. Provided the crypto is solid, the coins below may be better at privacy than all other in-production, non zerocash based, coins to date. https://en.wikipedia.org/wiki/Zerocash https://z.cash/ - Zcash ZEC http://zclassic.org/ - Zclassic ZCL https://zensystem.io/ - Zencash ZEN Further old and misleading arguments against them...
Private transactions take a while to generate (almost a minute on a decently powerful computer)
Old news is old... https://z.cash/blog/cultivating-sapling-faster-zksnarks.html
Complicated trusted setup / traceable / backdoored
Don't like it? Take more time in understanding and peer reviewing it, preparing and injecting openness, reproducibility, philosophy, documentation and auditability into the process in advance... and restart. The first Zerocash ceremony is not the only such ceremony the world will ever see in the crypto space. And the first one might be as good. Add this new post to the list of links on the list / net about ceremony... https://z.cash/blog/ceremony-audit-results.html
setup that has to be done by the developers.
False. It can be done by any group having any number of participants in an opensource reproducible and public fashion. The design, process, and results can all be posted and then imported by new projects as needed. Further, is it true that, in software release for current production Z coins, that new parameters can be dropped in place of old parameters for new transactions on their chains going forward? https://github.com/zcash/zcash/issues/2247
Supply cannot be audited therefore forgery can be very difficult to detect.
Bogus Arg. If setup is secure, and crypto enforces against forgery, then requiring blockchain be "public" about supply for auditability is moot. And even if the blockchain is not auditable, forging coin creation can still be detected by the community knowing its own real world size throwing funds into the coin, yet the price and walls aren't moving as they should over time. And a whole lot of Lambos rolling around till it gets leaked / rediscovered and fixed.
Uses relatively new cryptography
Crypto was new. Bitcoin was new. Cryptocurrency is still new. Regulation is still new and is a nearly equivalent goes-to-zero threat. Get cryptocurrency out there, get it peer reviewed, get it in production. Don't put in more than you want to lose. Here are some corporate reviewers and users that are either traps and/or investing huge sums they cannot afford to allow to lose... https://www.americanbanker.com/news/worlds-collide-jpm-works-with-team-behin... https://github.com/jpmorganchase/quorum http://entethalliance.org/
https://steemitimages.com/DQmSzRp3XQCXwQ1Y14jTNLcBw1XQ9rZ6oNz1XbnZxHomME3/im...
Bitcoin Core Version
Both ZEC and ZEN should merge back into each other some of their own improvements and fixes, including importing any recent useful stuff from original parent codebase of BTC. Normal opensource process.
Hides tx amount / Optional privacy defaults
Mix vs Transparent and Shielded... Well then don't use mixes or transparent, get it migrated and committed out of the code forever... https://imgur.com/gallery/MWdwh https://github.com/zcash/zcash/issues/2248
Compute time
Outdated info. See sapling tech above.
Incentivised Nodes / Pruneable / Scaling
These issues affect all cryptocurrencies in some way. Zencash ZEN has some work potentially evolving incentive structures https://zcoin.io/zcoin-development-update-znodes-and-scaling-zerocoin/
Trusted setup
Sly word choice. Call it "DASTp - distributed any single trust prevails" or something more technically representative like that. Here's another long debate... https://www.reddit.com/r/CryptoCurrency/comments/737is9/charlie_lee_tells_sn... This note isn't really meant to compare coins versus each other (they could all be shit), but to hint that the amount of FUD and outdated arguments being used out there to compare them... especially by their very own developers and communities who should know better... should be of concern and needs improved. Even an armchair reviewer could get rich starting up a site devoted solely to more objective comparisons and tracking development news and roadmaps. https://www.americanbanker.com/news/cheat-sheet-the-trade-offs-of-blockchain... "Each of these technologies solves a fraction of the puzzle, but we are beginning to see how they can be stitched together to deliver more complete privacy. A lot of the implementations take multiple different technologies and combine them together to achieve an additive result. It may well be that a combination of different technologies emerges as being a better solution." Prediction: Crypto-private coins will eventually outpace and surpass mix-private coins as knowledge of crypto continues to increase around the world. Send your wagers and comments here... btc:199WA27L4tVazpg2Bqzas2cX7nomqP4ZEp It's early days, keep your eyes open and your cryptocurrency ready.
Rethreading these two former threads into a more General: Item... 1: Zerocash: Addressing Bitcoin's Privacy Problem GoogleTechTalks 2: Why I can't sleep soundly with blockchain, being the cypherpunk
##########
https://zcoin.io/zcoins-privacy-technology-compares-competition/
Blockchain privacy is a particularly difficult thing to achieve as a public blockchain is designed so that all transactions are transparent and the supply of coins can be publicly verified. Privacy mechanisms have to ensure that these elements are preserved so it’s a conflicting mix of protecting privacy while maintaining public verifiability. I'm trying to understand what kind of crypto algorithm is being used in Zcoin. Is it any similar to cryptonote/bytecoin's ring signatures and such? I understand that transmitted coins are burnt and new ones replace
On 01/10/2017 7:42 AM, grarpamp wrote: them, but IMO this doesn't cover privacy fully - it's mostly the way the transactions/coins are transmitted that matters, is it not? In short my question is, how does zero knowledge proof compare to ring signatures employed i.e. by Monero?
On 05/10/2017 20:30, George Violaris wrote:
In short my question is, how does zero knowledge proof compare to ring signatures employed i.e. by Monero?
A proof is created that previous transactions equivalent in value were marked as consumed, without revealing which ones. Generating this proof is inconveniently slow, and the data that has to be stored is inconveniently on the fat side, but verifying it is reasonably fast. I don't have accurate information as to the costs of doing it this way, but they seem to be non trivial. Proof generation is particularly expensive, but this cost is carried only by the parties directly benefiting, not by the entire blockchain, thus is incentive compatible.
On 06/10/2017 8:31 AM, James A. Donald wrote:
Generating this proof is inconveniently slow, and the data that has to be stored is inconveniently on the fat side, but verifying it is reasonably fast.
I believe the issue with this, such as in Bitcoin and any coin, is that the blockchain eventually grows to an enormous size. It's all nice when it's at around 200GB of data and it only takes a few days to synchronize to the network. But think about a blockchain that is 2 TB. That is not only a huge blockchain, that would be huge for a relational DB that is stored on central server or cluster. When databases get to that size, companies divide the schema. They'll either divide it per system, per department, per branch or however it suits them best. Then they'll use some sort of business intelligence tool to make sense of all that data. Nodes need to be able to be useful by storing smaller chunks of a blockchain instead of having to store the entire thing, something like how sharing a bittorrent file works. The downside is that this may lead into centralization as full nodes would have an advantage, but it's not worse off than what it is now. ./gv
On 06/10/2017 16:03, George Violaris wrote:
I believe the issue with this, such as in Bitcoin and any coin, is that the blockchain eventually grows to an enormous size. It's all nice when it's at around 200GB of data and it only takes a few days to synchronize to the network. But think about a blockchain that is 2 TB. That is not only a huge blockchain, that would be huge for a relational DB that is stored on central server or cluster. When databases get to that size, companies divide the schema. They'll either divide it per system, per department, per branch or however it suits them best. Then they'll use some sort of business intelligence tool to make sense of all that data.
Suppose a cryptocurrency substantially replaces the US dollar and the existing banking system, and suppose we need to keep a year or so of transactions in active storage. How many transactions are full peers going to need to store? Or to say the same thing in other words, how many transactions do visa, mastercard, and the banking system do?
On 06/10/2017 2:01 PM, James A. Donald wrote:
Suppose a cryptocurrency substantially replaces the US dollar and the existing banking system, and suppose we need to keep a year or so of transactions in active storage.
How many transactions are full peers going to need to store?
Or to say the same thing in other words, how many transactions do visa, mastercard, and the banking system do?
Visa handles an average of 150 million transactions per day. Bitcoin currently handles around 350,000 transactions per day. Bitcoin has a total of 250 million transaction all time. The bitcoin blockchain is at 135GB and growing. So if Bitcoin is to reach Visa volume with it's current algorithm it will need upwards of 120GB of new storage DAILY! Bitcoin doesn't scale AT ALL. https://usa.visa.com/run-your-business/small-business-tools/retail.html https://blockchain.info/charts/n-transactions https://blockchain.info/charts/n-transactions-total?timespan=all https://blockchain.info/charts/blocks-size?timespan=all
On 10/6/2017 10:13 PM, juan wrote:
well supposedly the lightning network will add more capacity
Supposedly, LN will allow nodes to store only the transactions that concern them. Which to me sounds like a way to mess with the original double-spend prevention mechanism. What if the nodes witnessing the transactions behave badly? Wouldn't this be prone to attack? In any case I believe it is better to have a balance-out and archive mechanism rather than do transactions on a side chain. Transactions should happen in the main, wide open chain. It would make more sense to keep only balances and prune transactions older than x confirmations. Or something along those lines, I haven't given this enough thought to truly make up my mind about specifics; but the pruned transactions can be synchronized to archive nodes for historicity, research and verification purposes. Basically, 1. transactions older than x confirmations move to archive nodes and are deleted from main blockchain 2. main blockchain keeps transactions that are being confirmed until x blocks and keeps the balance amount for each public key 3. In order for this to work, we'd probably need to have a pseudo-genesis block upon each archive session. It will be like a fork but the pseudo-genesis block will have a pointer to the previous archived block. So if we're archiving 3 times a day (i.e. can be a const every x amount of blocks), this would mean that we're doing a chain fork 3 times a day. However, each time we fork we keep all the balances, unconfirmed (less than x times) transactions and confirmed transactions (equal to x confirmations) public to the new chain. Of course the transaction signatures still need to be dealt with to remove any malleability issues and the block size would need to, in my opinion, become entirely dynamic - something like how CryptoNote defines it.
On Sat, 7 Oct 2017 00:56:29 +0300 George Violaris <violarisgeorge@gmail.com> wrote:
On 10/6/2017 10:13 PM, juan wrote:
well supposedly the lightning network will add more capacity
Supposedly, LN will allow nodes to store only the transactions that concern them. Which to me sounds like a way to mess with the original double-spend prevention mechanism.
Not in theory. LN transactions done inside a channel don't show up on the blockchain, but the transactions needed to open and close the channel (or eventual dispute resolution) are 'on-chain' and that's what prevents double spending.
What if the nodes witnessing the transactions behave badly? Wouldn't this be prone to attack?
Could be. I don't know what mechanisms/incentives are there for nodes to behave well.
In any case I believe it is better to have a balance-out and archive mechanism rather than do transactions on a side chain.
But even if you have a lot more on-chain capacity you won't have fast transactions.
Transactions should happen in the main, wide open chain. It would make more sense to keep only balances and prune transactions older than x confirmations. Or something along those lines, I haven't given this enough thought to truly make up my mind about specifics; but the pruned transactions can be synchronized to archive nodes for historicity, research and verification purposes.
Basically, 1. transactions older than x confirmations move to archive nodes and are deleted from main blockchain 2. main blockchain keeps transactions that are being confirmed until x blocks and keeps the balance amount for each public key
I think there are plans to do...something about that. Spent transactions/outputs are useless, except for spying, but the argument goes : the only way to really 'verify' that you are not being tricked is to parse the whole history...
3. In order for this to work, we'd probably need to have a pseudo-genesis block upon each archive session. It will be like a fork but the pseudo-genesis block will have a pointer to the previous archived block. So if we're archiving 3 times a day (i.e. can be a const every x amount of blocks), this would mean that we're doing a chain fork 3 times a day. However, each time we fork we keep all the balances, unconfirmed (less than x times) transactions and confirmed transactions (equal to x confirmations) public to the new chain.
Of course the transaction signatures still need to be dealt with to remove any malleability issues and the block size would need to, in my opinion, become entirely dynamic - something like how CryptoNote defines it.
On 06/10/2017 21:36, George Violaris wrote:
On 06/10/2017 2:01 PM, James A. Donald wrote:
Suppose a cryptocurrency substantially replaces the US dollar and the existing banking system, and suppose we need to keep a year or so of transactions in active storage.
How many transactions are full peers going to need to store?
Or to say the same thing in other words, how many transactions do visa, mastercard, and the banking system do?
Visa handles an average of 150 million transactions per day. Bitcoin currently handles around 350,000 transactions per day.
Visa is four hundred times as fast. That is a gap we can close, though we will need to use a structure rather different than Bitcoin's
Bitcoin has a total of 250 million transaction all time. The bitcoin blockchain is at 135GB and growing. So if Bitcoin is to reach Visa volume with it's current algorithm it will need upwards of 120GB of new storage DAILY!
Assume that, instead of everyone being a peer, we have two dozen or so peers, the peers distributed among several nuclear armed jurisdictions, and each peer has a hundred million or so clients. OK, we are talking rather large peers. A terabyte of storage, a hundred dollars worth, will keep one of them going for a week. I don't think cost of storage is going to be a significant problem. Scaling, however, is the hard problem. Making enormous amounts of storage actually useful and effective is the problem. The amount of storage per client is absolutely insignificant. The amount of bandwidth per client is absolutely insignificant. Having a useful connection between enormous numbers of clients and enormous amounts of storage is the hard part.
On 10/7/2017 8:20 AM, James A. Donald wrote:
Scaling, however, is the hard problem. Making enormous amounts of storage actually useful and effective is the problem. The amount of storage per client is absolutely insignificant. The amount of bandwidth per client is absolutely insignificant. Having a useful connection between enormous numbers of clients and enormous amounts of storage is the hard part.
I believe you were the first person to actually point this out to Satoshi. He replied by saying that 100GB per day is required to be processed every day by full nodes. (https://marc.info/?l=cryptography&m=122567739309991&w=1) However I am confused by his explanation of server farms. Wouldn't at one point result to a small number of full nodes due to costs? Isn't that preventive of decentralization? I fail to understand how Satoshi would think that the entire world can connect to let's say 50 worldwide server farms and this would somehow scale and be considered decentralized. The point of decentralization is that everyone can verify all transactions. This is done by verifying each transaction against all transactions back to genesis by yourself, not by trusting 50 centralized nodes. For all we can know, in 20 years from now only banking institutions will have the capital and benefit of running full nodes. ./gv
participants (4)
-
George Violaris -
grarpamp -
James A. Donald -
juan