taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

math typesetting

Browse Source
This commit is contained in:
Christian Grothoff 2021-10-06 13:24:56 +02:00
parent 05539893ef
commit e168920702
No known key found for this signature in database
GPG Key ID: 939E6BE1E29FC3CC
1 changed files with 236 additions and 267 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

311
doc/cbdc-es/cbdc-es.tex
View File

@ -1,4 +1,4 @@
\documentclass{article}
\documentclass[10pt,spanish]{article}
\usepackage[a4paper,
top=2cm,
bottom=2cm,
@ -6,57 +6,33 @@ includefoot,
left=3cm,
right=2cm,
footskip=1cm]{geometry}
%\usepackage{lastpage} % enables \pageref{LastPage}
%\cfoot*{\normalfont Page \pagemark{} of \normalfont \pageref{LastPage}}
% Adjust variables in brackets for special indentation
%\setlength{\parindent}{0pt}
%\setlength{\parskip}{0.5ex plus 1pt minus 1pt}
% Set fonts for a nicer PDF view
\usepackage{url}
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{}
\usepackage{graphicx}
\usepackage{mathpazo}
\usepackage{amsmath}
%\usepackage{newtxmath}
\usepackage{mathptmx}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{color}
\usepackage[hidelinks]{hyperref}
\clubpenalty=10000
\widowpenalty=10000
\displaywidowpenalty=10000
\brokenpenalty=10000
\doublehyphendemerits=10000
\finalhyphendemerits=5000
\tolerance=10000
\urlstyle{same}
\begin{document}
\title{Cómo Emitir una Moneda Digital del Banco Central*}
\author{David Chaum \textsuperscript{a},
Christian Grothoff \textsuperscript{b}
y Thomas Moser \textsuperscript{c}}
\date{\today}
\author{David Chaum\footnote{david@chaum.com} \\
xx Network \and
Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\
Universidad de Ciencias Aplicadas de Berna y Proyecto GNU \and
Thomas Moser\footnote{thomas.moser@snb.ch}\\
Banco Nacional de Suiza}
\date{Primera versión: mayo 2020}
\maketitle
\begin{center} \textsuperscript{a} xx Network,
\textsuperscript{b} Universidad de Ciencias Aplicadas de Berna y Proyecto GNU,
\textsuperscript{c} Banco Nacional de Suiza
\end{center}
\renewcommand{\abstractname}{Resumen}
\renewcommand{\refname}{Referencias}
\vspace{20pt}
\begin{center}
\vspace{20pt}
\textbf{Resumen}
\end{center}
\emph{
\begin{abstract}% [Resumen]
Con la aparición de Bitcoin y monedas estables propuestas recientemente
por grandes empresas tecnológicas como Diem (antes Libra), los bancos
centrales se enfrentan a la creciente competencia de particulares que
@ -73,18 +49,17 @@ reglamentarios de modo convincente y ofrecer un nivel de protección de
resistencia cuántica contra los riesgos sistémicos que amenazan la
privacidad. Ni la política monetaria ni la estabilidad financiera se
verían materialmente afectadas porque una CBDC con este diseño
replicaría el efectivo físico en lugar de los depósitos bancarios.}
\vspace{20pt}
replicaría el efectivo físico en lugar de los depósitos bancarios. \\
JEL: E42, E51, E52, E58, G2
\newline
\newline
\\
Keywords: Monedas digitales, banco central, CBDC, firmas ciegas, monedas
estables
\end{abstract}
\vspace{20pt}
\newline
* David Chaum (david@chaum.com), Christian Grothoff (christian.grothoff@bfh.ch),
Thomas Moser (thomas.moser@snb.ch).
\newline
\vspace{20pt}
\section*{Agradecimientos}
Agradecemos a Michael Barczay, Roman Baumann, Morten Bech, Nicolas Cuche,
Florian Dold, Andreas Fuster, Stefan Kügel, Benjamin Müller, Dirk Niepelt,
Oliver Sigrist, Richard Stallman, Andreas Wehrli, y tres colaboradores
@ -94,13 +69,13 @@ documento pertenecen estrictamente a los autores. No reflejan
necesariamente los puntos de vista del Banco Nacional de Suiza (BNS). El
BNS no asume ninguna responsabilidad por errores u omisiones ni por la
exactitud de la información contenida en este documento.
\vspace{20pt}
\newline
{Primera versión: mayo 2020}
Traducción: Javier Sepulveda y Dora Scilipoti (verano 2021)
\newpage
\hypertarget{introducciuxf3n}{%
\section{\texorpdfstring{ \textbf{Introducción}}{1. Introducción}}
\section{Introducción}
\label{1.-introducciuxf3n}}
Desde la aparición de los ordenadores personales en los años ochenta, y
@ -221,9 +196,7 @@ consideraciones políticas y normativas (5) y trabajos relacionados (6);
en fin, concluimos (7).
\hypertarget{quuxe9-es-el-dinero-del-banco-central}{%
\section{\texorpdfstring{ \textbf{¿Qué es el dinero del banco central?}}
{2. ¿Qué es el dinero del banco central?}}
\label{2.-quuxe9-es-el-dinero-del-banco-central}}
\section{¿Qué es el dinero del banco central?} \label{2.-quuxe9-es-el-dinero-del-banco-central}}
El dinero es un activo que puede ser usado para comprar bienes y
servicios. Para ser considerado dinero, este activo debe ser aceptado
@ -403,9 +376,7 @@ regulan adecuadamente. Sin embargo, la disponibilidad de CBDC limitaría
significativamente su utilidad.
\hypertarget{diseuxf1os-simplistas-de-cbdc}{%
\section{\texorpdfstring{ \textbf{Diseños simplistas de CBDC}}
{3. Diseños simplistas de CBDC}}
\label{3.-diseuxf1os-simplistas-de-cbdc}}
\section{Diseños simplistas de CBDC} \label{3.-diseuxf1os-simplistas-de-cbdc}}
Como se ha señalado, una CBDC sería una obligación del banco central.
Dos posibles diseños que se analizan en la literatura son: (a) una CBDC
@ -567,19 +538,18 @@ pista de los clientes, lo cual no es compatible con la privacidad de la
transacción.
\hypertarget{diseuxf1o-de-cbdc-basado-en-tokens-para-salvaguardar-la-privacidad}{%
\section{\texorpdfstring{ \textbf{Diseño de CBDC basado en tokens para salvaguardar la
privacidad}}{4. Diseño de CBDC basado en tokens para salvaguardar la
privacidad}}
\section{Diseño de CBDC basado en tokens para salvaguardar la
privacidad}
\label{4.-diseuxf1o-de-cbdc-basado-en-tokens-para-salvaguardar-la-privacidad}}
La CBDC que se propone aquí es de tipo "solo software", simplemente una
aplicación para teléfonos inteligentes que no requiere ningún hardware
adicional por parte de los usuarios. La CBDC se basa en eCash y GNU
Taler. Taler es parte del Proyecto GNU, cuyo fundador, Richard Stallman,
acuñó el término "Software Libre", actualmente denominado "Software
Libre y de Código Abierto" (Free/Libre Open Source Software --
acuñó el término \emph{Software Libre}, actualmente denominado \emph{Software
Libre y de Código Abierto} (Free/Libre Open Source Software --
FLOSS).\footnote{Para más información sobre GNU, véase
https://www.gnu.org y Stallman (1985). GNU Taler se publica
\url{https://www.gnu.org} y Stallman (1985). GNU Taler se publica
gratuitamente bajo la Licencia Pública General Affero del Proyecto
GNU. Otros programas del Proyecto GNU populares entre los economistas
son «R» y ``GNU Regression, Econometrics and Time-series Library''
@ -622,7 +592,7 @@ colaboración para la comunicación por Internet: ``El desarrollo de
código abierto puede proporcionar confiabilidad de que el código está
escrito para asegurar las mejores prácticas de programación y no es
probable que introduzca vulnerabilidades o debilidades que puedan
poner en riesgo a los usuarios y los datos '' (U / OO / 134598-20).}
poner en riesgo a los usuarios y los datos '' (U/OO/134598-20).}
En esta nuestra arquitectura que proponemos todas las interacciones del
consumidor y el comerciante son con bancos comerciales. Sin embargo, la
@ -697,28 +667,28 @@ consulte Boneh (1999).} Sin embargo, en principio se puede utilizar
cualquier esquema de firma criptográfica (DSA, ECDSA, EdDSA, RSA, etc.).
Para generar las claves RSA, el firmante elige primero dos grandes e
independientes números primos \(p\) y \(q\) y calcula \(n = \emph{pq}\)
independientes números primos $p$ y $q$ y calcula $n = \emph{pq}$
así como la función totient de Euler
\(\phi\left( n \right) = \left( p - 1 \right)\left( q - 1 \right)\).
Entonces, cualquier \(e\) con \(1 < e < \phi\left( n \right)\) y
\(\emph{gcd}\left( e,\phi\left( n \right) \right) = 1\) se puede usar para
definir una clave pública \(\left( e,n \right)\). La condición de que el
mayor común divisor (greatest common divisor - \emph{gcd}) de \(e\) y
\(\phi\left( n \right)\) tiene que ser 1 (p. ej., que deben ser
$\phi(n) = (p - 1)(q - 1)$.
Entonces, cualquier $e$ con $1 < e < \phi(n)$ y
$\gcd(e, \phi(n)) = 1$ se puede usar para
definir una clave pública $(e,n)$. La condición de que el
mayor común divisor (greatest common divisor - $\gcd$) de $e$ y
$\phi(n)$ tiene que ser 1 (p. ej., que deben ser
relativamente primos) asegura que la inversa de
\(e \hspace*{1pt} \text{mod} \hspace*{1pt} \phi\left( n \right)\) existe.
$e \mod \phi(n)$ existe.
Esta inversa es la
correspondiente clave privada \emph{d}. Dado \(\phi\left( n \right)\), la clave
privada \emph{d} se puede calcular usando el algoritmo extendido
correspondiente clave privada $d$. Dado $\phi(n)$, la clave
privada $d$ se puede calcular usando el algoritmo extendido
Euclídeo de modo que
\(d \bullet e \equiv 1 \hspace*{1pt} \text{mod} \hspace*{1pt} \phi\left( n \right)\).
$d \cdot e \equiv 1 \mod \phi(n)$.
Dada la clave privada \emph{d} y la clave pública (\emph{e, n}), una firma simple RSA
\emph{s} sobre un mensaje \emph{m} es
\(s \equiv m^{d} \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
Dada la clave privada $d$ y la clave pública $(e, n)$, una firma simple RSA
$s$ sobre un mensaje $m$ es
$s \equiv m^{d} \mod n$.
Para verificar la firma, se calcula
\(m' \equiv s^{e} \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
Si \(m'\) y \emph{m} coinciden, la firma es válida, lo que prueba que el
$m' \equiv s^{e} \mod n$.
Si $m'$ y $m$ coinciden, la firma es válida, lo que prueba que el
mensaje fue firmado con la clave privada que pertenece a la clave
publica de verificación (autenticación de mensaje) y que ese mensaje no
ha sido cambiado en tránsito (integridad de mensaje). En la práctica,
@ -728,7 +698,7 @@ mensajes, que son identificadores únicos y cortos para los mensajes.
Firmar un hash corto es mucho más rápido que firmar un mensaje largo, y
la mayoría de los algoritmos de firma solo funcionan con entradas
relativamente cortas.\footnote{En el caso del criptosistema RSA el
límite de la longitud es \(\log_{2}n\) bits.}
límite de la longitud es $\log_{2}n$ bits.}
\emph{Firmas ciegas.} Usamos firmas ciegas, introducidas por Chaum
(1983), para proteger la privacidad de los compradores. Una firma ciega
@ -748,38 +718,38 @@ privacidad incluso contra ataques informáticos cuánticos. El banco
central, por su parte, establece múltiples denominaciones de pares de
claves disponibles para realizar la firma ciega de monedas con
diferentes valores, y publica/provee las correspondientes claves
públicas \emph{(e, n)} para estos valores.
públicas $(e, n)$ para estos valores.
Sea \(f\) el valor hash de una moneda y por tanto un identificador único
Sea $f$ el valor hash de una moneda y por tanto un identificador único
para esta moneda. El cliente que retira la moneda primero genera una
factor ciego aleatorio \(b\) y calcula
\(f' \equiv fb^{e} \hspace*{1pt} \text{mod} \hspace*{1pt} n\)
factor ciego aleatorio $b$ y calcula
$f' \equiv fb^{e} \mod n$
con la clave pública del banco central para ese valor.
La moneda cegada \(f'\) se transmite luego
al banco central para ser firmada. El banco central firma \(f'\) con su
clave privada \(d\) calculando la firma ciega
\(s' \equiv \left( f' \right)^{d} \hspace*{1pt} \text{mod} \hspace*{1pt} n\),
añade la firma \(s'\) a la moneda cegada \(f'\) y devuelve el par
\(\left( s',f' \right)\) al cliente.
La moneda cegada $f'$ se transmite luego
al banco central para ser firmada. El banco central firma $f'$ con su
clave privada $d$ calculando la firma ciega
$s' \equiv \left(f' \right)^{d} \mod n$,
añade la firma $s'$ a la moneda cegada $f'$ y devuelve el par
$(s',f')$ al cliente.
El cliente puede entonces des-cegar la firma calculando
\(s \equiv s'b^{- 1} \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
$s \equiv s'b^{- 1} \mod n$.
Esto funciona porque
\(\left( f' \right)^{d} = f^{d}b^{\text{ed}} = f^{d}b\) y, así,
multiplicar \(s'\) con \(b^{- 1}\) produce \(f^{d}\), que es una firma RSA
válida sobre \(f\) como antes:
\(s^{e} \equiv f^{\text{de}} \equiv f \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
$\left( f' \right)^{d} = f^{d}b^{\text{ed}} = f^{d}b$ y, así,
multiplicar $s'$ con $b^{- 1}$ produce $f^{d}$, que es una firma RSA
válida sobre $f$ como antes:
$s^{e} \equiv f^{\text{de}} \equiv f \mod n$.
En la propuesta original de Chaum, las monedas eran solo tokens. Sin
embargo, nosotros queremos que los consumidores puedan realizar
contratos usando firmas digitales. Para lograrlo, cuando una billetera
digital retira una moneda, primero crea una clave privada aleatoria
\(c\) y calcula la correspondiente clave publica \(C\) de esta moneda
$c$ y calcula la correspondiente clave publica $C$ de esta moneda
para crear firmas digitales con esquemas de firma criptográfica
regulares (como DSA, ECDSA, EdDSA e RSA). Entonces, se deriva \(f\)
usando una hash criptográfica de la clave pública \(C\), que luego es
regulares (como DSA, ECDSA, EdDSA, and RSA). Entonces, se deriva $f$
usando una hash criptográfica de la clave pública $C$, que luego es
firmada en modalidad ciega por el banco central (usando un factor
aleatorio ciego actualizado para cada moneda). Ahora el cliente puede
usar \(c\) para firmar compras electrónicamente, gastando así la moneda.
usar $c$ para firmar compras electrónicamente, gastando así la moneda.
Como se ha señalado anteriormente, el banco central establecería pares
de claves para los diferentes valores de las monedas y publicaría las
@ -806,7 +776,7 @@ central puede descartar entradas vencidas y no tiene que almacenar y
buscar una lista siempre creciente de monedas (gastadas) para detectar
el doble gasto. Segundo, reduce los riesgos de seguridad porque el banco
central no tiene que preocuparse sobre ataques contra sus claves
(\emph{d}) de denominación (privadas) vencidas. Además , incluso si una
($d$) de denominación (privadas) vencidas. Además , incluso si una
clave privada se ve comprometida, el tiempo durante el cual el atacante
puede usar la clave es limitado. Además cobrar una comisión por el
cambio permitiría al banco central implementar tasas de interés
@ -833,22 +803,21 @@ intercambio justo en sistemas tradicionales de efectivo electrónico.
La construcción matemática más común para un protocolo de intercambio de
claves es la construcción Diffie-Hellman (Diffie y Hellman 1976). Esta
permite que dos partes puedan derivar una clave secreta compartida. Para
hacerlo, comparten dos parámetros del dominio \emph{p} y \emph{g}, que
pueden ser públicos, donde \emph{p} es un número primo grande y \emph{g}
es una raíz primitiva módulo \emph{p}.\footnote{Un entero \emph{g} es una raíz
primitiva módulo \emph{p} si para cada entero \emph{a} coprimo a \emph{p} hay
algún entero \emph{k} para el cual
\(g^{k} \equiv a\left( \hspace*{1pt} \text{mod} \hspace*{1pt} p \right)\).
En la práctica, \emph{g} deberia ser tal raíz primitiva \emph{p-1}, que se
hacerlo, comparten dos parámetros del dominio $p$ y $g$, que
pueden ser públicos, donde $p$ es un número primo grande y $g$
es una raíz primitiva módulo $p$.\footnote{Un entero $g$ es una raíz
primitiva módulo $p$ si para cada entero $a$ coprimo a $p$ hay
algún entero $k$ para el cual
$g^k \equiv a \mod p$.
En la práctica, $g$ deberia ser tal raíz primitiva $p-1$, que se
llama también generador, para prevenir ataques de subgrupo tales como ataques
Pohlig-Hellman (véase Lim y Pil, 1997).} Ahora, las dos partes eligen sus claves
privadas \emph{a} y \emph{b}, que son dos números enteros grandes. Con estas claves
privadas y los parámetros del dominio, generan sus respectivas claves
públicas \(A \equiv g^{a} \hspace*{1pt} \text{mod} \hspace*{1pt} p\) y
\(B \equiv g^{b} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
públicas $A \equiv g^{a} \mod p$ y $B \equiv g^{b} \mod p$.
Cada una de las partes ahora puede usar su propia clave privada y la
clave pública de la otra parte para calcular la clave secreta compartida
\(k \equiv \left( g^{b} \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
$k \equiv \left( g \middle| b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.
\footnote{El mismo mecanismo también se podría usar para garantizar que
las monedas no se transfieran a un tercero durante el retiro. Para
lograr esto, los consumidores tendrían que salvaguardar una clave de
@ -863,74 +832,74 @@ riesgo limitado en las transferencias a terceros al retirar monedas,
no está claro si esta mitigación sería una buena compensación.}
Para obtener el cambio (también llamado ``vuelto''), el cliente empieza
con la clave privada de la moneda \emph{c}. gastada parcialmente. Sea \emph{C} la
con la clave privada de la moneda c. gastada parcialmente. Sea C la
correspondiente clave pública, p. ej.
\(C = g^{c} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
$C = g^{c} \mod p$.
Cuando la moneda se gastó parcialmente, el banco central grabó en su base de
datos la transacción en la que se incluye a \emph{C}. Para simplificar, daremos
datos la transacción en la que se incluye a C. Para simplificar, daremos
por sentado que existe una denominación que coincide exactamente con el
valor residual. De no ser así, se puede simplemente ejecutar
repetidamente el protocolo de cambio hasta obtener todo el cambio
necesario. Sea \(\left( e,n \right)\) la clave de denominación para el
necesario. Sea $(e,n)$ la clave de denominación para el
cambio que se tiene que emitir.
Para obtener el cambio, el cliente primero crea \(\kappa\) claves de
transferencia privada \(t_{i}\) para
\(i \in \left\{ 1,\ldots,\kappa \right\}\) y calcula las
correspondientes claves públicas \(T_{i}\). Estas claves de
transferencia \(\kappa\) son simplemente pares de claves pública-privada
Para obtener el cambio, el cliente primero crea $\kappa$ claves de
transferencia privada $t_{i}$ para
$i \in \left\{ 1,\ldots,\kappa \right\}$ y calcula las
correspondientes claves públicas $T_{i}$. Estas claves de
transferencia $\kappa$ son simplemente pares de claves pública-privada
que permiten al cliente ejecutar localmente el protocolo de intercambio
de claves -- con el cliente jugando en ambos lados -- \(\kappa\) veces
entre \emph{c} y cada \(t_{i}\). Si se usa Diffie-Hellman para el protocolo de
de claves -- con el cliente jugando en ambos lados -- $\kappa$ veces
entre $c$ y cada $t_{i}$. Si se usa Diffie-Hellman para el protocolo de
intercambio de claves, tendremos
\(T_{i} \equiv g^{t_{i}} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
$T_{i} \equiv g^{t_{i}} \mod p$.
El resultado son tres secretos de transferencia
\(K_{i} \equiv \emph{KX}\left( c,t_{i} \right)\). El protocolo de
$K_{i} \equiv \emph{KX}(c,t_{i})$. El protocolo de
intercambio de claves se puede usar de diferentes maneras para llegar al
mismo valor
\(K_{i} \equiv \emph{KX}\left( C,t_{i} \right) = \emph{KX}\left( c,T_{i} \right)\).
Dada \(K_{i}\), el cliente usa una función criptográfica hash \emph{H} para
$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$.
Dada $K_{i}$, el cliente usa una función criptográfica hash H para
derivar valores
\(\left( b_{i},c_{i} \right) \equiv H\left( K_{i} \right)\), donde
\(b_{i}\) es un factor ciego válido para la clave de denominación
\(\left( e,n \right)\) y \(c_{i}\) es una clave privada para obtener la
moneda recién creada como cambio. \(c_{i}\) debe ser adecuada tanto para
$(b_{i},c_{i}) \equiv H(K_{i})$, donde
$b_{i}$ es un factor ciego válido para la clave de denominación
$(e,n)$ y $c_{i}$ es una clave privada para obtener la
moneda recién creada como cambio. $c_{i}$ debe ser adecuada tanto para
crear firmas criptográficas como para su futuro uso con el protocolo de
intercambio de claves (como \emph{c}, para obtener cambio a partir del cambio).
Sea \(C_{i}\) la clave pública correspondiente a \(c_{i}\). El cliente
intercambio de claves (como $c$, para obtener cambio a partir del cambio).
Sea $C_{i}$ la clave pública correspondiente a $c_{i}$. El cliente
solicita entonces al banco central que cree una firma ciega sobre
\(C_{i}\) para \(i \in \left\{ 1,\ldots,\kappa \right\}\).\footnote
$C_{i}$ para $i \in \{ 1,\ldots,\kappa\}$. \footnote
{Si se usara el criptosistema RSA para firmas ciegas, usaríamos
\(f \equiv \emph{FDH}_{n}\left( C_{i} \right)\), donde
\(\emph{FDH}_{n}\left( \right)\) es el hash de dominio completo sobre
el dominio \emph{n}.} En esta petición, el cliente también se compromete a
las claves públicas \(T_{i}\). La petición es autorizada usando una
firma hecha con la clave privada \emph{c}.
$f \equiv \emph{FDH}_{n}(C_{i})$, donde
$\emph{FDH}_{n}()$ es el hash de dominio completo sobre
el dominio $n$.} En esta petición, el cliente también se compromete a
las claves públicas $T_{i}$. La petición es autorizada usando una
firma hecha con la clave privada $c$.
En lugar de devolver directamente la firma ciega, el banco central
primero desafía al cliente para comprobar que el cliente haya usado
correctamente la construcción mencionada anteriormente proveyendo
\(\gamma \in \left\{ 1,\ldots,\kappa \right\}\). El cliente debe
entonces revelar al banco central la \(t_{i}\) para \(i \neq \gamma\) .
$\gamma \in \left\{ 1,\ldots,\kappa \right\}$. El cliente debe
entonces revelar al banco central la $t_{i}$ para $i \neq \gamma$ .
El banco central puede entonces calcular
\(K_{i} \equiv \emph{KX}\left(C,t_{i} \right)\) y derivar los valores
de \(\left( b_{i},c_{i} \right)\). Si para todas las \(i \neq \gamma\)
la \(t_{i}\) provista demuestra que el cliente usó la construcción
$K_{i} \equiv \emph{KX}(C,t_{i})$ y derivar los valores
de $(b_{i},c_{i})$. Si para todas las $i \neq \gamma$
la $t_{i}$ provista demuestra que el cliente usó la construcción
correctamente, el banco central devuelve la firma ciega sobre
\(C_{\gamma}\). Si el cliente no provee una prueba correcta, se pierde
$C_{\gamma}$. Si el cliente no provee una prueba correcta, se pierde
el valor residual de la moneda original. Esto penaliza efectivamente a
quienes intentan evadir la transparencia de sus ingresos con una tasa de
impuestos estimada de \(1 - \frac{1}{\kappa}\).
impuestos estimada de $1 - \frac{1}{\kappa}$.
Para evitar que un cliente conspire con un comerciante que está tratando
de ocultar sus ingresos, el banco central permite que cualquiera que
conozca \emph{C} pueda obtener, en cualquier momento, los valores de
\(T_{\gamma}\) y las correspondientes firmas ciegas de todas las monedas
vinculadas a la moneda original \emph{C}. Esto permite que el propietario de la
moneda original -- que conoce \emph{c} -- calcule
\(K_{\gamma} \equiv \emph{KX}\left( c,T_{\gamma} \right)\) y, a partir de
allí, pueda derivar \(\left( b_{i},c_{i} \right)\) y descifrar la firma
conozca $C$ pueda obtener, en cualquier momento, los valores de
$T_{\gamma}$ y las correspondientes firmas ciegas de todas las monedas
vinculadas a la moneda original $C$. Esto permite que el propietario de la
moneda original -- que conoce $c$ -- calcule
$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$ y, a partir de
allí, pueda derivar $(b_{i},c_{i})$ y descifrar la firma
ciega. En consecuencia, un comerciante que oculte sus ingresos de este
modo formaría básicamente una unión económica limitada con el cliente en
lugar de obtener un control exclusivo.
@ -950,29 +919,29 @@ automático. La transacción entre el banco comercial del usuario y el
banco central tiene lugar en segundo plano. El procedimiento para
retirar CBDC sería como se muestra en la Figura 1.
\includegraphics[width=6.13681in,height=4.60208in]{taler_figure_1_dora_SPANISH.jpg}
\includegraphics[width=\textwidth]{taler_figure_1_dora_SPANISH.jpg}
Un cliente (1) proporciona autenticación a su banco comercial usando la
autenticación respectiva del banco comercial y los procedimientos de
autorización. A continuación, el teléfono (u ordenador) del cliente
obtiene la clave de denominación \emph{(e, n)} provista por el banco central
obtiene la clave de denominación (e, n) provista por el banco central
para ese valor; calcula entonces (2) un par de claves para una moneda,
con la clave privada \emph{c} y la clave pública \emph{C}, y elige un factor de cegado
\emph{b}. A la clave pública de la moneda se le aplica una función hash
(→ \emph{f}) y es cegada (→ \(f'\)). A continuación, (3) el teléfono
del cliente envía \(f'\) junto con una autorización para retirar la
con la clave privada c y la clave pública C, y elige un factor de cegado
$b$. A la clave pública de la moneda se le aplica una función hash
($\to$ $f$) y es cegada ($\to$ $f'$). A continuación, (3) el teléfono
del cliente envía $f'$ junto con una autorización para retirar la
moneda y debitar de la cuenta del cliente en el banco comercial a través
de un canal seguro establecido. El banco comercial entonces (4) debita
la cantidad en la cuenta de depósito del cliente, (5) autoriza
la cantidad en la cuenta de depósito del cliente , (5) autoriza
digitalmente la petición con la propia firma digital de su sucursal
bancaria y reenvía la petición y la moneda cegada al banco central para
su firma. El banco central (6) deduce el valor de la moneda en la cuenta
del banco comercial, firma la moneda de forma ciega con la clave privada
del banco central para el valor respectivo, y (7) devuelve la firma
ciega \emph{s'} al banco comercial. (8) reenvía la firma ciega \emph{s'}
ciega $s'$ al banco comercial. (8) reenvía la firma ciega $s'$
a la billetera electrónica del cliente. Finalmente, el teléfono del
cliente (9) usa \emph{b} para descifrar la firma (→ \emph{f}) y almacena la
moneda recién acuñada \emph{(c, s)}.
cliente (9) usa b para descifrar la firma ($\to$ $f$) y almacena la
moneda recién acuñada (c, s).
Cuando se gastan CBDC, el proceso es análogo a pagar al vendedor en
efectivo. Sin embargo, para asegurar el acuerdo, el vendedor debe
@ -981,14 +950,14 @@ Figura 2.
Un cliente y un vendedor negocian un contrato comercial, y (1) el
cliente usa una moneda electrónica para firmar el contrato o factura de
venta con la clave privada \emph{c} de la moneda y transmite la firma al
venta con la clave privada c de la moneda y transmite la firma al
vendedor. La firma de una moneda en un contrato con una moneda válida es
una instrucción del cliente para pagar al vendedor que es identificado
por la cuenta bancaria en el contrato. Los clientes pueden firmar
contratos con múltiples monedas en caso de que una sola moneda fuera
insuficiente para pagar la cantidad total. El vendedor (2) valida
entonces la firma de la moneda sobre el contrato y la firma s del banco
central sobre \emph{f} que corresponde a la \emph{C} de la moneda con las
central sobre $f$ que corresponde a la C de la moneda con las
respectivas claves públicas y reenvía la moneda firmada (junto con la
información de la cuenta del vendedor) al banco comercial del vendedor.
El banco comercial del vendedor (3) confirma que el vendedor es uno de
@ -1002,7 +971,7 @@ continuación, (7) el banco comercial acredita la cuenta del vendedor e
(8) informa al vendedor. El vendedor (9) entrega el producto o servicio
al cliente. Todo el proceso dura solo unos pocos milisegundos.
\includegraphics[width=6.13681in,height=4.60208in]{taler_figure_2_dora_SPANISH.jpg}.
\includegraphics[width=\textwidth]{taler_figure_2_dora_SPANISH.jpg}.
\hypertarget{consideraciones-acerca-de-la-seguridad}{%
\subsection{Consideraciones acerca de la Seguridad}
@ -1032,8 +1001,8 @@ monedas que no han gastado. El banco central anunciaría la revocación de
clave mediante la API (Application Programming Interface), que sería
detectada por las billeteras e iniciarían el siguiente protocolo de
actualización: el usuario revela al banco central la clave pública
\emph{C} de la moneda, la firma \emph{s} del banco central, y el factor
ciego \emph{b}, posibilitando así que el banco central verifique el
$C$ de la moneda, la firma $s$ del banco central, y el factor
ciego $b$, posibilitando así que el banco central verifique el
retiro legítimo del usuario y devuelva el valor de la moneda no gastada.
Para detectar un posible compromiso de esta clave, el banco central
puede monitorear la base de datos en busca de casos de depósitos que
@ -1099,9 +1068,7 @@ banda y computación) a escala estaría por debajo de USD 0,0001 por
transacción (para obtener detalles sobre los datos, consulte Dold 2019).
\hypertarget{consideraciones-normativas-y-poluxedticas}{%
\section{\texorpdfstring{ \textbf{Consideraciones normativas y políticas}}
{5. Consideraciones normativas y políticas}}
\label{5.-consideraciones-normativas-y-poluxedticas}}
\section{Consideraciones normativas y políticas}\label{5.-consideraciones-normativas-y-poluxedticas}}
En el esquema propuesto, los bancos centrales no conocen la identidad de
los consumidores o comerciantes ni los montos totales de las
@ -1188,14 +1155,12 @@ menor tenga un ritmo de circulación diferente a la del efectivo físico,
pero esto no sería un problema material para las políticas monetarias.
\hypertarget{trabajos-relacionados}{%
\section{\texorpdfstring{ \textbf{Trabajos relacionados}}
{6. Trabajos relacionados}}
\label{6.-trabajos-relacionados}}
\section{Trabajos relacionados}\label{6.-trabajos-relacionados}}
Como se señaló anteriormente, la CBDC propuesta en el presente documento
se basa en eCash y GNU Taler.\footnote{La implementación de eCash por la
compañía DigiCash en los años noventa está documentada en
\href{https://www.chaum.com/ecash}{{https://www.chaum.com/ecash}}.} A
\url{https://www.chaum.com/ecash}.} A
partir de la propuesta original de Chaum para el efectivo electrónico,
la investigación se ha centrado en tres cuestiones principales. Primero,
en la propuesta original de Chaum las monedas tenían un valor fijo y
@ -1267,7 +1232,7 @@ tanto, no está claro qué ventajas de privacidad, rendimiento o seguridad
tiene la EUROchain sobre el dinero existente en depósito.
\hypertarget{conclusiuxf3n}{%
\section{\texorpdfstring{ \textbf{Conclusión}}{7. Conclusión}}
\section{Conclusión}
\label{7.-conclusiuxf3n}}
Con la aparición de Bitcoin y monedas digitales recientemente propuestas
@ -1311,6 +1276,7 @@ evitar perturbaciones significativas en sus políticas monetarias y
estabilidad financiera cosechando al mismo tiempo los beneficios de la
digitalización.
\newpage
REFERENCIAS
@ -1690,4 +1656,7 @@ and Freedom Respecting Software for Economists.'' Journal of Applied
Econometrics, Vol. 23, pp. 279-86.
\end{itemize}
\bibliographystyle{plain}
\bibliography{cbdc,rfc}
\end{document}