[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] 08/15: added description of optimization and DB-schema
From: |
gnunet |
Subject: |
[taler-docs] 08/15: added description of optimization and DB-schema |
Date: |
Wed, 11 Jan 2023 17:27:40 +0100 |
This is an automated email from the git hooks/post-receive script.
oec pushed a commit to branch master
in repository docs.
commit 1a65188965792a791229ecf6a039d72e9b013c0a
Author: Özgür Kesim <oec-taler@kesim.org>
AuthorDate: Tue Jan 10 18:13:30 2023 +0100
added description of optimization and DB-schema
---
design-documents/024-age-restriction.rst | 85 +++++++++++++++++++++++++++++++-
1 file changed, 84 insertions(+), 1 deletion(-)
diff --git a/design-documents/024-age-restriction.rst
b/design-documents/024-age-restriction.rst
index e216168..996e563 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
~~~~~~~~~~~~~~~~~~~~~~~
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-docs] 02/15: fix # of disclosed coins -> [n][kappa-1] array, (continued)
- [taler-docs] 02/15: fix # of disclosed coins -> [n][kappa-1] array, gnunet, 2023/01/11
- [taler-docs] 14/15: added description of how to derive cs-nonce from the coin_priv for withdraw-age, gnunet, 2023/01/11
- [taler-docs] 10/15: clearity in age withdraw reveal optimization, gnunet, 2023/01/11
- [taler-docs] 06/15: finalizing age-withdraw api, gnunet, 2023/01/11
- [taler-docs] 04/15: redo withdraw with age restriction, gnunet, 2023/01/11
- [taler-docs] 12/15: -rename id field in table, gnunet, 2023/01/11
- [taler-docs] 05/15: added ReserveAgeWithdrawTransaction to the history of a reserve, gnunet, 2023/01/11
- [taler-docs] 11/15: -mention the private keys of the derived age commitments, gnunet, 2023/01/11
- [taler-docs] 13/15: added max_age_group to the withdraw-age request, made it signed by the reserve_priv, and put into the database schema, gnunet, 2023/01/11
- [taler-docs] 07/15: -rename field in age-withdraw history, gnunet, 2023/01/11
- [taler-docs] 08/15: added description of optimization and DB-schema,
gnunet <=
- [taler-docs] 15/15: Merge branch 'age-restriction', gnunet, 2023/01/11