2 MB blocksize

[zookozcash]

In the Great Bitcoin Schism, both sides are converging on 2 MB blocks being okay, and the current remaining disagreements are about when to schedule a hard-fork upgrade of Bitcoin from 1 MB blocks to 2 MB blocks (sooner vs. later, before or after rolling out segwit, and possibly with some kind of user voting protocol to do "market research" about whether the users want it).

I think Zcash should start life with 2 MB blocksize. We can take the patch being maintained by Bitcoin Classic.

I've asked our Technical Advisory Board about this (in addition to asking about #764, since this and that compound with one another), and none of them raised a warning flag.

[zookozcash]

Actually, I'm not sure it's fair to say that none of them raised a warning flag. @amiller has studied scalability of blockchains recently, and he said something ambivalent about this combination (2.5 minute block intervals and 2 MB blocksize) on Slack. Assigning this ticket to @amiller to let us know if he thinks it is a bad idea.

[daira]

Remember that Zcash has significantly larger transactions when Pours are used, so we need larger blocks (or more precisely, we will need greater transaction bandwidth). The question AFAICS is whether 2MB at 2.5 minutes is enough. But it's not a big deal if we underestimate for 1.0; the reasons why so much acrimony has attached to this choice in Bitcoin seem to be mostly political rather than technical.

[Edit: I wrote this before I realised the extent of the effect of JoinSplit verification time, which is much larger than for Bitcoin or than for altcoins that have changed the maximum transaction size or target time, on block propagation delay. That may be a serious issue for blocks with a large number of JoinSplits.]

[ebfull]

I agree with @daira. Leaving the max block size alone for 1.0 leaves less room for error, and I don't think we have enough information to judge the proper course of action for that parameter at this moment anyway.

[zookozcash]

After all the extensive discussions we've had about this and #764, discussing risks involving long verification times compared to block times, I'm currently still in favor of this and #765. The risks seem uncertain, far-future, and fixable. The benefits are immediate and significant.

[defuse]

#320 is relevant when we're thinking about miner transaction processing times.

[taoeffect]

@zookozcash did you ever do any followup re that discussion we had about the impact that zk-SNARKs has on txn selection & the impact of 51% attacks? (Forgot which issue it was.)

Because if it is the case that zk-SNARKs makes a 51% attacker more impotent as far as the damage they can do (specifically, censoring txns), then mining centralization is not as significant of a concern as it is in Bitcoin, and therefore Zcash may have more breathing room as far as blocksize goes.

[ebfull]

I believe that the block size limit is a very important tool that we should wield carefully. Although it sets an upper-bound on transaction throughput, it has important implications for block propagation and network health -- important for decentralization and preventing attacks which leverage weaknesses in our construction.

We should always set parameters, especially ones related to network capacity, to values which underestimate unforseen dangers. We should not wait for a failure scenario, we should pre-empt it with conservative choices. The point of network capacity parameters is to avoid those scenarios. Further, since we plan to make aggressive hardforking a forte of the network, undershooting this property does little harm.

One way in which danger may lurk for this constant is our transaction verification time. Pours cost much more than ECDSA signatures to validate, and so blocks full of pours will propagate slowly.

• Miners might be incentivized to SPV mine blocks because they're too expensive to verify and they don't want to be left out.
• Miners employing attacks like block withholding may use varying propagation delays among blocks to optimize their strategies at the expense of all honest miners.
• There may be a disincentive for miners to include pours in their blocks since they are more likely to propagate otherwise.
• Orphan rates are higher, stretching our confidence over consensus. (This is something we seem to not want to guarantee anyway, but I thought I'd point it out.)

I believe, if anything, the limit should be lowered to match some conservative estimate for a healthy network.

[amiller]

We are still missing a definition of a healthy network, which makes it hard to decide here. How about we pick a target distribution of nodes and miners/mining pools, and go from there?
For example, a $2000 machine should be able to validate max-size blocks with a latency of 2 seconds?
Or a $20/mo VPS full node should be able to "keep up" without falling behind. This a) sets an actionable goal, and b) can relate to understandable real world consequences

[taoeffect]

We are still missing a definition of a healthy network, which makes it hard to decide here. How about we pick a target distribution of nodes and miners/mining pools, and go from there?

👍

Not only who can run the machines but also what attacks the network can tolerate (which still seems like a not fully understood question given zk-SNARKs).

In Bitcoin it's important for individuals to be able to run full nodes because of the possibility of censorship, and that puts a very clear $-value on the target cost. If because of zk-SNARKs it doesn't matter whether individuals (as opposed to businesses) can run full nodes, then you've got more overhead room.

[daira]

I absolutely want individuals to be able to run full Zcash nodes (and also act as miners). Remember, we also have transparent transactions [edit: and mixed transparent/private] which are every bit as vulnerable to censorship attacks as in Bitcoin.

[nathan-at-least]

There's a potential resource usage concern I haven't seen in any conversations yet which relates to this ticket (as well as others):

A miner needs RAM for PoW proving. A wallet needs RAM for private xfer proving. A mining wallet has a resource contention issue for RAM.

[daira]

This is marked as "in 1.0", but I don't remember us reaching consensus on it.

[daira]

Oh, I remember now: we had consensus to implement it on the testnet and ask people to try to break it.

[daira]

@nathan-at-least wrote:

A miner needs RAM for PoW proving. A wallet needs RAM for [JoinSplit] proving. A mining wallet has a resource contention issue for RAM.

This is another reason why I think we may need dynamic unloading of the JoinSplit proving key.

[daira]

I'm increasingly of the opinion that the estimates of feasible block size for Bitcoin (and for other altcoins) don't apply to us and that we should start with a conservative block size limit, maybe even less than 1 MB — but with 2.5 minute target block time. The transaction capacity will be smaller at launch than it would have been, but I think that is absolutely fine.