Live data from Hacker News

Is Zcash’s encrypted blockchain Satoshi’s vision?

cryptopotato.com

61–70 of 71 posts

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#61
post #47

Earlier quoted context omitted.

Very good summary of the issue. This is actually a solveable problem. You use a tree of spent serial numbers and non-membership proofs. This basically eliminates the over head to the network of managing serial numbers and checking for double spends. However, it requires they be stored somewhere because some of that data is needed to make non-membership proofs and update the tree. To further reduce it, keep separate s…

That doesn’t solve the issue. It just pushes the responsibility of holding all this data onto the signer instead of the validator, which is a free choice. But signers are usually more space constrained than validators. And there is no connection between privacy guarantees and this issue. I’m not sure what you’re getting at there.

It not holding all the data though. Anyone with old coins has to hold at most 2kb of data. They do have to occasionally (think every 1 to 5 years) scan all spends from that epoch to update that data or get someone to do that on their behalf. But it really does reduce the work.

As to mimblewimble: yes, there is a connection. You are trying to prune provably spent things. But to do that, you must know what was spent. Which means, if I spend a coin with you in Mimblewimble, the set of possible coins it could be is orders of magnitude smaller than the set of coins it could be in zcash or even Monero. Because these don't prune.

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#62
post #59

Earlier quoted context omitted.

Mimblewimble doesn't provide very strong privacy protections. Indeed, to a first approximation all it hides is transaction value. The aggregatable transactions only provide privacy if you assume they are generated, fully formed from nothing. Which isn't true. If they are passed around the network and things are aggregated in, than anyone observing the networking will see exactly what went in and what didn't. IF you p…

It's true that an entity like NSA would notice transactions at their point of origin, before aggregation, and could relate inputs to outputs. Reducing this linkability doesn't require a trusted party though, as MimbleWimble is compatible with the valueshuffle [0] protocol. [0] https://people.mmci.uni-saarland.de/~truffing/papers/valuesh...

You have a choice: use a trusted party (obviously bad) or pass around partial aggregates and have someone add on to them ( this is the standard proposal). Problem is, you can trivially attach to almost every full node and observe those transactions as they get broadcast around. Its not NSA level attacks, I know at least 2 blockchain analysis companies that do this in Bitcoin today.

So, against that attacker, which already exists and is live today, mimblewimble seeming provides almost no privacy.

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#63
post #34

Someone explain this part to me: > I would be happy if Zcash and Bitcoin could serve as a gateway from an unstable currency (Venezuelan Bolivar) to a stable currency (EURO/USD) How would this actually happen? Who is on the other side of this transaction? Who would want to cash out their Bitcoin in Venezuelan bolivar? I assume the Bitcoin trades that actually occur in Venezuela are for USD and black-market goods, not…

Presumably one might want to trade the BTC for bolivar to immediately spend them somewhere?

Not that I have experience in the matter, but I have heard that spending bolivar in Venezuela means waiting in long lines for goods with artificial prices, whereas you can buy whatever you want in USD.

I suspect that the bolivar/BTC trade is just a feel-good story, and the reality is that Bitcoin is not available to ordinary Venezuelans.

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#64
post #59

Earlier quoted context omitted.

It's true that an entity like NSA would notice transactions at their point of origin, before aggregation, and could relate inputs to outputs. Reducing this linkability doesn't require a trusted party though, as MimbleWimble is compatible with the valueshuffle [0] protocol. [0] https://people.mmci.uni-saarland.de/~truffing/papers/valuesh...

You have a choice: use a trusted party (obviously bad) or pass around partial aggregates and have someone add on to them ( this is the standard proposal). Problem is, you can trivially attach to almost every full node and observe those transactions as they get broadcast around. Its not NSA level attacks, I know at least 2 blockchain analysis companies that do this in Bitcoin today. So, against that attacker, which al…

Everything in a MimbleWimble chain, and even at the transaction broadcast level, look like sorted sets of uniformly random curve points. There are no amounts as you point out, but there are no addresses either.

