added description of optimization and DB-schema

1 files changed, 84 insertions, 1 deletions

diff --git a/design-documents/024-age-restriction.rst b/design-documents/024-age-restriction.rst
index e2161688..996e5638 100644
--- a/design-documents/024-age-restriction.rst
+++ b/design-documents/024-age-restriction.rst
@@ -53,7 +53,7 @@ protocol, that gives the minor/ward a 1/κ chance to raise the minimum age for
 the new coin).
 
 The proposed solution maintains the guarantees of GNU Taler with respect to
-anonymity and unlinkability.  We have published a paper 
+anonymity and unlinkability.  We have published a paper
 `Zero Knowledge Age Restriction for GNU Taler <https://link.springer.com/chapter/10.1007/978-3-031-17140-6_6>`_
 with the details.
 
@@ -291,6 +291,7 @@ NULL, but only iff the corresponding denomination (indirectly referenced via
 table ``known_coins``) has ``.age_restricted`` set to true.  This constraint
 can not be expressed reliably with SQL.
 
+
 Protocol changes
 ----------------
 
@@ -371,6 +372,88 @@ accomodate for handling multiple coins at once -- thus multiplying the amount
 of data by the amount of coins in question--, but all with the same value of
 :math:`\gamma`.
 
+The *actual* implementation of the protocol above will have a major optimization
+to keep the bandwidth usage to a minimum.  Instead of generating and sending
+the age commitment (array of public keys) for each coin, the wallet *MUST*
+derive the corresponding age commitments from the coin's private key
+:math:`c_s` itself as follows:
+
+Let :math:`m \in \{1,\ldots,M\}` be the maximum age (according to the reserve)
+that a wallet can commit to during the withdrawal.
+
+For age group :math:`a \in \{1,\ldots,m\}`, set
+
+.. math::
+             s_a &:= \text{HDKF}(c_s, \text{"age-commitment"}, a) \\
+           p_a  &:= \text{Edx25519\_generate\_private}(s_a)
+
+
+and calculate the corresponding Edx25519PublicKey as
+
+.. math::
+           q_a &:= \text{Edx25519\_public\_from\_private}(p_a)
+
+
+For age group :math:`a \in \{m,\ldots,M\}`, set
+
+.. math::
+           f_a &:= \text{HDKF}(c_s, \text{"age-factor"}, a)
+
+and calculate the corresponding Edx25519PublicKey as
+
+.. math::
+           q_a &:= \text{Edx25519\_derive\_public}(P, f_a),
+
+where :math:`P` is a published constant public key, for which the private key
+is not known to the client.
+
+Provided with the private key :math:`c_s`, ghe exchange can therefore calculate the
+age commitment :math:`\vec{q}` itself, along with the coin's public key
+:math:`C_p` and use the value of
+
+.. math::
+
+  \text{TALER\_CoinPubHashP}(C_p, \text{age\_commitment\_hash}(\vec{q}))
+
+during the verification of the original age-withdraw-commitment.
+
+
+For the withdrawal with age restriction, a sketch of the corresponding database
+schema in the exchange is given here:
+
+.. graphviz::
+
+	digraph deposit_policies {
+		rankdir = LR;
+		splines = true;
+		fontname="monospace"
+		node [
+			fontname="monospace"
+			shape=record
+		]
+
+		subgraph cluster_commitments {
+			label=<<B>withdraw_age_commitments</B>>
+			margin=20
+			commitments [
+			  label="<id>id\l|h_commitment\l|amount_with_fee_val\l|amount_with_fee_frac\l|noreveal_index\l|<res>reserve_uuid\l|reserve_sig\l|timestamp\l"
+			]
+		}
+
+		subgraph cluster_reveals {
+			label=<<B>withdraw_age_reveals</B>>
+			margin=20
+			reveals [
+			  label="freshcoin_index\l|<comm>withdraw_age_commitments_id\l|<denom>denominations_serial\l|h_coin_ev\l"
+			]
+		}
+
+		commitments:res->reserves:id [ label="n:1"; fontname="monospace"];
+		reveals:comm -> commitments:id [ label="n:1"; fontname="monospace" ];
+		reveals:denom -> denominations:id [ label="n:1"; fontname="monospace"] ;
+
+	}
+
 
 Refresh - melting phase
 ~~~~~~~~~~~~~~~~~~~~~~~