math typesetting

1 files changed, 237 insertions, 268 deletions

diff --git a/doc/cbdc-es/cbdc-es.tex b/doc/cbdc-es/cbdc-es.tex
index d38b4d12b..ee6341fa2 100644
--- a/doc/cbdc-es/cbdc-es.tex
+++ b/doc/cbdc-es/cbdc-es.tex
@@ -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,19 +49,18 @@ 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
-Agradecemos a Michael Barczay, Roman Baumann, Morten Bech, Nicolas Cuche, 
+\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
 anónimos por sus comentarios y sugerencias. Las ideas, opiniones,
@@ -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
@@ -173,12 +148,12 @@ transacción, no proporciona beneficios tangibles en una implementación
 por parte de un banco central. Utilizar la DLT para emitir dinero
 digital puede ser útil si no hay un banco central para empezar (p. ej.
 el proyecto Sovereign de las Islas Marshall) o si la intención explícita
-es prescindir de un banco central (p. ej. Bitcoin).\footnote{Puede haber 
-buenos casos de uso para la DLT en el caso de infraestructura de 
-mercado financiero, tal como los intercambios digitales, donde surge la 
-cuestión de como obtener dinero del banco central en la DLT a efectos de 
-liquidación. Sin embargo en esas situaciones, los beneficios potenciales 
-de la DLT, por ejemplo menos costes o reconciliación automática, no surgen 
+es prescindir de un banco central (p. ej. Bitcoin).\footnote{Puede haber
+buenos casos de uso para la DLT en el caso de infraestructura de
+mercado financiero, tal como los intercambios digitales, donde surge la
+cuestión de como obtener dinero del banco central en la DLT a efectos de
+liquidación. Sin embargo en esas situaciones, los beneficios potenciales
+de la DLT, por ejemplo menos costes o reconciliación automática, no surgen
 de una emisión descentralizada del dinero del banco central.}
 
 La CBCD basada en tokens que se propone aquí permite también la
@@ -205,7 +180,7 @@ problemáticos incluso si las personas creen que no tienen nada que
 esconder, simplemente por la posibilidad de error y abuso,
 particularmente si los programas carecen de transparencia e
 imputabilidad (véase Solove 2011). Segundo, porque la privacidad en las
-transacciones protege a los usuarios frente a la explotación de datos por parte 
+transacciones protege a los usuarios frente a la explotación de datos por parte
 de los proveedores de servicios de pago.
 Tercero, porque protege a los usuarios frente a la contraparte en la
 transacción, descartando la posibilidad de un posterior comportamiento
@@ -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
@@ -237,13 +210,13 @@ cotizan los precios y cómo se registran las deudas) coincide con el
 medio de intercambio por razones de conveniencia. La separación puede
 ocurrir, sin embargo, si el valor del medio de intercambio carece de
 estabilidad en relación a los bienes y servicios
