From 42e05529a4737df88e064f5178833e11f270d025 Mon Sep 17 00:00:00 2001 From: Eran Tromer Date: Wed, 25 Aug 2021 19:29:49 -0400 Subject: [PATCH 1/2] ZIP 307: clarify that epk is needed The current phrasing implies the 580-byte memo ciphertext suffices for detection. Clarify that the 32-byte ephemeral public key is also needed. Also added "public" to "ephemeral key" further down. --- zip-0307.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/zip-0307.rst b/zip-0307.rst index e44cf9fe..844d2414 100644 --- a/zip-0307.rst +++ b/zip-0307.rst @@ -147,13 +147,14 @@ A recipient detects their transactions by trial-decrypting this ciphertext. On a that has the entire block chain, the primary cost is computational. For light clients however, there is an additional bandwidth cost: every ciphertext on the block chain must be received from the server (or network node) the light client is connected to. This -results in a total of 580 bytes per output that must be streamed to the client. +results in a total of 580 bytes per output that must be streamed to the client (in addition +to the 32-byte ephemeral public key). However, we don't need all of that just to detect payments. The first 52 bytes of the ciphertext contain the contents and opening of the note commitment, which is all of the data needed to spend the note and to verify that the note is spendable. If we ignore the -memo and the authentication tag, we're left with a 32-byte ephemeral key, the 32-byte note -commitment, and only the first 52 bytes of the ciphertext for each output needed to +memo and the authentication tag, we're left with a 32-byte ephemeral public key, the 32-byte +note commitment, and only the first 52 bytes of the ciphertext for each output needed to decrypt, verify, and spend a note. This totals to 116 bytes per output, for an 80% reduction in bandwidth use. From 14326d0f9a9b5b1b3448456eaba88ecf353d1dc4 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 7 Sep 2021 14:46:47 +0100 Subject: [PATCH 2/2] ZIP 307: regenerate HTML. Signed-off-by: Daira Hopwood --- zip-0307.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0307.html b/zip-0307.html index b83fd737..73dad62b 100644 --- a/zip-0307.html +++ b/zip-0307.html @@ -101,8 +101,8 @@ License: MIT -

A recipient detects their transactions by trial-decrypting this ciphertext. On a full node that has the entire block chain, the primary cost is computational. For light clients however, there is an additional bandwidth cost: every ciphertext on the block chain must be received from the server (or network node) the light client is connected to. This results in a total of 580 bytes per output that must be streamed to the client.

-

However, we don't need all of that just to detect payments. The first 52 bytes of the ciphertext contain the contents and opening of the note commitment, which is all of the data needed to spend the note and to verify that the note is spendable. If we ignore the memo and the authentication tag, we're left with a 32-byte ephemeral key, the 32-byte note commitment, and only the first 52 bytes of the ciphertext for each output needed to decrypt, verify, and spend a note. This totals to 116 bytes per output, for an 80% reduction in bandwidth use.

+

A recipient detects their transactions by trial-decrypting this ciphertext. On a full node that has the entire block chain, the primary cost is computational. For light clients however, there is an additional bandwidth cost: every ciphertext on the block chain must be received from the server (or network node) the light client is connected to. This results in a total of 580 bytes per output that must be streamed to the client (in addition to the 32-byte ephemeral public key).

+

However, we don't need all of that just to detect payments. The first 52 bytes of the ciphertext contain the contents and opening of the note commitment, which is all of the data needed to spend the note and to verify that the note is spendable. If we ignore the memo and the authentication tag, we're left with a 32-byte ephemeral public key, the 32-byte note commitment, and only the first 52 bytes of the ciphertext for each output needed to decrypt, verify, and spend a note. This totals to 116 bytes per output, for an 80% reduction in bandwidth use.

However, skipping the full ciphertext means that we can no longer calculate the authentication tag for the entire ciphertext and will need to do something else to validate the integrity of the decrypted note plaintext.

Since the note commitment is sent outside the ciphertext and is authenticated by the binding signature over the entire transaction, it serves as an adequate check on the validity of the decrypted plaintext (assuming you trust the entity assembling transactions). We therefore recalculate the note commitment from the decrypted plaintext. If the recalculated commitment matches the one in the output, we accept the note as valid and spendable.