[ZIP 208] Does this allow users to *safely* conclude a transaction with less time?

[nathan-at-least]

Edit: At time of filing this ticket, this ZIP draft had not yet been merged. The draft text at the time was filed in linked here which is tracked in #200 which also has some conversation in it.

Edit by @daira: The ZIP has been published at https://zips.z.cash/zip-0208 .

Do shorter block target times allow users to safely conclude transactions with a shorter wait?

Concretely, is it safe to recommend they wait for the same number of confirmations, 10, both before and after this change takes place?

One security analysis models the opportunity cost of an attack to rollback blocks, where the USD-per-time of mining honestly provides a lower bound on opportunity cost. Since the proposed change strives to maintain the same ZEC-per-time curve, it would not lower "safe transaction conclusion time" for users, even though more blocks are expected to be confirmed.

A different analysis is that an attacker with a given capacity of the mining network, the chance to rollback K blocks remains constant regardless of block target time (ignoring network propagation, block validation time, and other realistic details). In that analysis, the same block confirmation depth should provide the same security with shorter block target time, and therefore this change would reduce the "safe transaction conclusion time".

Is there a better or more comprehensive security analysis about this?

[zebambam]

Yes. I got a response from NCC on the topic:

"ZIP 208 indeed starts with a “Motivation” section that includes: “reduced latency for considering transactions to be sufficiently confirmed”.

I considered this; in my opinion, that claim is true (with some caveats).

The “confirmation height” is not part of the consensus rules. It is meant to counteract two scenarios:

• accidental forking, when two miners find the next block at about the same time;
• adversarial 51% attack.

In the first case, two candidates for the next block live in the network, and each miner will use one or the other as new chain head, depending on which one it received first. Such things happen randomly, and are normally resolved at the next block; however, the same situation may arise again on the next block. If it happens with probability P for each new block, then such a fork may reach depth h only with probability Ph. The confirmation height is about enforcing a h large enough that Ph is negligible.

Probability P is basically the chance of a miner finding a block within the network average latency for propagation of a block just mined. If we suppose that it takes 5 seconds for a new block to percolate through the network, and that there is a new block every 150 seconds (on average), then P = 5/150, and a confirmation height h = 6 will mean that a Ph is about 1 over 729 million, i.e. not a lot. With the spacing reduced to 75 seconds, probability P is doubled; however, doubling the confirmation height h would be overkill. With these figures, bumping up h from 6 to 8 would make the new Ph even lower than the previous one. Eight blocks at 75 seconds per block is less time than six blocks at 150 seconds per block, thus the latency for confirmation is indeed reduced. It is not halved, but it is still reduced. It may be worth adding some note somewhere that the confirmation height could be slightly increased, but that height is not part of the consensus rules or the protocol; it’s a convention local to each client.

One may add that even when that kind of temporary fork occurs, the transactions are still propagated in the network, and all transactions from the abandoned branch will be included in the other branch too. For a transient fork to induce adverse effects, the occurrence of the fork must somehow be predicted by the attacker: for instance, the sender who wants to renege on his payment must send at the same time a concurrent transaction onto other peers and hope that:

• the normal, “honest” transaction will go into the next block, as seen by the victim;
• there will be a transient fork up to the confirmation height;
• the other branch, to which the fork will be ultimately solved, will use the other transaction (the one that sends the money not to the victim, but to another address of the attacker).

Thus, even a transient fork is not enough for the attack to work.

In the case of a 51% attack, the block spacing does not matter much. An attacker with less than 50% of the total mining power cannot win the race in the long term, but an attacker with close to 50% power may be “lucky”. Let’s suppose that an attacker controls a proportion r of the network. The attacker wants to renege on transactions, i.e. rollback the chain for more than h blocks; if r > 0.5, then the attacker can start his own branch and that branch will ultimately catch up with the normal one. If r < 0.5, then the attacker will not catch up in the long run, but may be lucky enough in the short term. The attacker wants to win a race with the rest of the network: the attacker needs to build a chain of k > h blocks faster than the rest of the network, with h being the confirmation height. The exact expression of the success rate of the attacker is complicated; the important points are:

• Success rate decreases rather steeply when h rises; i.e. the attacker needs a lot more luck if the confirmation rate is higher.
• Success rate depends on the mining power ratio, not on the average block spacing.

What the reduced block spacing changes is the cost for the attacker. Indeed, in the attack, the attacker invests his mining power into making an alternate branch; if the attack fails (the alternative branch never catches up with the normal one), then all the mining effort is lost. Thus, the attack cost really is F*C, where F is the probability of attack failure and C is the total value of the mining fees that the attacker could collect by working on the normal branch. Halving the target spacing does not change F, but it halves the cost C since the attack will mine the same number of blocks, and the blocks have half the value. This, if the attack cost is halved, it may become worthwhile for the attacker.

Again, a slight increase of the confirmation height h (not a doubling) should restore the original balance. I have not made the exact computation, but since the success rate is basically exponential, I expect that, again, bumping the height from 6 to 8 would be more than enough.

Summary: the reduced target rate implies an increase in the probability of attacks and adverse events related to the confirmation height, which can be counterbalanced with a slight increase of that height. Even with such a slight increase, the latency is indeed reduced.
The confirmation height is not part of the consensus rules or protocol, but it may be beneficial to publish some guidance somewhere, and indeed to update that guidance with regards to the reduced target spacing.
"

[zebambam]

@daira have you done any further analysis on this?

[defuse]

If the attacker has eclipsed a victim, then they don't need to compete against other miners to get the victim to accept their blocks, and so NCC's F becomes independent of h. If the victim waits for N confirmations, then the cost to attack them while they are eclipsed is the cost to mine N blocks, so if the victim doesn't double N when Blossom activates, the cost to attack them this way decreases.

Strawman proposal: A transaction is confirmed when it has 10+K confirmations and the total value of the miners' reward in those confirming blocks is greater than the value of the transaction.