So now, tell me what that "attack" gives you?

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#65
post #47

Earlier quoted context omitted.

That doesn’t solve the issue. It just pushes the responsibility of holding all this data onto the signer instead of the validator, which is a free choice. But signers are usually more space constrained than validators. And there is no connection between privacy guarantees and this issue. I’m not sure what you’re getting at there.

It not holding all the data though. Anyone with old coins has to hold at most 2kb of data. They do have to occasionally (think every 1 to 5 years) scan all spends from that epoch to update that data or get someone to do that on their behalf. But it really does reduce the work. As to mimblewimble: yes, there is a connection. You are trying to prune provably spent things. But to do that, you must know what was spent. W…

How do you "scan all spends from that epoch" with having those spends ("the data")?

You essentialy just said: "It's not holding all the data though, you just have to have all the data." ...?

As I pointed out elsewhere in this thread (see cousin comments) relying an an external 3rd party archival service doesn't solve the issue because either (a) you want the system decentralized so it needs to be within the signer's capability to run such a service, or (b) you don't do that and now you've introduced central points of failure and then what's the point?

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#66
post #65

Earlier quoted context omitted.

It not holding all the data though. Anyone with old coins has to hold at most 2kb of data. They do have to occasionally (think every 1 to 5 years) scan all spends from that epoch to update that data or get someone to do that on their behalf. But it really does reduce the work. As to mimblewimble: yes, there is a connection. You are trying to prune provably spent things. But to do that, you must know what was spent. W…

How do you "scan all spends from that epoch" with having those spends ("the data")? You essentialy just said: "It's not holding all the data though, you just have to have all the data." ...? As I pointed out elsewhere in this thread (see cousin comments) relying an an external 3rd party archival service doesn't solve the issue because either (a) you want the system decentralized so it needs to be within the signer's…

So the model is as follows: This network holds the last n blocks (where n is something on the order of months or years.). Spending coins within that time period is unchanged. For every coin outside of those n blocks, the user must hold about 2kb of data per coin. Every n blocks, they must scan the last n blocks before those blocks are discarded to update their state OR rely on a third party archiving service. So if n = 1 year, then oncee a year you must connect to the network and either download the years worth serial numbers from coins outside the current epoch (note that this is much smaller than the years blockchain) or just have a node scan on your behalf given your data.. If you wait longer than a year, then you are out of luck unless you find a copy.

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#67
post #65

Earlier quoted context omitted.

How do you "scan all spends from that epoch" with having those spends ("the data")? You essentialy just said: "It's not holding all the data though, you just have to have all the data." ...? As I pointed out elsewhere in this thread (see cousin comments) relying an an external 3rd party archival service doesn't solve the issue because either (a) you want the system decentralized so it needs to be within the signer's…

So the model is as follows: This network holds the last n blocks (where n is something on the order of months or years.). Spending coins within that time period is unchanged. For every coin outside of those n blocks, the user must hold about 2kb of data per coin. Every n blocks, they must scan the last n blocks before those blocks are discarded to update their state OR rely on a third party archiving service. So if n…

So users must scan the entire block chain to maintain their balance. Note that this is a stronger requirement than bitcoin has! A similar amount of data needs to be synced for on bitcoin to see if the inputs were spent, but not to make a transaction. That's the key difference. There are many applications where it makes sense to have a wallet make spends while checking block data only when it is expecting a confirmation, e.g. because its keys are HSM protected. Vending machines, for example.

Bitcoin has about 2-4k inputs per block. Let's say 3k inputs every 600 seconds. A key image size depends on the crypto being used. A super conservative lower bound on size is 256 bits per key image -- smaller than either Monero or Zcash, I believe -- as general information theory says anything less than that cannot provide 128 bits of security. That's 4GB/yr or 330MB/mo. And again, that's a minimum -- Zcash for example is 9x this number as a theoretical minimum, larger when you add protocol and serialization overhead.

