From 238d00275e318eaf21994b42a596784d68a08a98 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 23 Mar 2020 16:31:39 +0000 Subject: [PATCH] ZIP 221: strengthen caveat about FlyClient security in chains with rapid difficulty adjustment. Signed-off-by: Daira Hopwood --- zip-0221.html | 5 +++-- zip-0221.rst | 8 ++++++-- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/zip-0221.html b/zip-0221.html index a6882c16..0842df2f 100644 --- a/zip-0221.html +++ b/zip-0221.html @@ -586,10 +586,11 @@ License: MIT

Given the performance of BLAKE2b, we expect this validation cost to be negligible. However, it seems prudent to benchmark potential MMR implementations during the implementation process. Should the validation cost be higher than expected, there are several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.

Generally, header commitments have no impact on privacy. However, FlyClient has additional security and privacy implications. Because FlyClient is a motivating factor for this ZIP, it seems prudent to include a brief overview. A more in-depth security analysis of FlyClient should be performed before designing a FlyClient-based light client ecosystem for Zcash.

FlyClient, like all light clients, requires a connection to a light client server. That server may collect information about client requests, and may use that information to attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and publicly verifiable, they could be shared among many light clients after the initial server interaction.

-

FlyClient proofs are probabilistic. When properly constructed, there is negligible probability that a dishonest chain commitment will be accepted by the verifier. The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block. However, these security properties have not been examined closely in chain models with rapidly adjusting difficulty.

+

FlyClient proofs are probabilistic. When properly constructed, there is negligible probability that a dishonest chain commitment will be accepted by the verifier. The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block.

+

In addition, 2 only analyses these security properties in chain models with slowly adjusting difficulty, such as Bitcoin. It leaves their analysis in chains with rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states that the FlyClient protocol provides only heuristic security guarantees in that case.

Deployment

-

This proposal will be deployed with the Heartwood network upgrade. 9

+

This proposal will be deployed with the Heartwood network upgrade. 9

Additional Reading

    diff --git a/zip-0221.rst b/zip-0221.rst index 2b0be90c..bec6ad11 100644 --- a/zip-0221.rst +++ b/zip-0221.rst @@ -711,8 +711,12 @@ probability that a dishonest chain commitment will be accepted by the verifier. security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node -and knows the genesis block. However, these security properties have not been examined -closely in chain models with rapidly adjusting difficulty. +and knows the genesis block. + +In addition, [#FlyClient]_ only analyses these security properties in chain models with +slowly adjusting difficulty, such as Bitcoin. It leaves their analysis in chains with +rapidly adjusting difficulty –such as Zcash or Ethereum– as an open problem, and states +that the FlyClient protocol provides only heuristic security guarantees in that case. Deployment