That’s a good question. I don’t think we’ve publicly disclosed any of the crypto-performance-improvement ideas yet. Maybe we could write a separate blog post just about that.
3 Likes
I think it is confusing because https://network.zcha.in is trying to include both “most recent 24-hour” counts and “all time” counts on the same display. @lustro: I’d suggest that you just remove the “all time” display (even though that makes the Zcash network look a lot smaller!), or move it to a separate page. I’ve heard multiple people being confused about this, including me in the past and including one of the Zcash dev team an hour ago.
Anyway, @edstewbob, the number of nodes connected to https://network.zcha.in in the last 24 hours is less than 200, apparently.
I think just a better label or description on the report would be fine.
1 Like
The global-tally objective can be achieved by applying the freshness requirement only to z-addresses, and keeping t-addresses exempt because they can be trivially tallied. Then, “hibernation” and unlimited offline storage can be achieved simply by transferring the funds into a t-address.
This doesn’t achieve the other goal, of requiring fresh software. But having funds stored in t-addresses significantly reduces the pertinent attack surface and susceptibility to incompatible upgrades. For example, decade-old funds held in a z-address may be unspendable if the zkSNARK scheme has been replaced meanwhile, but it’s hard to imagine a fork that would make plain transparent funds unspendable.
3 Likes
A new block can start being mined as soon as the hash of the previous block is known.
(There’s an attack called “selfish mining”, also applicable to Bitcoin, where a miner starts working on the next block prior to releasing the previous one. Of course then it risks the previous block not getting into the chain, depending on how long it waits. This attack isn’t very effective unless you have a high proportion of the total mining power.)
2 Likes
It also doesn’t achieve the goal of “reveal the current monetary base, i.e. excluding money controlled by lost spending keys”. I would want to refuse to honor money that was ever dormant for longer than a year, even if that money was in t-addresses the whole time.
I’m not sure that invalidating money that is in t-addresses for an indefinitely long time is actually necessary for monetary base auditing.
Edit: I slightly misread what @zooko said. Yes, if you want to exclude transparent funds held in addresses with lost keys from the audited monetary base figure, then you do need to enforce movement (or proof of knowledge of private key) of funds in t-addresses. But Bitcoin seems to manage just fine without this, as do fiat currencies for cash holdings! (Fiat coinage and notes eventually do cease being legal tender if you wait long enough, but only over periods of decades, so in practice the amount of outstanding fiat cash is only known approximately. Of course you can argue that private keys are more likely to be lost than cash, but I’m not sure that argument is strong enough to justify the disadvantages of invalidating old coins in a cryptocurrency.)
Also, you could calculate an upper bound for how much money would have been attributed to potentially lost t-address private keys, without actually requiring those funds to be moved.
3 Likes
I think you are quite right (and similarly to what @tromer suggested in this thread) that it would be possible to achieve at least some of these desiderata without sacrificing the “indefinite off-line storage” desideratum. However, the “indefinite off-line storage” desideratum is the precise opposite of the “everyone knows the current monetary base” desideratum that I want, so there’s no point in trying to find a design that can satisfy both of those two at once!
Another desideratum that I haven’t previously mentioned on this thread is a performance/scalability one: my envisioned variant of Zcash that invalidates old money doesn’t have to remember as much as a variant that promises to respect arbitrarily old private spending keys, back from the grave. Not having to remember as much can help with performance and scalability. (For both transparent and shielded addresses. Although hopefully before too long we’ll have deprecated and removed transparent addresses! At least on my envisioned “fast-evolving” branch of the blockchain.)
2 Likes
Note that that list of nodes and versions is only ones that have initially connected to network.zcha.in with the last 24 hours…once your node has been up for longer than that, it drops off the list. I have a working port of bitnodes to zcash now. Its at GitHub - radix42/znodes: znodes is currently being developed to estimate the size of the zcash network by finding all the reachable nodes in the network · but the docs need some updating, both for zcash and because the docs in the bitnodes repo weren’t complete to start with.
But znodes is crawling nodes from peer connections, and so it doesn’t pick up nodes that are behind NAT, since it can’t connect to them…hence it hasn’t picked up any zcash4win nodes, even though it has over 1000 downloads now. I know that MY test systems that are running 24/7 aren’t on public IPs 
At last count it had connections to 526 nodes on public IP addresses (it isn’t crawling nodes on TOR yet, when I get that working I’m sure the number will go up). At some point I’m going to setup a cronjob to push the json file containing node into it crawls to a public site for download.
Since the zcash network is significantly smaller than bitcoin’s, a znodes server doesn’t take nearly as many resources…I have it running on a 6 core, 24 gig of RAM machine, and that is overkill for it by quite a lot. @lustro I’ll ping you when I have that dataset publically available, you may want to integrate it into the maps on your site(s), if you don’t end up running a znodes server yourself.
2 Likes
Alternatively, you could use a network transport or connection system that provides NAT punching, such as I2P or Tor hidden services, or Magic Wormhole.
2 Likes
re: Invalidating old balances… What is the moral aspect of destroying someone’s money without offering to make them whole?
btw Thank you all for this AMA - I missed it but enjoyed reading through.
2 Likes
@Voluntary: I’m saying “I don’t accept money at my store unless that money has had continuous proof-of-liveness all along (i.e. has never lain dormant for more than a year).” It is perfectly moral for me to decide what I accept and don’t accept in payment. It would be immoral for anyone else to tell me what I could or couldn’t accept in payment.
1 Like
Ugh I just dread supporting sw on both side of the chain fork that’s gonna result, because honestly for the record I’ll be supporting a fork that honors money in cold storage, on explicit moral grounds. I know you’re fine with that kind of split, I just hope the currency survives it if it happens.
4 Likes