-comercializados.\footnote{Esto puede ocurrir espontáneamente en un entorno 
-de alta-inflación, p. ej. cuando los precios se fijan en USD pero los pagos 
-se realizan en divisa local. Lo mismo es ciertopara los pagos en Bitcoin, 
-donde los precios usualmente se fijan en USA u otras divisas locales debido a 
-la alta volatilidad de Bitcoin. Una eparación también puede ocurrir por el 
-diseño, p. ej. en la Unidad de Fomento (UF) de Chile o la Special Drawing Right 
-(SDR) del fondo monetario internacional (IMF). Sin embargo, también entonces el 
+comercializados.\footnote{Esto puede ocurrir espontáneamente en un entorno
+de alta-inflación, p. ej. cuando los precios se fijan en USD pero los pagos
+se realizan en divisa local. Lo mismo es ciertopara los pagos en Bitcoin,
+donde los precios usualmente se fijan en USA u otras divisas locales debido a
+la alta volatilidad de Bitcoin. Una eparación también puede ocurrir por el
+diseño, p. ej. en la Unidad de Fomento (UF) de Chile o la Special Drawing Right
+(SDR) del fondo monetario internacional (IMF). Sin embargo, también entonces el
 propósito es tener una unidad de cuenta más estable.} El dinero debe también ser
 un depósito de valor para poder actuar como medio de intercambio, porque
 debe preservar su poder de compra desde el momento en que se recibe
@@ -339,9 +312,9 @@ monedas en relación al activo o los activos subyacentes depende de
 manera crucial de los derechos legales que adquieran los titulares de
 las monedas estables. Si una moneda estable es canjeable a un precio
 fijo (p. ej. 1 moneda = 1 USD, o 1 moneda = 1 onza de oro), tal
-estabilidad teóricamente se conseguirá.\footnote{Si también estabilice o 
-no el valor de las monedas estables en relación con los bienes y 
-servicios negociados depende de la estabilidad del valor del respectivo 
+estabilidad teóricamente se conseguirá.\footnote{Si también estabilice o
+no el valor de las monedas estables en relación con los bienes y
+servicios negociados depende de la estabilidad del valor del respectivo
 activo en relación con el valor de los bienes y servicios.} Lo que el esquema
 esencialmente hace es replicar a los bancos comerciales garantizando la
 convertibilidad al activo subyacente a la vista. Sin embargo, a
@@ -359,18 +332,18 @@ dinero (billetes o depósitos bancarios) no es muy rentable. En
 consecuencia, los proveedores de monedas estables tienen un incentivo
 para economizar su tenencia de activos y trasladarse hacia un sistema de
 reserva fraccionado, tal como lo hicieron los bancos comerciales.\footnote
-{La incertidumbre sobre si un moneda estable está 
-totalmente garantizada puede ser una de las razones por las que una 
-moneda stable puede negociarse por debajo de la par en el mercado 
-secundario (véase Lyons y Ganesh Viswanath-Natraj, 2020). Este fue 
-también historícamente el caso con los billetes cuando eran emitidos 
-por los bancos comerciales. Tales billetes solían negociarse con 
-diversos descuentos en el mercado secundario antes de que la emisión 
-de billetes fuera nacionalizada y transferida al monopolio de los 
-bancos centrales.} Esto implica que reducen su tenencia de activos de 
-bajo rendimiento al mínimo que se considere necesario para satisfacer el 
-requisito de convertibilidad. Añadiendo en cambio activos líquidos de 
-alto rendimiento tales como bonos del Estado. Esto mejora la 
+{La incertidumbre sobre si un moneda estable está
+totalmente garantizada puede ser una de las razones por las que una
+moneda stable puede negociarse por debajo de la par en el mercado
+secundario (véase Lyons y Ganesh Viswanath-Natraj, 2020). Este fue
+también historícamente el caso con los billetes cuando eran emitidos
+por los bancos comerciales. Tales billetes solían negociarse con
+diversos descuentos en el mercado secundario antes de que la emisión
+de billetes fuera nacionalizada y transferida al monopolio de los
+bancos centrales.} Esto implica que reducen su tenencia de activos de
+bajo rendimiento al mínimo que se considere necesario para satisfacer el
+requisito de convertibilidad. Añadiendo en cambio activos líquidos de
+alto rendimiento tales como bonos del Estado. Esto mejora la
 rentabilidad pero también incrementa el nivel de riesgo.
 
 Sin embargo, incluso si una moneda estable está garantizada al 100\% por
@@ -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
@@ -441,10 +412,10 @@ activos (tokens) incluyen información acerca de su valor y de la entidad
 que emitió el token. Por tanto, la única posibilidad de lograr la
 propiedad de privacidad de la transacción como la que se obtiene con el
 dinero efectivo reside en los sistemas basados en tokens.\footnote
-{Si bien el término "Bitcoin" sugiere el uso de tokens, Bitcoin es un 
-sistema basado en cuentas. La única diferencia entre un sistema 
-tradicional basado en cuentas y una blockchain es que las cuentas no 
-se guardan en una base de datos central, sino en una base de datos 
+{Si bien el término "Bitcoin" sugiere el uso de tokens, Bitcoin es un
+sistema basado en cuentas. La única diferencia entre un sistema
+tradicional basado en cuentas y una blockchain es que las cuentas no
+se guardan en una base de datos central, sino en una base de datos
 descentralizada del tipo "solo por anexión".}
 
 \hypertarget{cbdc-basada-en-cuentas}{%
@@ -567,31 +538,30 @@ 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 --
-FLOSS).\footnote{Para más información sobre GNU, véase 
-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'' 
-(GRETL). Un análisis de los beneficios del FLOSS en comparación con el 
-software privativo en el campo de la investigación puede consultarse 
-en Baiocchi y Distaso (2003), Yalta y Lucchetti (2008) y Yalta y Yalta 
-(2010). Sobre el licenciamiento de código abierto véase Lerner y 
-Tirole (2005).} Un programa se considera "Software Libre" si la licencia 
-otorga a los usuarios cuatro libertades esenciales: la libertad 
-de ejecutar el programa como deseen, la libertad de estudiar el programa 
-y modificarlo, la libertad de redistribuir copias del programa y la 
-libertad de distribuir copias de las versiones modificadas del programa. 
+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
+\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''
+(GRETL). Un análisis de los beneficios del FLOSS en comparación con el
+software privativo en el campo de la investigación puede consultarse
+en Baiocchi y Distaso (2003), Yalta y Lucchetti (2008) y Yalta y Yalta
+(2010). Sobre el licenciamiento de código abierto véase Lerner y
+Tirole (2005).} Un programa se considera "Software Libre" si la licencia
+otorga a los usuarios cuatro libertades esenciales: la libertad
+de ejecutar el programa como deseen, la libertad de estudiar el programa
+y modificarlo, la libertad de redistribuir copias del programa y la
+libertad de distribuir copias de las versiones modificadas del programa.
 El software libre no tiene por qué ser no comercial: proporcionar
 soporte técnico para software es un modelo de negocio estándar para el
 FLOSS.
@@ -605,24 +575,24 @@ probablemente un obstáculo para la adopción desde el principio. Con el
 FLOSS, todas las partes interesadas tienen acceso a cada detalle de la
 solución y el derecho de adaptar el software a sus necesidades. Esto
 conduce a una integración más fácil y una mejor interoperabilidad y
-competencia entre proveedores.\footnote{Sin embargo, puede haber otros 
-roles para hardware privado. Por ejemplo, proteger los depósitos de 
-claves y ciertas funciones de auditoría, en la medida en que tal 
-seguridad pueda demostrarse solo como aditiva, puede ser un área donde 
-el hardware dedicado evaluado por solo un número limitado de expertos 
+competencia entre proveedores.\footnote{Sin embargo, puede haber otros
+roles para hardware privado. Por ejemplo, proteger los depósitos de
+claves y ciertas funciones de auditoría, en la medida en que tal
+seguridad pueda demostrarse solo como aditiva, puede ser un área donde
+el hardware dedicado evaluado por solo un número limitado de expertos
 podría tener ventajas.} Además, permite que el banco central cumpla
 con los requisitos de transparencia y responsabilidad. Los beneficios
 del FLOSS para la seguridad son también ampliamente reconocidos. La
 disponibilidad del código fuente y el derecho a modificarlo facilitan la
-detección de fallos y su rápida solución.\footnote{Por ejemplo, un 
-boletín de seguridad cibernética emitido por la Agencia de Seguridad 
-Nacional de EE. UU. en abril de 2020 insta a los usuarios a priorizar 
-el software de código abierto en la selección y el uso de servicios de 
-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).}
+detección de fallos y su rápida solución.\footnote{Por ejemplo, un
+boletín de seguridad cibernética emitido por la Agencia de Seguridad
+Nacional de EE. UU. en abril de 2020 insta a los usuarios a priorizar
+el software de código abierto en la selección y el uso de servicios de
+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).}
 
 En esta nuestra arquitectura que proponemos todas las interacciones del
 consumidor y el comerciante son con bancos comerciales. Sin embargo, la
@@ -641,9 +611,9 @@ instrumento digital al portador porque cuando el usuario retira una suma
 de dinero en forma de número, el número es ``cegado'' u ocultado por el
 teléfono inteligente con un cifrado especial. En el sistema real, una
 moneda es un par de claves pública / privada, y la clave privada solo la
-conoce el propietario de la moneda.\footnote{En Bitcoin, que es un 
-sistema basado en cuentas, el par de claves es una cuenta, siendo la 
-clave pública la "dirección" de la cuenta y por tanto un tipo de 
+conoce el propietario de la moneda.\footnote{En Bitcoin, que es un
+sistema basado en cuentas, el par de claves es una cuenta, siendo la
+clave pública la "dirección" de la cuenta y por tanto un tipo de
 "identidad'', incluso si se trata de un pseudónimo.} La moneda deriva
 su valor financiero de la firma del banco central en la clave pública de
 la moneda. El banco central hace la firma con su clave privada y dispone
@@ -680,8 +650,8 @@ conocimiento.
 esquema de firma con clave pública es que el propietario de una clave
 privada es el único que puede firmar un mensaje, mientras que la clave
 pública permite a cualquiera verificar la validez de la
-firma.\footnote{La criptografía de clave pública fué introducida por 
-Diffie y Hellman (1976), y la primera implentación de firmas digitales 
+firma.\footnote{La criptografía de clave pública fué introducida por
+Diffie y Hellman (1976), y la primera implentación de firmas digitales
 fué introducida por Rivest, Shamir y Adleman (1978).} El resultado de
 la función de verificación es la declaración binaria "verdadero" o
 "falso". Si el mensaje está firmado con la clave privada que pertenece a
@@ -691,34 +661,34 @@ contrario es falso. En nuestra propuesta, el mensaje es una "moneda" o
 su validez. Si bien GNU Taler usa por defecto firmas EdDSA modernas
 (véase Bernstein et al. 2012), presentamos un esquema de firma
 criptográfica simple basado en el bien estudiado sistema criptográfico
-RSA (Rivest et al. 1978).\footnote{Para un análisis de la larga historia 
-del criptosistema RSA y un estudio de los ataques al criptosistema RSA, 
-consulte Boneh (1999).} Sin embargo, en principio se puede utilizar 
+RSA (Rivest et al. 1978).\footnote{Para un análisis de la larga historia
+del criptosistema RSA y un estudio de los ataques al criptosistema RSA,
+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
-Euclídeo de modo que 
-\(d \bullet e \equiv 1 \hspace*{1pt} \text{mod} \hspace*{1pt} \phi\left( n \right)\).
-
-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\).
-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
+correspondiente clave privada $d$. Dado $\phi(n)$, la clave
+privada $d$ se puede calcular usando el algoritmo extendido
+Euclídeo de modo que
+$d \cdot e \equiv 1 \mod \phi(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} \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\) 
-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. 
-El cliente puede entonces des-cegar la firma calculando 
-\(s \equiv s'b^{- 1} \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} \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} \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
@@ -792,12 +762,12 @@ similar existe para los billetes físicos, donde las series de los
 billetes se renuevan regularmente para que los billetes vayan equipados
 con las últimas características de seguridad, excepto que los billetes
 generalmente permanecen en circulación durante décadas en vez de por
-unos pocos meses o años.\footnote{En Suiza, por ejemplo, el Swiss 
-National Bank empezó la eliminación paulatina la serie octava de 
-billetes en abril de 2016. Estos billetes fueron puestos en 
-circulación al final de los 90. A partir del dia 1 de enero de 2020, 
-sin embargo, todos los billetes que empiezan por la serie sexta 
-emitidos en 1976, así como cualquier futura serie, permanecen válidas 
+unos pocos meses o años.\footnote{En Suiza, por ejemplo, el Swiss
+National Bank empezó la eliminación paulatina la serie octava de
+billetes en abril de 2016. Estos billetes fueron puestos en
+circulación al final de los 90. A partir del dia 1 de enero de 2020,
+sin embargo, todos los billetes que empiezan por la serie sexta
+emitidos en 1976, así como cualquier futura serie, permanecen válidas
 y se pueden cambiar por billetes actuales de forma indefenida.}
 
 Desde un punto de vista técnico, una fecha de vencimiento tiene dos
@@ -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,104 +803,103 @@ 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 
-llama también generador, para prevenir ataques de subgrupo tales como ataques 
+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\).
-\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 
-identidad a largo plazo. Luego, el proceso de retiro podría usar la 
-misma construcción que usa GNU Taler para obtener el cambio, excepto 
-que se usaría la clave de identidad a largo plazo de un cliente en 
-lugar de la moneda original cuando se retira de la cuenta bancaria del 
-cliente. Sin embargo, si el cliente no proteje la clave de identidad a 
-largo plazo las garantías de privacidad podrían quedar anuladas con 
-consecuente riesgo de robo de todas las monedas restantes. Dado el 
-riesgo limitado en las transferencias a terceros al retirar monedas, 
+$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
+identidad a largo plazo. Luego, el proceso de retiro podría usar la
+misma construcción que usa GNU Taler para obtener el cambio, excepto
+que se usaría la clave de identidad a largo plazo de un cliente en
+lugar de la moneda original cuando se retira de la cuenta bancaria del
+cliente. Sin embargo, si el cliente no proteje la clave de identidad a
+largo plazo las garantías de privacidad podrían quedar anuladas con
+consecuente riesgo de robo de todas las monedas restantes. Dado el
+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
-correspondiente clave pública, p. ej. 
-\(C = g^{c} \hspace*{1pt} \text{mod} \hspace*{1pt} p\). 
+con la clave privada de la moneda c. gastada parcialmente. Sea C la
+correspondiente clave pública, p. ej.
+$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
-intercambio de claves, tendremos 
-\(T_{i} \equiv g^{t_{i}} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
+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}} \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
+mismo valor
+$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
-{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}.
+$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}(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
+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
+\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}