That's a lot of data to suck down a pay-as-you-use-it IoT 3G connection. And that's just at bitcoin's pre-segwit average usage, not even what segwit can do or levels people think bitcoin should eventually be scaled up to. However much bitcoin capacity limits are raised in the future will directly scale up these numbers.

> rely on a third party archiving service

This is not a solution. If you allow scaling to such a degree that third party archiving services are required, then you've centralized the network. Why even use a block chain at that point?

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#68
post #67

Earlier quoted context omitted.

So the model is as follows: This network holds the last n blocks (where n is something on the order of months or years.). Spending coins within that time period is unchanged. For every coin outside of those n blocks, the user must hold about 2kb of data per coin. Every n blocks, they must scan the last n blocks before those blocks are discarded to update their state OR rely on a third party archiving service. So if n…

So users must scan the entire block chain to maintain their balance. Note that this is a stronger requirement than bitcoin has! A similar amount of data needs to be synced for on bitcoin to see if the inputs were spent, but not to make a transaction. That's the key difference. There are many applications where it makes sense to have a wallet make spends while checking block data only when it is expecting a confirmati…

The assumption isn't that the entire blockchain is stored forever, its that users who keep year old coins can 1) receive blocks (either as they are created, or in some batched process where the batch size could be as large as you like up to e.g. 1 year) and 2) store 2k of state per coin. This is weaker assumption than that of a full node in Bitcoin (which stores the entire blockchain)but obviously stronger than an SPV client which doesn't receive blocks.

And remember, this only happens for really old coins. The data from looking at Monero's anonymous Tx's (recall there was a bug that leaked spending history) is that coins are typically spent with in a week. Not just does this mean few users will pay this cost, but the cost will actually be smaller. You don't need the entire block to update the non-memership proof for a given epoch, you only need all the serial numbers from that epoch that were in that block. Thats likely a small fraction of transactions. Zcash serial numbers are 256 bits by the way.

Yes, its a cost. But it is the price you pay for strong privacy. If you can prune transactions, its because you know their outputs have been spent. Which means those outputs don't contribute to your anonymity set.

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#69

Earlier quoted context omitted.

You have a choice: use a trusted party (obviously bad) or pass around partial aggregates and have someone add on to them ( this is the standard proposal). Problem is, you can trivially attach to almost every full node and observe those transactions as they get broadcast around. Its not NSA level attacks, I know at least 2 blockchain analysis companies that do this in Bitcoin today. So, against that attacker, which al…

Everything in a MimbleWimble chain, and even at the transaction broadcast level, look like sorted sets of uniformly random curve points. There are no amounts as you point out, but there are no addresses either. So now, tell me what that "attack" gives you?

If Alice gives you a coin and then you spend it to Bob, what stops Alice and Bob from identifying that they delt with the same person? This isn't an issue of addresses or values, but the transaction graph. The only thing that hides that in mimblewimble is aggregate transactions. But again, they don't hide it if you see them assembled. To such an attacker , the transaction graph is entirely intact.

Re: Is Zcash’s encrypted blockchain Satoshi’s vision?

#70

Earlier quoted context omitted.

Everything in a MimbleWimble chain, and even at the transaction broadcast level, look like sorted sets of uniformly random curve points. There are no amounts as you point out, but there are no addresses either. So now, tell me what that "attack" gives you?

If Alice gives you a coin and then you spend it to Bob, what stops Alice and Bob from identifying that they delt with the same person? This isn't an issue of addresses or values, but the transaction graph. The only thing that hides that in mimblewimble is aggregate transactions. But again, they don't hide it if you see them assembled. To such an attacker , the transaction graph is entirely intact.

The transaction graph (apart from private aggregation) is intact to an attacker who has seen all transactions being broadcast, but can then only relate outputs that they themselves have been involved in (like Alice and Bob in your example) to real world identities. This is the great advantage of having no addresses.
Post reply on HN