es-cbdc version from Stefan

4 files changed, 1701 insertions, 1 deletions

diff --git a/doc/cbdc-es/cbdc-es.tex b/doc/cbdc-es/cbdc-es.tex
new file mode 100644
index 000000000..007a38c97
--- /dev/null
+++ b/doc/cbdc-es/cbdc-es.tex
@@ -0,0 +1,1700 @@
+\documentclass{article}
+\usepackage[a4paper,
+top=2cm,
+bottom=2cm,
+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
+\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}
+\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}
+
+\vspace{20pt}
+\begin{center} 
+\vspace{20pt}
+\textbf{Resumen}
+\end{center}
+\emph{
+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
+ofrecen su propia alternativa digital al dinero en efectivo. No
+abordamos la cuestión normativa de si un un banco central debería o no
+emitir una moneda digital del banco central (Central Bank Digital
+Currency -- CBDC). Contribuimos en cambio al actual debate de
+investigación mostrando de qué manera un banco central podría hacerlo si
+así lo deseara. Proponemos un sistema basado en tokens sin tecnología de
+libro mayor distribuido, y mostramos que el efectivo electrónico ya
+implementado solo mediante software se puede mejorar para preservar la
+privacidad en las transacciones, cumplir con los requisitos
+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}
+
+JEL: E42, E51, E52, E58, G2
+\newline
+\newline
+Keywords: Monedas digitales, banco central, CBDC, firmas ciegas, monedas
+estables
+\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, 
+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,
+investigaciones y conclusiones o recomendaciones expresadas en este
+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}
+
+\newpage
+\hypertarget{introducciuxf3n}{%
+\section{\texorpdfstring{ \textbf{Introducción}}{1. Introducción}}
+\label{1.-introducciuxf3n}}
+
+Desde la aparición de los ordenadores personales en los años ochenta, y
+especialmente desde que en 1991 la National Science Foundation quitara
+las restricciones al uso de Internet para propósitos comerciales, se ha
+buscado crear dinero digital para realizar pagos en línea. La primera
+propuesta la realizó Chaum en 1983. A pesar de que tales métodos fueron
+implementados, no prosperaron. Fueron en cambio los sistemas con tarjeta
+de crédito los que se convirtieron en el método dominante para pagos en
+línea. La propuesta de Nakamoto en 2008 para un sistema P2P de dinero
+digital y el posterior lanzamiento exitoso de Bitcoin desataron una
+nueva era de investigación sobre el tema y desarrollo de dinero digital.
+CoinMarketCap enumera más de 5.000 criptomonedas. Recientemente los
+bancos centrales han empezado a considerar, o al menos estudiar, la
+emisión de monedas digitales (véase Auer et. al. 2020, Boar et al. 2020,
+Kiff et al. 2020 y Mancini-Griffoli et al. 2018).
+
+Actualmente los bancos centrales emiten dos tipos de dinero: (i)
+reservas en forma de cuentas de liquidación en los bancos centrales para
+determinados participantes del mercado financiero y (ii) moneda en forma
+de billetes disponibles para el público. En consecuencia, la
+bibliografía sobre la moneda digital del banco central (CBDC) distingue
+entre (a) venta de CBDC al por mayor, con acceso limitado, y (b) venta
+de CBDC al por menor, accesible al público (véase, p. ej. Bech y Garratt
+2017). Una CBDC al por mayor sería menos disruptiva para el sistema
+actual debido a que los bancos y los participantes seleccionados del
+mercado financiero ya tienen acceso a dinero digital del banco en forma
+de cuentas del banco central, que utilizan para liquidar pagos
+interbancarios. La cuestión aquí es si la tokenización del dinero de un
+banco central y la tecnología de libro mayor distribuido (Distributed
+Ledger Technology - DLT) ofrecen beneficios netos en comparación con los
+sistemas de liquidación bruta en tiempo real ( Real-Time Gross
+Settlement - RTGS). Hasta el momento, la conclusión es que no es así, al
+menos cuando se trata de pagos interbancarios nacionales (véase Chapman
+et al. 2017).
+
+Una CBDC al por menor, que sería una nueva forma de dinero del banco
+central a disposición del público, podría ser más disruptiva para el
+sistema actual, dependiendo de su diseño. Cuanto más compita una CBDC de
+este tipo con los depósitos bancarios comerciales, mayor será la amenaza
+para la financiación bancaria, con un posible impacto adverso en el
+crédito bancario y la actividad económica (véase Agur et al. 2019). Sin
+embargo, una CBDC al por menor podría también tener beneficios (véase
+Bordo y Levin 2017, Berentsen y Schär 2018, Bindseil 2020, Niepelt 2020,
+Sveriges Riksbank 2020 y Bank of England 2020). Poner a disposición de
+todos dinero electrónico del banco central sin riesgo de contrapartida
+podría mejorar la estabilidad y la resistencia del sistema de pago al
+por menor. También podría proporcionar una infraestructura de pago
+neutral para promover la competencia, la eficiencia y la innovación. En
+general, es probable que los costos y beneficios de una CBDC al por
+menor difieran de un país a otro. Para conocer la opinión del Banco
+Nacional de Suiza, que no tiene planes de emitir una CBDC al por menor,
+véase Jordan (2019).
+
+El presente documento se centra en una CBDC al por menor, pero no
+abordamos la cuestión de si un banco central \emph{debería o no} emitir
+una moneda CBDC. Nos centramos en cambio en el diseño potencial de una
+CBCD. Recientemente ha habido un creciente interés en el diseño de
+monedas CBCD (véase p. ej. Allen et al. (2020), Bank of England (2020)).
+El diseño que proponemos difiere significativamente de otras propuestas.
+Nuestro sistema se basa en la tecnología eCash descrita por Chaum (1983)
+y Chaum et al. (1990), mejorándola. En particular, proponemos un sistema
+para CBCD basado en tokens y solo mediante software, sin blockchain para
+la DLT. La DLT es un diseño interesante en ausencia de un actor
+principal o si las entidades que interactúan no concuerdan en nombrar un
+actor central de confianza. Sin embargo, este no es el caso de una CBCD
+al por menor emitida por un \emph{banco central}. Distribuir el libro
+mayor del banco central con una blockchain solo aumenta los costes de
+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 
+de una emisión descentralizada del dinero del banco central.}
+
+La CBCD basada en tokens que se propone aquí permite también la
+preservación de una cualidad clave del dinero físico: la privacidad en
+la transacción. Usualmente se argumenta que las protecciones
+criptográficas para la privacidad exigen tantos recursos computacionales
+que su utilización en dispositivos móviles no es factible (véase Allen
+et al. 2020). Si bien esto puede ser cierto en el contexto de la DLT,
+donde la rastreabilidad pública de las transacciones es necesaria para
+prevenir el doble gasto (Narayanan et al. 2016), no es cierto para el
+protocolo de firma ciega de tipo Chaum con un banco central que se
+propone en el presente documento. Nuestra CBDC, basada en firmas ciegas
+y arquitectura de dos niveles, garantiza una perfecta privacidad de
+resistencia cuántica en las transacciones, al mismo tiempo que
+proporciona protecciones sociales tales como impedir el lavado de dinero
+(Anti-Money Laundering - AML) y financiar la lucha contra el terrorismo
+(Counter Terrorism Financing -- CFT), protecciones que de hecho tienen
+mayor fuerza que con los billetes.
+
+La privacidad en las transacciones es importante por tres razones.
+Primero, porque protege a los usuarios frente al escrutinio y el abuso
+de vigilancia gubernamental. Los programas de vigilancia masiva son
+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 
+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
+oportunista, o frente a riesgos de seguridad debido a fallos o
+negligencia en la protección de los datos del cliente (véase Kahn et al.
+2005).
+
+Este documento está estructurado como sigue: en la sección 2 explicamos
+la diferencia entre el dinero del banco central y otro dinero. En la
+sección 3 analizamos los diseños de CBDC comunes y simplistas, antes
+de proponer nuestro diseño en la sección 4. Luego comentamos
+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}}
+
+El dinero es un activo que puede ser usado para comprar bienes y
+servicios. Para ser considerado dinero, este activo debe ser aceptado
+por otras entidades distintas del emisor. Este es el motivo por el que
+los vales, por ejemplo, no se consideran dinero. El dinero genuino tiene
+que ser aceptado \emph{comúnmente} como medio de intercambio. Si bien el
+dinero tiene otras funciones, por ejemplo como unidad de cuenta y
+depósito de valor, la característica que lo distingue es su función como
+medio de intercambio. Normalmente, la unidad de cuenta (p. ej. cómo se
+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 
+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
+hasta el momento en que se gasta. Sin embargo, varios otros activos
+sirven como depósito de valor, como por ejemplo acciones, bonos, metales
+preciosos e inmuebles. Por tanto, la característica como depósito de
+valor no es distintiva del dinero.
+
+En la economía moderna, el público usa dos tipos diferentes de dinero:
+(a) dinero estatal y (b) dinero privado. El dinero estatal lo emite
+típicamente un banco central, que actúa como agente del Estado. El
+dinero del banco central está disponible para determinadas instituciones
+financieras en forma de depósitos en el banco central (reservas) y para
+el público en forma de moneda (billetes y monedas), también llamado
+``efectivo''. En una economía moderna con dinero fiduciario, tal dinero
+no tiene valor intrínseco. Legalmente es una obligación del banco
+central, aunque no es canjeable.
+
+En la mayoría de los países, el dinero del banco central se define como
+moneda de curso legal, lo cual significa que debe ser aceptado como pago
+de una deuda monetaria, incluyendo impuestos y multas legales. Si bien
+esto garantiza que el dinero del banco central tenga algún valor, el
+estatus de moneda de curso legal es insuficiente para que el dinero del
+banco central mantenga un valor estable. Más bien, es la política
+monetaria de los bancos centrales la que mantiene el valor del dinero.
+Mantener la estabilidad de los precios, es decir, un valor estable del
+dinero en relación con el valor de los bienes y servicios
+comercializados, es una de las principales responsabilidades de los
+bancos centrales.
+
+En una economía moderna, la mayoría de los pagos se hacen con dinero
+privado emitido por bancos comerciales. Tal dinero se compone de
+depósitos a la vista que la gente tiene en los bancos comerciales. A
+estos depósitos bancarios se puede acceder con cheques, tarjetas de
+débito, tarjetas de crédito, u otros medios para transferir dinero. Son
+una obligación del respectivo banco comercial. Una característica
+fundamental de los depósitos bancarios es que los bancos comerciales
+garantizan la convertibilidad, bajo demanda, en dinero del banco central
+a un precio fijo, es decir, a la par. Los depositantes pueden retirar
+sus fondos en efectivo o transferirlos a una tasa fija de 1:1. Los
+bancos comerciales mantienen estable el valor de su dinero vinculándolo
+al dinero del banco central.
+
+No obstante, en un sistema de reserva fraccionado, un banco comercial
+-- incluso siendo solvente -- puede no contar con la liquidez necesaria
+para cumplir su promesa de convertir los depósitos bancarios en dinero
+del banco central (p. ej. en caso de una caída bancaria) de manera tal
+que los clientes no puedan retirar su dinero. Un banco también puede
+llegar a ser insolvente e ir a la bancarrota, y como resultado los
+clientes pueden perder su dinero. Así, los bancos comerciales están
+regulados para mitigar estos riesgos.
+
+Una diferencia significativa entre el dinero de un banco central y el
+dinero emitido privadamente por un banco comercial es, por lo tanto, que
+este último conlleva un riesgo para la contraparte. Un banco central
+puede siempre cumplir con sus obligaciones usando su propio dinero no
+reembolsable. El dinero del banco central es el único activo monetario
+de una economía nacional sin riesgo crediticio o de liquidez. Por lo
+tanto, es el activo que típicamente se prefiere para los pagos en las
+infraestructuras del mercado financiero (véase p. ej. CPMI-IOSCO
+\emph{Principles for Financial Market Infrastructures}, 2012). Otra
+diferencia es que el dinero del banco central afianza el sistema
+monetario nacional al proporcionar una referencia de valor con la que el
+dinero de los bancos comerciales mantiene una convertibilidad a la par.
+
+Aparte de los bancos comerciales, otra entidades privadas ocasionalmente
+intentan emitir dinero, las criptomonedas son solo el intento más
+reciente. Pero a diferencia de los depósitos bancarios, tal dinero no es
+comúnmente aceptado como medio de intercambio. Esto también sucede con
+Bitcoin, la criptomoneda más aceptada. Un impedimento a su utilidad como
+medio de intercambio es la alta volatilidad de su valor. Una respuesta
+reciente a este problema fue la aparición de las llamadas monedas
+estables. Las monedas estables generalmente intentan estabilizar su
+valor en una de las dos maneras siguientes: o bien imitando a los bancos
+centrales (monedas estables algorítmicas) o bien imitando a los bancos
+comerciales o a los medios de inversión (monedas estables con respaldo
+de activos).\footnote{Para más detalles sobre la taxonomia y descripción
+de las monedas stables véase Bullman et al. (2019).}
+
+Las ``monedas estables algorítmicas'' dependen de algoritmos para
+regular su suministro. En otras palabras, intentan alcanzar la
+estabilidad de su precio con sus propias ``políticas monetarias
+algorítmicas''. Hay ejemplos de tales monedas estables (p. ej. Nubits),
+pero hasta ahora ninguna ha estabilizado su valor por largo tiempo.
+
+Las monedas estables ``respaldadas con activos'' difieren en función del
+tipo de activos que usan y de los derechos legales que adquieren los
+titulares de monedas estables. Los tipos de activos que típicamente se
+usan son: dinero (reservas del banco central, billetes o depósitos en
+bancos comerciales), productos básicos (p. ej. oro), valores y a veces
+otras criptomonedas. Cuán bien tal esquema estabilice el valor de las
+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 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
+diferencia de los depósitos bancarios, que típicamente están solo
+parcialmente respaldados por las reservas monetarias del banco central,
+las monedas estables generalmente están respaldadas completamente por
+las reservas del activo subyacente para evitar el riesgo de liquidez,
+principalmente porque carecen de beneficios públicos tales como el
+soporte de seguros de depósito y prestamistas de última instancia, que
+se aplican en cambio a los bancos regulados.
+
+Las monedas estables respaldadas con dinero se llaman también monedas
+estables fiduciarias. Sin embargo, mantener el 100\% de garantía en
+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
+rentabilidad pero también incrementa el nivel de riesgo.
+
+Sin embargo, incluso si una moneda estable está garantizada al 100\% por
+un depósito en un banco comercial, sigue expuesta a los riesgos de
+crédito y liquidez del banco subyacente. Este riesgo se puede eliminar
+si los depósitos se mantienen en el banco central para que la moneda
+estable esté respaldada por las reservas del banco central. Tales
+monedas estables han sido llamadas ``CBDC sintéticas'' (Adrian y
+Mancini-Griffoli 2019). Es importante señalar, sin embargo, que tales
+monedas estables no son dinero del banco central y por lo tanto no son
+CBDC, ya que no constituyen obligaciones del banco central y, por lo
+tanto, siguen expuestas al riesgo de contraparte, es decir, el riesgo de
+que el emisor de la moneda estable se declare en quiebra.
+
+Si una moneda estable no es canjeable a un precio fijo, su estabilidad
+no está garantizada por el activo subyacente. Si la moneda estable a
+pesar de esto representa una participación en la propiedad del activo
+subyacente, el esquema se asemeja a un fondo de inversión fijo o a un
+fondo cotizado en bolsa (Exchange-Traded Fund - ETF), y se aplican los
+correspondientes riesgos. El valor de la moneda dependerá del valor neto
+de los activos del fondo, pero su valor real puede desviarse. Si hay
+participantes autorizados que puedan crear y canjear monedas estables y
+así actuar como arbitristas, como en el caso de los ETF y como estaba
+previsto para Diem (Asociación Libra 2020), es probable que la
+desviación sea mínima.
+
+En general, las monedas estables tiene una mayor probabilidad de llegar
+a convertirse en dinero que las criptomonedas, especialmente si se
+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}}
+
+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
+basada en cuentas y (b) una CBDC basada en tokens (o basada en valor).
+Estos diseños corresponden a los dos tipos existentes de dinero de un
+banco central y sus correspondientes sistemas de pago (Kahn y Roberds
+2008): las reservas de un banco central (en un sistema basado en
+cuentas) y billetes (en un sistema basado en tokens). Un pago se produce
+si un activo monetario se transfiere de un pagador a un beneficiario. En
+un sistema basado en cuentas, una transferencia se produce cobrándole a
+la cuenta del pagador y transfiriendo el crédito a la cuenta del
+beneficiario. En un sistema basado en tokens, la transferencia se
+produce transfiriendo el valor en sí o el token, es decir, un objeto que
+representa el activo monetario. El mejor ejemplo de un token es el
+efectivo ---monedas o billetes. Pagar con efectivo significa entregar
+una moneda o un billete. No es necesario registrar la transferencia, la
+posesión del token es suficiente. Por lo tanto, las partes no están
+obligadas a revelar sus identidades en ningún momento durante la
+transacción, ambas pueden permanecer anónimas. De todas maneras, el
+beneficiario tiene que poder verificar la autenticidad del token. Esta
+es la razón por la que los bancos centrales invierten mucho en elementos
+de seguridad para los billetes.
+
+Ha habido sugerencias de que la distinción entre los sistemas basados en
+cuentas y los sistemas basados en tokens no es aplicable a las monedas
+digitales (Garratt et al. 2020). Nosotros tenemos una opinión diferente
+porque creemos que hay una diferencia significativa. La distinción
+fundamental es la información contenida en el activo. En un sistema
+basado en cuentas, los activos (las cuentas) se asocian con los
+historiales de las transacciones, que incluyen todas las operaciones de
+crédito y débito de las cuentas. En un sistema basado en tokens, los
+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
+  descentralizada del tipo "solo por anexión".}
+
+\hypertarget{cbdc-basada-en-cuentas}{%
+\subsection{CBDC basada en cuentas}\label{cbdc-basada-en-cuentas}}
+
+La forma más simple de lanzar una CBDC sería permitir que el público
+tenga cuentas de depósito en el banco central. Esto implica que el banco
+central seria responsable de llevar a cabo verificaciones para conocer a
+sus clientes (Know-Your-Customer - KYC) y asegurar el cumplimiento del
+AML y CFT. Esto incluiría no solo realizar el proceso inicial del KYC,
+sino también autentificar a los clientes para las transacciones
+bancarias, gestionar el fraude y lidiar con los falsos positivos y las
+autenticaciones de los falsos negativos. Dada la limitada presencia
+física de bancos centrales en la sociedad, y el hecho de que la
+autenticación del ciudadano es algo que probablemente en la actualidad
+los bancos no estén preparados para hacer a gran escala, cualquier CBDC
+basada en cuentas requeriría que el banco central delegara estas
+verificaciones. Todo el servicio y mantenimiento de tales cuentas podría
+asignarse a proveedores externos (Blindseil 2020), o la legislación
+podría obligar a los bancos comerciales a abrir cuentas bancarias en el
+banco central para sus clientes (Berentsen y Schär 2018).
+
+Tal CBDC basada en cuentas daría potencialmente a un banco central mucha
+información. Una posible preocupación podría ser que esto permitiera a
+los gobiernos realizar fácilmente vigilancia masiva e imponer sanciones
+a los titulares de cuentas individuales. Su naturaleza centralizada hace
+que tales intervenciones sean económicas y fáciles de aplicar contra
+individuos o grupos. Incluso en las democracias, hay muchos ejemplos de
+abusos de vigilancia dirigidos a críticos y opositores políticos. Se
+podría argumentar que los bancos centrales independientes puedan
+salvaguardar tal información del escrutinio del gobierno y el abuso
+político, pero esto solo abriría una nueva vía para la presión política,
+amenazando la independencia del banco central. Además, la base de datos
+central sería un objetivo importante para los atacantes: incluso el
+acceso de solo lectura a partes de la base de datos podría crear riesgos
+significativos para las personas cuyos datos fueran expuestos.
+
+Proveyendo cuentas bancarias al público, un banco central estaría
+también en competición directa con los bancos comerciales. Esta
+competición implicaría dos riesgos. Primero, podría amenazar la base de
+depósitos de los bancos y, en el extremo, desintermediar el sector
+bancario. Esto podría afectar de manera adversa la disponibilidad de
+crédito para el sector privado y, como resultado, la actividad económica
+(Agur et al. 2019). La desintermediación de los bancos también podría
+conducir a la centralización del proceso de asignación de crédito dentro
+del banco central, lo que afectaría negativamente la productividad y el
+crecimiento económico. En segundo lugar, permitir que la gente traslade
+sus depósitos al refugio seguro de un banco central podría acelerar las
+caídas bancarias durante crisis financieras.
+
+Existen sin embargo argumentos contrarios. Brunnermeier y Niepelt (2019)
+argumentan que la transferencia de fondos desde un depósito hacia una
+cuenta de CBDC conduciría a una sustitución automática de la
+financiación de depósitos por la financiación del banco central,
+simplemente haciendo explicita la garantía implícita del banco central
+como prestamista de última instancia. Berentsen y Schär (2018) sostienen
+que la competencia de los bancos centrales podría incluso tener un
+efecto disciplinario sobre los bancos comerciales y, por lo tanto,
+incrementar la estabilidad del sistema financiero, ya que los bancos
+comerciales tendrían que hacer sus modelos de negocio más seguros para
+evitar las caídas bancarias.
+
+También hay propuestas para mitigar el riesgo de la desintermediación
+que tienen como objetivo limitar o desincentivar el uso de CBDC como
+depósito de valor. Una propuesta es limitar la cantidad de CBDC que se
+puede poseer. Una segunda propuesta es aplicar una tasa de interés
+ajustable a las cuentas de CBDC, de manera que la remuneración esté
+siempre lo bastante por debajo de la remuneración de las cuentas de los
+bancos comerciales (posiblemente incluyendo un rendimiento negativo)
+para hacer que las CBDC resulten menos atractivas como depósitos de
+valor (Kumhof y Noone 2018, Bindseil 2020). Además, para disuadir las
+caídas bancarias, Kumhof y Noone (2018) sugieren que las CBDC no
+deberían ser emitidas contra depósitos bancarios, sino solo contra
+valores tales como bonos del Estado. En general, una CBDC basada en
+cuentas requeriría un análisis más profundo de estas cuestiones.
+
+\hypertarget{cbdc-basada-en-tokens-y-dependiente-del-hardware}{%
+\subsection{CBDC basada en tokens y dependiente del hardware}
+\label{cbdc-basada-en-tokens-y-dependiente-del-hardware}}
+
+Un banco central podría también emitir tokens electrónicos en lugar de
+cuentas. Técnicamente esto requiere de un sistema para asegurar que los
+tokens electrónicos no se puedan copiar fácilmente. Las funciones
+físicamente imposibles de clonar (véase Katzenbeisser et al. 2012) y las
+zonas seguras en el hardware (véase Alves y Felton 2004, Pinto y Santos
+2019) son dos tecnologías potenciales para la prevención de la copia
+digital. Las funciones físicas imposibles de clonar, sin embargo, no se
+pueden intercambiar a través de Internet (eliminando así el uso
+principal de las CBDC), y anteriores funciones de seguridad en el
+hardware para la prevención de copias se han visto comprometidas
+repetidamente ( véase p. ej. Wojtczuk y Rutkowska 2009, Johnston 2010,
+Lapid and Wool 2019).
+
+Una ventaja fundamental de las CBDC basadas en tokens sobre las basadas
+en cuentas del banco central es que los sistemas basados en tokens
+funcionarían sin conexión, es decir, los usuarios podrían intercambiar
+tokens (peer-to-peer) sin involucrar al banco central, lo que protegería
+la privacidad y la libertad de las personas. Sin embargo, la
+desintermediación que se produce cuando los usuarios pueden intercambiar
+tokens electrónicos sin los bancos como intermediarios que realizan los
+controles KYC, AML y CFT dificultarían la limitación de los abusos por
+parte de delincuentes.
+
+Las tarjetas SIM son actualmente las candidatas más extensivamente
+disponibles para un sistema de pago seguro basado en hardware, pero
+estas también conllevan riesgos. La experiencia (véase p. ej. Soukup y
+Muff 2007, Garcia et. al. 2008, Kasper et. al. 2010, CCC 2017) sugiere
+que cualquier dispositivo económicamente producible que almacene tokens
+con un valor monetario en posesión de una persona, y que permita
+transacciones sin conexión ---y por tanto el robo de la información que
+contiene--- será el objetivo de ataques de falsificación exitosos tan
+pronto como el valor económico del ataque fuera los suficientemente
+elevado. Tales ataques incluyen usuarios que atacan su propio hardware
+(véase también Allen et al. 2020). Los sistemas de pago con tarjeta que
+se han desplegado previamente dependen de la resistencia a la
+manipulación en combinación con la detección del fraude para limitar el
+impacto de una situación de peligro. Sin embargo, la detección del
+fraude requiere la habilidad de identificar a los pagadores y seguir la
+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}}
+\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.
+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.
+
+Dado el gran número de partes interesadas involucradas en una CBDC al
+por menor (el banco central, el sector financiero, comerciantes y
+clientes) y la importancia crítica de la infraestructura, una CBDC al
+por menor debe basarse en el FLOSS. Imponer una solución propietaria que
+requiera la dependencia de un proveedor en particular sería
+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
+  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).}
+
+En esta nuestra arquitectura que proponemos todas las interacciones del
+consumidor y el comerciante son con bancos comerciales. Sin embargo, la
+creación de dinero y la base de datos las proporcionan exclusivamente el
+banco central. Los bancos comerciales autentican a los clientes cuando
+retiran CBDC y a los comerciantes/beneficiarios cuando reciben CBDC,
+pero cuando gastan CBDC, los clientes/pagadores solo tienen que
+autorizar sus transacciones y no necesitan identificarse. Esto hace que
+los pagos resulten más baratos, fáciles y rápidos, y evita una fácil
+interferencia con la privacidad (Dold 2019). Además, autenticar a los
+clientes cuando retiran CBDC y a los comerciantes/beneficiarios cuando
+reciben CBDC garantiza el cumplimiento del KYC, AML y CFT.
+
+La CBDC que se propone en el presente documento es un auténtico
+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
+  "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
+de múltiples pares de claves de denominación para la firma ciega de
+monedas de diferentes valores. Un comerciante puede utilizar la
+correspondiente "clave pública" del banco central para verificar la
+firma. Sin embargo, para asegurarse de que la moneda no haya sido
+copiada y ya canjeada por otro beneficiario (es decir, que no se haya
+"gastado dos veces"), el comerciante debe depositar la moneda para que
+el banco central pueda comparar la moneda con un archivo de monedas
+canjeadas. Debido a que ni el banco comercial ni el banco central ven el
+número de la moneda durante el retiro, más tarde, cuando el comerciante
+deposita la moneda, se desconoce qué usuario la retiró. El cegamiento y
+la privacidad resultante son los que hacen de este tipo de CBDC un
+verdadero instrumento digital al portador.
+
+En el análisis que sigue proporcionamos una introducción de alto nivel a
+la tecnología y demostramos cómo se puede integrar con el sistema
+bancario existente para crear una CBDC. Dold (2019) describe detalles
+adicionales.
+
+\hypertarget{componentes-fundamentales}{%
+\subsection{Componentes fundamentales}\label{componentes-fundamentales}}
+
+A continuación describimos los principales componentes del protocolo,
+incluido el trasfondo matemático para una posible instanciación de las
+primitivas criptográficas utilizadas, para ilustrar cómo podría
+funcionar una implementación. Observamos que existen diseños matemáticos
+alternativos y equivalentes para cada componente, y simplemente
+presentamos los diseños seguros más sencillos de los que tenemos
+conocimiento.
+
+\emph{Firmas digitales.} La idea básica de las firmas digitales en un
+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
+  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
+la clave pública de verificación, el resultado es verdadero, de lo
+contrario es falso. En nuestra propuesta, el mensaje es una "moneda" o
+"billete" con un número de serie, y la firma del banco central confirma
+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 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 = \text{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
+\(\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 - gcd) de \(e\) y
+\(\phi\left( n \right)\) 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. 
+Esta inversa es la
+correspondiente clave privada 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 d y la clave pública (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
+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,
+las firmas se colocan sobre lo hashes de los mensajes en vez de los
+propios mensajes. Las funciones hash calculan el resumen de los
+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.}
+
+\emph{Firmas ciegas.} Usamos firmas ciegas, introducidas por Chaum
+(1983), para proteger la privacidad de los compradores. Una firma ciega
+se usa para crear una firma criptográfica para un mensaje sin que el
+firmante conozca el contenido del mensaje que se firma. En nuestra
+propuesta, esto evita que los bancos comerciales y el banco central
+puedan rastrear las compras identificando a los compradores. Nuestra
+propuesta funciona en principio con cualquier esquema de firma ciega,
+pero la mejor solución es la variante basada en RSA descrita por Chaum
+(1983).
+
+El cegamiento lo realizan los clientes, quienes ciegan sus monedas antes
+de transmitirlas al banco central para ser firmadas. Los clientes por
+tanto no necesitan confiar al banco central la protección de su
+privacidad. Además, el cegamiento RSA proveería de protección de la
+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.
+
+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 \(\kappa\) 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 \(t_{i}\) y devuelve el par 
+\(\left( s \middle| ',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\). 
+Esto funciona porque
+\(\left( f^{'} \right)^{d} = f^{d}b^{\text{ed}} = f^{d}b\) y, así,
+multiplicar \(s'\) con \(b^{- 1}\) produce \(f\), que es una firma RSA
+válida sobre \(c\) como antes: 
+\(s^{e} \equiv f^{\text{de}} \equiv f \hspace*{1pt} \text{mod} \hspace*{1pt} 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
+para crear firmas digitales con esquemas de firma criptográfica
+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.
+
+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
+claves públicas que los clientes podrían usar para retirar dinero. Estas
+claves de denominación, y por tanto las monedas, tendrían una fecha de
+vencimiento antes de la cual deberían ser gastadas o intercambiadas por
+nuevas monedas. A los clientes se les daría una cierta cantidad de
+tiempo durante el cual podrían intercambiar sus monedas. Un proceso
+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 
+y se pueden cambiar por billetes actuales de forma indefenida.}
+
+Desde un punto de vista técnico, una fecha de vencimiento tiene dos
+ventajas. Primero, mejora la eficiencia del sistema porque el banco
+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
+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
+negativas, si se considera necesario. El banco central podría también
+imponer un límite de conversión por cliente en consideración del AML y
+el CFT (límites de ``efectivo'' ) o por razones de estabilidad
+financiera (para prevenir el acaparamiento o las caídas bancarias), si
+así se deseara.
+
+\emph{Protocolo de intercambio de claves.} GNU Taler utiliza un
+protocolo de intercambio de claves de manera inusual para proporcionar
+un vínculo entre la moneda original y el cambio (también llamado
+``vuelto'') entregado por esa moneda original. Esto asegura que siempre
+se pueda entregar el cambio sin comprometer la transparencia de los
+ingresos o la privacidad del consumidor. El mismo mecanismo se puede
+usar también para realizar devoluciones anónimas a los clientes. El
+protocolo también maneja fallos en la red y en los componentes,
+asegurando que los pagos se hayan realizado definitivamente o se hayan
+cancelado definitivamente y que todas las partes tengan una prueba
+criptográfica del resultado. Esto es aproximadamente equivalente a los
+intercambios atómicos de los protocolos \emph{interledger} o al
+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 
+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\).
+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 \middle| 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,
+  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 c. gastada parcialmente. Sea C la
+correspondiente clave pública, p. ej. 
+\(C = g^{c} \hspace*{1pt} \text{mod} \hspace*{1pt} 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 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
+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
+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\).
+
+El resultado son tres secretos de transferencia
+\(K_{i} \equiv \emph{KX}\left( c,t_{i} \right)\). 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 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
+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
+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}.
+
+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\) .
+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
+correctamente, el banco central devuelve la firma ciega sobre
+\(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}\).
+
+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
+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.
+
+\hypertarget{arquitectura-del-sistema}{%
+\subsection{Arquitectura del sistema}\label{arquitectura-del-sistema}}
+
+El objetivo principal de nuestra arquitectura es asegurar que los bancos
+centrales no tengan que interactuar directamente con los clientes o
+guardar ninguna información sobre ellos, sino simplemente mantener una
+lista de las monedas que se gastan. La autenticación se delega a los
+bancos comerciales, que tienen ya la infraestructura necesaria. Los
+protocolos de retiro y depósito llegan al banco central a través del
+banco comercial como intermediario. Desde el punto de vista del cliente,
+el proceso es análogo a retirar dinero efectivo desde un cajero
+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}
+
+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 (e, n) provista por el banco central
+para ese valor; calcula entonces (2) un par de claves para una moneda,
+con la clave privada c y la clave pública 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
+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
+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'}
+a la billetera electrónica del cliente. Finalmente, el teléfono del
+cliente (9) usa b para descifrar la firma (→ \emph{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
+depositar las monedas. El procedimiento para gastar CBDC se indica en la
+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 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 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
+sus clientes y envía la moneda firmada al banco central. El banco
+central (4) verifica las firmas y comprueba su base de datos para
+asegurar que la moneda no haya sido previamente gastada. Si todo está en
+orden, (5) el banco central añade la moneda a la lista de monedas
+gastadas, acredita la cuenta del banco comercial en el banco central y
+(6) envía la confirmación al banco comercial a tal efecto. A
+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}.
+
+\hypertarget{consideraciones-acerca-de-la-seguridad}{%
+\subsection{Consideraciones acerca de la Seguridad}
+\label{consideraciones-acerca-de-la-seguridad}}
+
+Nuestra propuesta requiere que el banco central opere un servicio en
+línea y una base de datos de alta disponibilidad. Debido a que los
+usuarios pueden copiar las monedas electrónicas, solo los controles en
+línea pueden prevenir eficientemente el doble gasto. Si bien existen
+soluciones teóricas para identificar de manera retroactiva a usuarios
+que se dediquen al doble gasto (véase Chaum et al. 1990), tales
+soluciones crean un riesgo económico tanto para los usuarios como para
+el banco central, debido al retraso en la identificación de
+transacciones fraudulentas. La detección del doble gasto en línea
+elimina este riesgo, pero a su vez implica que las transacciones serán
+imposibles de realizar si la conexión con el banco central no estará
+disponible.
+
+El banco central también tendrá que proteger la confidencialidad de las
+claves privadas que utiliza para firmar las monedas y otros mensajes del
+protocolo. De manera que si las claves de las firmas del banco central
+se vieran en algún momento comprometidas, como por ejemplo por una
+computadora cuántica, un ataque físico en su centro de datos, o quizás
+por algún nuevo algoritmo imprevisto, los usuarios puedan de forma
+segura, y sin comprometer su privacidad, ser reembolsados con todas las
+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
+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
+superen los retiros.
+
+\hypertarget{escalabilidad-y-costes}{%
+\subsection{Escalabilidad y Costes}\label{escalabilidad-y-costes}}
+
+El esquema que proponemos sería tan eficiente y rentable como los
+modernos sistemas RTGS que utilizan actualmente los bancos centrales.
+
+La escalabilidad se refiere al costo de aumentar la capacidad de
+procesamiento para que se pueda procesar un número cada vez mayor de
+transacciones en un tiempo adecuado para la finalidad. El costo global
+del sistema puede ser bajo, ya que la CBDC que se propone aquí se basa
+en software solamente. Las monedas gastadas deben guardarse hasta que
+caduque el par de claves de denominación que se usó para firmar las
+monedas; por ejemplo, mediante un calendario anual renovable, que
+mantiene limitado el tamaño de la base de datos. La cantidad de potencia
+de procesamiento adicional y ancho de banda necesarios aumenta en la
+misma cantidad por cada transacción, gasto o depósito adicional, porque
+las transacciones son esencialmente independientes una de la otra. Esta
+potencia adicional se logra simplemente añadiendo más hardware,
+comúnmente llamado partición o fragmentación. Con el llamado hash
+consistente, las adiciones de hardware no tienen por qué ser
+disruptivas. Se puede utilizar cualquier tecnología de base de datos
+subyacente.
+
+Más concretamente, la lógica del front-end en el banco central solo
+tiene que realizar unas cuantas operaciones de firma, y un único
+procesador puede hacer miles de operaciones por segundo (véase Bernstein
+y Lange 2020). Si un solo sistema es insuficiente, es fácil desplegar
+servidores front-end adicionales y solicitar a los varios bancos
+comerciales que balanceen sus peticiones en la granja de servidores o
+que utilicen un balanceador de carga para distribuir las peticiones
+dentro de la infraestructura del banco central.
+
+Los servidores front-end deben comunicarse con una base de datos para
+hacer transacciones y prevenir el doble gasto. Un solo servidor moderno
+para la base de datos debería ser suficiente para manejar de manera
+fiable decenas de miles de estas operaciones por segundo. Las
+operaciones se reparten fácilmente entre varios servidores de bases de
+datos simplemente asignando a cada servidor un rango de valores de los
+que es responsable. Este diseño asegura que las transacciones
+individuales nunca crucen fragmentos. Así, se espera que también los
+sistemas de back-end escalen linealmente con los recursos
+computacionales disponibles, de nuevo partiendo de una línea de base
+alta para un solo sistema.
+
+Los front-end también deben comunicarse con los back-end mediante una
+interconexión. Las interconexiones puede soportar grandes cantidades de
+transacciones por segundo. El tamaño de una transacción individual suele
+ser de 1-10 kilobytes aproximadamente. Asi, las interconexiones de un
+centro de datos moderno, con velocidades de conmutación de 400Gbit/s,
+pueden soportar millones de transacciones por segundo.
+
+En fin, el costo total del sistema es bajo. Es probable que el
+almacenamiento seguro de 1 a 10 kilobytes por transacción durante muchos
+años sea el costo predominante del sistema. Utilizando los precios de
+Amazon Web Services, experimentamos con un prototipo anterior de GNU
+Taler y descubrimos que el costo del sistema (almacenamiento, ancho de
+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}}
+
+En el esquema propuesto, los bancos centrales no conocen la identidad de
+los consumidores o comerciantes ni los montos totales de las
+transacciones. Los bancos centrales solo ven cuándo se lanzan las
+monedas electrónicas y cuándo se canjean. Los bancos comerciales siguen
+proporcionando autenticación crucial de clientes y comerciantes y, en
+particular, siguen siendo los guardianes de la información del KYC. Los
+bancos comerciales observan cuándo los comerciantes reciben fondos y
+pueden limitar la cantidad de CBDC por transacción que un comerciante
+individual puede recibir, si así se requiere.
+
+Además, las transacciones están asociadas con los contratos pertinentes
+de los clientes. La transparencia de ingresos que se obtiene permite que
+el sistema cumpla con los requisitos del AML y CFT. Si se detectan
+patrones inusuales de ingresos comerciales, el banco comercial, las
+autoridades fiscales o las fuerzas del orden pueden obtener e
+inspeccionar los contratos comerciales subyacentes a los pagos para
+determinar si la actividad sospechosa es ilegal. La transparencia de los
+ingresos que se obtiene es también una fuerte medida contra la evasión
+fiscal porque los comerciantes no pueden declarar menos ingresos o
+evadir los impuestos sobre las ventas. En general, el sistema implementa
+privacidad por diseño y privacidad por omisión (como lo exige, por
+ejemplo, el Reglamento General de Protección de Datos de la Unión
+Europea). Los comerciantes no infieren inherentemente la identidad de
+sus clientes, los bancos solo tienen la información necesaria sobre las
+actividades de sus propios clientes y los bancos centrales están
+felizmente divorciados del conocimiento detallado de las actividades de
+los ciudadanos.
+
+Por razones reglamentarias, en algunos países existen límites para los
+retiros y pagos en efectivo. Dichas restricciones también podrían
+implementarse para la CBDC en el diseño propuesto. Por ejemplo, se
+podría limitar la cantidad que los consumidores puedan retirar por día,
+o limitar la cantidad total de CBDC que los bancos comerciales puedan
+convertir.
+
+Un problema potencial de estabilidad financiera que a menudo se plantea
+con las CBDC al por menor es la desintermediación del sector bancario.
+En particular, la venta de CBDC al por menor podría facilitar el
+acaparamiento de grandes cantidades de dinero del banco central. Esto
+podría afectar negativamente a la financiación de depósitos de los
+bancos porque el público tendría menos dinero en forma de depósitos
+bancarios. Para los países cuyas monedas sirven como monedas de refugio
+seguro, podría conducir a un aumento de las entradas de capital durante
+períodos de riesgo global, lo que resultaría en presiones adicionales en
+la apreciación del tipo de cambio.
+
+Si bien esto podría representar una preocupación seria en el caso de una
+CBDC basada en cuentas, la preocupación sería menor con una CBDC basada
+en tokens. En primer lugar, acumular una CBDC basada en tokens conlleva
+riesgos de robo o pérdida similares a los de acumular efectivo. Tener
+unos cientos de dólares en un teléfono inteligente es probablemente un
+riesgo aceptable para muchos, pero tener una cantidad muy grande es
+probablemente un riesgo menos aceptable. Por tanto, no esperaríamos un
+acaparamiento significativamente mayor que en el caso del efectivo
+físico.
+
+Sin embargo, si el acaparamiento o la conversión masiva a CBDC de dinero
+proveniente de depósitos bancarios se convirtieran en un problema, los
+bancos centrales tendrían varias opciones. Como se señaló, en el diseño
+propuesto los bancos centrales configuran una fecha de vencimiento para
+todas las claves de firma, lo que implica que en una fecha establecida
+las monedas firmadas con esas claves dejan de ser válidas. Cuando las
+claves de denominación caducan y los clientes tienen que cambiar monedas
+firmadas con claves de denominación antiguas por monedas nuevas, el
+regulador podría fácilmente imponer un límite de conversión por cliente
+para hacer cumplir un límite estricto a la cantidad de CBDC que
+cualquier individuo puede acumular. Además, los bancos centrales podrían
+cobrar una tarifa si fuera necesario. Una tarifa de actualización de
+este tipo, cuando las monedas están programadas para caducar, implicaría
+de hecho tasas de interés negativas en la CBDC, y haría que la CBDC
+resultara menos atractiva como depósito de valor, tal como sugiere
+Bindseil (2020). De hecho, sería la implementación directa de la idea de
+Silvio Gesell de aplicar un ``impuesto de posesión'' sobre la moneda, al
+que hace célebremente referencia Keynes (1936), y reviven Goodfriend
+(2000), Buiter y Panigirtzoglou (2003) y Agarwal y Kimball (2019).
+
+En cuanto a las posibles implicaciones para las políticas monetarias, no
+anticipamos efectos materiales porque nuestra CBDC está diseñada para
+replicar el dinero en efectivo en lugar de los depósitos bancarios. La
+emisión, retiro y depósito de nuestra CBCD corresponden exactamente a la
+emisión, retiro y depósito de billetes. Es posible que una CBDC al por
+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}}
+
+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
+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
+solo podían gastarse en su totalidad. Pagar grandes cantidades con
+monedas denominadas en centavos sería ineficiente, por lo que Okamoto
+(1995), Camenisch (2005), Canard y Gouget (2007) y Dold (2019) idearon
+formas de abordar este problema. Estas soluciones involucran protocolos
+para dar cambio o para posibilitar la divisibilidad de las monedas.
+
+Una segunda cuestión es que las transacciones a veces fallan debido a
+caídas de la red, por ejemplo. En este caso, el sistema debe permitir
+que los fondos permanezcan con el consumidor sin impacto negativo sobre
+privacidad. Camenisch et al. (2007) y Dold (2019) abordan este tema en
+su propuesta de dinero electrónico respaldado. Varias de las soluciones
+anteriores violan las garantías de privacidad para los clientes que
+utilizan estas funciones, y todas, excepto Taler, violan el requisito de
+transparencia de ingresos.
+
+La tercera cuestión importante, a menudo desatendida, es conservar la
+transparencia de los ingresos y, por lo tanto, el cumplimiento del AML y
+KYC. Fuchsbauer y col. (2009) diseñaron deliberadamente un sistema que
+posibilita la desintermediación para proporcionar una semántica más
+similar al efectivo. Sin embargo, la desintermediación ilimitada
+generalmente no concuerda con las regulaciones del AML y KYC, ya que no
+permite lograr ningún nivel de responsabilidad. Un ejemplo de tal diseño
+es ZCash, un libro mayor distribuido que oculta a la red la información
+sobre el pagador, el beneficiario y el monto de la transacción, siendo
+por lo tanto el sistema de pago perfecto para la delincuencia en línea.
+Solo Taler ofrece tanto la privacidad constante del cliente como la
+transparencia de los ingresos, al mismo tiempo que proporciona un cambio
+eficiente, intercambios atómicos (consulte Camenisch 2007) y la
+capacidad de restaurar billeteras desde una copia de seguridad.
+
+Con respecto a los sistemas de pago para las CBDC, Danezis y Meiklejohn
+(2016) diseñaron un libro mayor escalable con RSCoin. Básicamente es un
+sistema RTGS que es protegido utilizando la misma criptografía que se
+usa en Bitcoin. Al igual que Taler, el diseño utiliza la fragmentación
+de la base de datos para lograr una escalabilidad lineal. Sin embargo,
+el diseño de Danezis y Meiklejohn no tiene ninguna disposición para la
+privacidad y carece de consideraciones sobre cómo integrar prácticamente
+el diseño con los sistemas y procesos bancarios existentes.
+
+La EUROchain del Banco Central Europeo (véase ECB 2019) es otro
+prototipo para CBDC con libro mayor distribuido. Similar a la
+arquitectura propuesta en el presente documento, la EUROchain utiliza
+una arquitectura de dos niveles donde los bancos comerciales actúan como
+intermediarios. Una diferencia crucial es la manera en que los sistemas
+intentan combinar la privacidad y el cumplimiento del AML. En nuestro
+diseño, los reguladores podrían imponer un límite a la cantidad de
+efectivo electrónico que el titular de una cuenta bancaria puede retirar
+durante un cierto tiempo, mientras que la EUROchain emite un número
+limitado de "vales de anonimato" que conceden al receptor un número
+limitado de transacciones sin verificación del AML. Como estos vales
+parecen no tener ninguna relación con ningún token de valor, no queda
+claro de qué manera el diseño evitaría la aparición de un mercado negro
+de ``vales de anonimato''. Además, la noción de anonimato de la
+EUROchain es muy diferente, ya que sus "vales de anonimato" simplemente
+eliminan ciertas verificaciones del AML, al mismo tiempo que preservan
+la capacidad de los bancos comerciales de ver cómo los consumidores
+gastan el efectivo electrónico. Mientras que los pagadores usuarios de
+Taler interactúan directamente con los comerciantes para gastar su
+efectivo electrónico, el sistema EUROchain requiere que los pagadores
+instruyan a sus bancos comerciales para que accedan a su CBDC. Por lo
+tanto, la EUROchain no emite tokens de valor directamente a los
+consumidores y, en cambio, depende de que los consumidores se
+autentiquen ellos mismos en sus bancos comerciales para acceder a la
+CBDC que el banco central mantiene efectivamente en custodia. Por lo
+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}}
+\label{7.-conclusiuxf3n}}
+
+Con la aparición de Bitcoin y monedas digitales recientemente propuestas
+por grandes empresas tecnológicas como Diem (antes Libra), los bancos
+centrales se enfrentan a una competencia cada vez mayor de actores que
+ofrecen su propia alternativa digital al efectivo físico. Las decisiones
+de los bancos centrales sobre la emisión o no de una CBDC dependen de
+cómo evalúen los beneficios y los riesgos de una CBDC. Estos beneficios
+y riesgos, así como las circunstancias jurisdiccionales específicas que
+definen el alcance de las CBDC al por menor, probablemente difieran de
+un país a otro.
+
+Si un banco central decide emitir una CBDC al por menor, proponemos una
+CBDC basada en tokens que combina la privacidad de las transacciones con
+el cumplimiento del KYC, AML y CFT. Dicha CBDC no competiría con los
+depósitos de los bancos comerciales, sino que reproduciría el efectivo
+físico, lo que limitaría los riesgos de estabilidad financiera y
+políticas monetarias.
+
+Hemos demostrado que el esquema propuesto aquí sería tan eficiente y
+rentable como los sistemas RTGS modernos operados por los bancos
+centrales. Los pagos electrónicos con nuestra CBDC solo necesitarían una
+simple base de datos para las transacciones y cantidades minúsculas de
+ancho de banda. La eficiencia y la rentabilidad, junto con la facilidad
+de uso mejorada para el consumidor provocada por el cambio de la
+autenticación a la autorización, hacen que este esquema sea
+probablemente el primero en respaldar el objetivo largamente previsto de
+los micropagos en línea. Además, el uso de monedas para firmar
+criptográficamente contratos electrónicos permitiría el uso de contratos
+inteligentes. Esto también podría conducir a la aparición de
+aplicaciones completamente nuevas para los sistemas de pago. Aunque
+nuestro sistema no se basa en la DLT, podría integrarse fácilmente con
+dichas tecnologías si así lo requirieran las infraestructuras del
+mercado financiero en el futuro.
+
+Igualmente importante, sin embargo, es que una CBDC al por menor debe
+preservar el efectivo como un bien común respetuoso de la privacidad
+bajo el control individual de los ciudadanos. Esto se puede lograr con
+el esquema propuesto en este documento, y los bancos centrales pueden
+evitar perturbaciones significativas en sus políticas monetarias y
+estabilidad financiera cosechando al mismo tiempo los beneficios de la
+digitalización.
+
+\newpage
+REFERENCIAS
+
+\begin{itemize}
+\item Adrian, Tobias and Tommaso Mancini-Griffoli. 2019. ``The Rise of Digital
+Money.'' IMF Fintech Note 19/01.
+\end{itemize}
+
+\begin{itemize}
+\item Agarwal, Ruchir and Miles S. Kimball. 2019. ``Enabling Deep Negative
+Rates to Fight Recessions: A Guide.'' IMF Working Paper 19/84.
+\end{itemize}
+
+\begin{itemize}
+\item Agur, Itai, Anil Ari and Giovanni Dell'Ariccia. 2019. ``Designing
+Central Bank Digital Currencies.'' IMF Working Paper 19/252.
+\end{itemize}
+
+\begin{itemize}
+\item Allen, Sarah, Srđjan Čapkun, Ittay Eyal, Giulia Fanti, Bryan A. Ford,
+James Grimmelmann, Ari Juels, Kari Kostiainen, Sarah Meiklejohn, Andrew
+Miller, Eswar Prasad, Karl Wüst, and Fan Zhang. 2020. ``Design Choices
+for Central Bank Digital Currency: Policy and Technical
+Considerations.'' NBER Working Paper No. 27634.
+\end{itemize}
+
+\begin{itemize}
+\item Alves, Tiago and Don Felton. 2004. ``TrustZone: Integrated hardware and
+software security.'' ARM IQ, Vol. 3, No. 4, pp. 18--24.
+\end{itemize}
+
+\begin{itemize}
+\item Auer, Raphael and Rainer Böhme. 2020. ``The technology of retail central
+bank digital currency\emph{.''} BIS Quarterly Review, March 2020, pp.
+85--96.
+\end{itemize}
+
+\begin{itemize}
+\item Auer, Raphael, Giulio Cornelli and Jon Frost. 2020. ``Taking stock:
+ongoing retail CBDC projects.'' BIS Quarterly Review, March 2020, pp.
+97--98.
+\end{itemize}
+
+\begin{itemize}
+\item Bank for International Settlements. 2018. ``Central Bank Digital
+Currencies.'' Joint Report of the Committee on Payments and Market
+Infrastructures and Markets Committee.
+\end{itemize}
+
+\begin{itemize}
+\item Bank of England. 2020. ``Central Bank Digital Currency: Opportunities,
+Challenges and Design.'' Discussion Paper. March.
+\end{itemize}
+
+\begin{itemize}
+\item Baiocchi, Giovanni and Walter Distaso. 2003. ``GRETL: Econometric
+Software for the GNU Generation.'' Journal of Applied Econometrics, Vol.
+18, pp. 105-110.
+\end{itemize}
+
+\begin{itemize}
+\item Bech, Morten and Rodney Garratt. 2017. ``Central bank
+cryptocurrencies.'' BIS Quarterly Review, September, pp. 55--70.
+\end{itemize}
+
+\begin{itemize}
+\item Berentsen, Aleksander and Fabian Schär. 2018. ``The Case for Central
+Bank Electronic Money and the Non-case for Central Bank
+Cryptocurrencies.'' Federal Reserve Bank of St. Louis Review, Vol. 100,
+No. 2, pp. 97--106.
+\end{itemize}
+
+\begin{itemize}
+\item Bernstein, Daniel J. and Tanja Lange. 2020. ``eBACS: ECRYPT Benchmarking
+of Cryptographic Systems.'' https://bench.cr.yp.to, accessed 17 March
+2020.
+\end{itemize}
+
+\begin{itemize}
+\item Bernstein, Daniel J., Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin
+Yang. 2012. ``High-speed high-security signatures.'' Journal of
+Cryptographic Engineering, Vol. 2, pp. 77--89.
+\end{itemize}
+
+\begin{itemize}
+\item Bindseil, Ulrich. 2020. ``Tiered CBDC and the financial system.'' ECB
+Working Paper 2351 January.
+\end{itemize}
+
+\begin{itemize}
+\item Boar, Codruta, Henry Holden and Amber Wadsworth. 2020. ``Impending
+arrival - a sequel to the survey on central bank digital currency.'' BIS
+Papers, No. 107.
+\end{itemize}
+
+\begin{itemize}
+\item Boneh, Dan. 1999. ``Twenty Years of Attacks on the RSA Cryptosystem.''
+Notices of the AMS, Vol. 42, No. 2, pp. 202--213.
+\end{itemize}
+
+\begin{itemize}
+\item Bordo, Michael D. and Andrew T. Levin. 2017. ``Central bank digital
+currency and the future of monetary policy.'' NBER Working Papers No.
+23711.
+\end{itemize}
+
+\begin{itemize}
+\item Brunnermeier, Markus and Dirk Niepelt. 2019. ``On the Equivalence of
+Private and Public Money.'' Journal of Monetary Economics, Vol. 106, pp.
+27--41.
+\end{itemize}
+
+\begin{itemize}
+\item Buiter, Willem H. and Nikolaos Panigirtzoglou. 2003. ``Overcoming the
+Zero Bound on Nominal Interest Rates with Negative Interest on Currency:
+Gesell's Solution.'' The Economic Journal, Vol. 113, No. 490, pp.
+723--746.
+\end{itemize}
+
+\begin{itemize}
+\item Bullmann, Dirk, Jonas Klemm and Andrea Pinna. 2019. ``In search for
+stability in crypto-assets: are stablecoins the solution?'' ECB
+Occasional Paper Series No. 230.
+\end{itemize}
+
+\begin{itemize}
+\item Camenisch, J., Aanna Lysyanskaya, and Mira Meyerovich. 2007. ``Endorsed
+E-Cash.'' In: 2007 IEEE Symposium on Security and Privacy (SP '07). May:
+pp.101--115.
+\end{itemize}
+
+\begin{itemize}
+\item Camenisch, Jan, Susan Hohenberger, and Anna Lysyanskaya. 2005. ``Compact
+E-Cash.'' In: Advances in Cryptology -- EUROCRYPT 2005: 24th Annual
+International Conference on the Theory and Applications of Cryptographic
+Techniques, Aarhus, Denmark, May 22-26, 2005. Proceedings. Ed. by Ronald
+Cramer. Berlin, Heidelberg: Springer.
+\end{itemize}
+
+\begin{itemize}
+\item Canard, Sébastien and Aline Gouget. 2007. ``Divisible e-cash systems can
+be truly anonymous.'' In: Annual International Conference on the Theory
+and Applications of Cryptographic Techniques. pp. 482--97.
+\end{itemize}
+
+\begin{itemize}
+\item CCC. 2017. ``Chaos Computer Club hacks e-motor charging stations.''
+34c3.
+\end{itemize}
+
+\begin{itemize}
+\item Chapman, James, Rodney Garratt, Scott Hendry, Andrew McCormack and Wade
+McMahon. 2017. Project Jasper: Are Distributed Wholesale Payment Systems
+Feasible Yet? Bank of Canada, Financial System Review, June, pp. 59--69.
+\end{itemize}
+
+\begin{itemize}
+\item Chaum, David. 1983. ``Blind signatures for untraceable payments.''
+Advances in Cryptology: Proceedings of Crypto `82, Vol. 82, No. 3, pp.
+199--203.
+\end{itemize}
+
+\begin{itemize}
+\item Chaum, David, Amos Fiat, and Moni Naor. 1990. ``Untraceable electronic
+cash.'' Advances in Cryptology: Proceedings of CRYPTO '88, pp. 319--327.
+\end{itemize}
+
+\begin{itemize}
+\item Danezis, George and Sarah Meiklejohn. 2016. ``Centrally Banked
+Cryptocurrencies.'' In: 23nd Annual Network and Distributed System
+Security Symposium, NDSS2016, San Diego, California, USA, February
+21--24. The Internet Society.
+\end{itemize}
+
+\begin{itemize}
+\item Diffie, Whitfield and Martin Hellmann. 1976. ``New Directions in
+Cryptography''. IEEE Trans. on Inf. Theory, IT-22, pp. 644--654.
+\end{itemize}
+
+\begin{itemize}
+\item Dold, Florian. 2019. The GNU Taler System: Practical and Provably Secure
+Electronic Payments. PhD Thesis, University of Rennes 1.
+\end{itemize}
+
+\begin{itemize}
+\item European Central Bank. 2019. ``Exploring anonymity in central bank
+digital currencies.'' In: In Focus, Issue No. 4, December.
+\end{itemize}
+
+\begin{itemize}
+\item Fuchsbauer, Georg, David Pointcheval, and Damien Vergnaud. 2009.
+``Transferable constant-size fair e-cash.'' In: International Conference
+on Cryptology and Network Security. Springer. pp. 226--47.
+\end{itemize}
+
+\begin{itemize}
+\item Garcia, Flavio, Gerhard de Koning Gans, Ruben Muijrers, Peter van
+Rossum, Roel Verdult, Ronny Wichers Schreur and Bart Jacobs. 2008.
+``Dismantling MIFARE Classic.'' European Symposium on Research in
+Computer Security.
+\end{itemize}
+
+\begin{itemize}
+\item Garratt, Rod, Michael Lee, Brendan Malone, and Antoine Martin. 2020.
+``Token- or Account-Based? A Digital Currency Can Be Both.'' Liberty
+Street Economics, Federal Reserve Bank of New York, August 12, 2020.
+\end{itemize}
+
+\begin{itemize}
+\item Goodfriend, Marvin. 2000. ``Overcoming the Zero Bound on Interest Rate
+Policy.'' Journal of Money, Credit, and Banking, Vol. 32, No. 4,
+1007--35.
+\end{itemize}
+
+\begin{itemize}
+\item Johnston, Casey. 2010. ``PS3 hacked through poor cryptography
+implementation.'' Ars Technica, December 30.
+\end{itemize}
+
+\begin{itemize}
+\item Jordan, Thomas J. 2019. ``Currencies, money and digital tokens.'' Speech
+given at the 30th anniversary of the WWZ and VBÖ, University of Basel,
+September. Available at:
+www.snb.ch/en/mmr/speeches/id/ref\_20190905\_tjn/source/ref\_20190905\_tjn.en.pdf
+\end{itemize}
+
+\begin{itemize}
+\item Kahn, Charles M. and William Roberds. 2009. ``Why Pay? An Introduction
+to Payments Economics.'' Journal of Financial Intermediation, No. 18,
+pp. 1--23.
+\end{itemize}
+
+\begin{itemize}
+\item Kahn, Charles M., James McAndrews, and William Roberds. 2005. ``Money is
+Privacy.'' International Economic Review, Vol. 46, No. 2, pp. 377--399.
+\end{itemize}
+
+\begin{itemize}
+\item Kasper, Timo, Michael Silbermann and Christof Paar. 2010. ``All you can
+eat or breaking a real-world contactless payment system.'' Financial
+Cryptography and Data Security, Lecture Notes in Computer Science, Vol.
+6052, pp. 343--50.
+\end{itemize}
+
+\begin{itemize}
+\item Katzenbeisser, Stefan, Ünal Kocabaş, Vladimir Rožić, Ahmad-Reza Sadeghi,
+Ingrid Verbauwhede and Christian Wachsmann. 2012. ``PUFs: Myth, Fact or
+Busted? A Security Evaluation of Physically Unclonable Functions (PUFs)
+Cast in Silicon.'' Cryptographic Hardware and Embedded Systems -- CHES
+2012. Lecture Notes in Computer Science, Vol. 7428, pp. 283--301.
+\end{itemize}
+
+\begin{itemize}
+\item Keynes, John Maynard. 1936. The General Theory of Employment, Interest
+and Money. London: Macmillan.
+\end{itemize}
+
+\begin{itemize}
+\item Kiff, John, Jihad Alwazir, Sonja Davidovic, Aquiles Farias, Ashraf Khan,
+Tanai Khiaonarong, Majid Malaika, Hunter Monroe, Nobu Sugimoto, Hervé
+Tourpe, and Peter Zhou. 2020. A Survey of Research on Retail Central
+Bank Digital Currency. IMF Working Paper 20/104.
+\end{itemize}
+
+\begin{itemize}
+\item Kumhof, Michael and Clare Noone. 2018. ``Central bank digital currencies
+- design principles and balance sheet implications.'' Bank of England,
+Staff Working Paper No. 725.
+\end{itemize}
+
+\begin{itemize}
+\item Lapid, Ben, and Avishai Wool. 2018. ``Cache-Attacks on the ARM TrustZone
+Implementations of AES-256 and AES-256-GCM via GPU-Based Analysis.''
+International Conference on Selected Areas in Cryptography. Lecture
+Notes in Computer Science, Vol. 11349.
+\end{itemize}
+
+\begin{itemize}
+\item Lerner, Josh and Jean Tirole. 2005. ``The Scope of Open Source
+Licensing.'' Journal of Law, Economics \& Organization, Vol. 21, pp.
+20-56.
+\end{itemize}
+
+\begin{itemize}
+\item Libra Association. 2020. Libra White Paper v2.0.
+\href{https://libra.org/en-US/white-paper/}{{https://libra.org/en-US/white-paper/}}
+\end{itemize}
+
+\begin{itemize}
+\item Lim, Chae Hoon and Phil Joong Lee. 1997. ``A key recovery attack on
+discrete log-based schemes using a prime order subgroup.'' CRYPTO 1997.
+Lecture Notes in Computer Science, vol 1294.
+\end{itemize}
+
+\begin{itemize}
+\item Lyons, Richard K. and Ganesh Viswanath-Natraj. 2020. ``What Keeps
+Stablecoins Stable?'' NBER Working Paper No. 27136, May.
+\end{itemize}
+
+\begin{itemize}
+\item Mancini-Griffoli, Tommaso, Maria Soledad Martinez Peria, Itai Agur, Anil
+Ari, John Kiff, Adina Popescu, and Celine Rochon. 2018. ``Casting Light
+on Central Bank Digital Currency.'' IMF Staff Discussion Notes 18/08,
+International Monetary Fund.
+\end{itemize}
+
+\begin{itemize}
+\item Nakamoto, Satoshi. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System.
+\href{https://www.bitcoin.com/bitcoin.pdf}{{https://www.bitcoin.com/bitcoin.pdf}}
+\end{itemize}
+
+\begin{itemize}
+\item Narayanan, Arvind, Joseph Bonneau, Edward Felten, Andrew Miller, Steven
+Goldfeder. 2016. Bitcoin and Cryptocurrency Technologies: A
+Comprehensive Introduction. Princeton: Princeton University Press.
+\end{itemize}
+
+\begin{itemize}
+\item Niepelt, Dirk. 2020. Digital money and central bank digital currency: An
+executive summary for policymakers. VOX/CEPR.
+\href{https://voxeu.org/article/digital-money-and-central-bank-digital-currency-executive-summary}{{https://voxeu.org/article/digital-money-and-central-bank-digital-currency-executive-summary}}.
+\end{itemize}
+
+\begin{itemize}
+\item Okamoto, Tatsuaki. 1995. ``An Efficient Divisible Electronic Cash
+Scheme.'' Advances in Cryptology --- CRYPT0'95: 15th Annual
+International Cryptology Conference Santa Barbara, California, USA,
+August 27--31, 1995 Proceedings. Ed. by Don Coppersmith. Berlin,
+Heidelberg: Springer, pp. 438--451.
+\end{itemize}
+
+\begin{itemize}
+\item Pinto, S. and N. Santos. 2019. ``Demystifying Arm TrustZone: A
+Comprehensive Survey.'' ACM Computing Surveys, Article No. 130, January.
+\end{itemize}
+
+\begin{itemize}
+\item Rivest, Ronald L., Adi Shamir, and Leonard Adleman. 1978. ``A Method for
+Obtaining Digital Signatures and Public Key Cryptosystems''. Comm. ACM,
+Vol 21, No 2.
+\end{itemize}
+
+\begin{itemize}
+\item Solove, Daniel J. 2011. Nothing to Hide: The false tradeoff between
+privacy and security. New Haven \& London: Yale University Press.
+\end{itemize}
+
+\begin{itemize}
+\item Soukup, Michael and Bruno Muff. 2007. ``Die Postcard lässt sich
+fälschen.'' Sonntagszeitung, April 22.
+\end{itemize}
+
+\begin{itemize}
+\item Stallman, Richard. 1985. The GNU manifesto. Dr. Dobb's Journal of
+Software Tools 10(3), pp. 30--35.
+\end{itemize}
+
+\begin{itemize}
+\item Sveriges Riksbank. 2020. The Riksbank's e-krona project. February.
+https://www.riksbank.se/globalassets/media/rapporter/e-krona/2019/the-riksbanks-e-krona-pilot.pdf
+\end{itemize}
+
+\begin{itemize}
+\item Wojtczuk, Rafal and Joanna Rutkowska. 2009. ``Attacking Intel Trusted
+Execution Technology.'' BlackHat-DC 2009.
+\end{itemize}
+
+\begin{itemize}
+\item Yalta, A.Talha, and A. Yasemin Yalta. 2010. ``Should Economists Use Open
+Source Software for Doing Research?'' Computational Economics, Vol. 35,
+pp. 371--94.
+\end{itemize}
+
+\begin{itemize}
+\item Yalta, A. Talha, and Riccardo Lucchetti. 2008. ``The GNU/Linux Platform
+and Freedom Respecting Software for Economists.'' Journal of Applied
+Econometrics, Vol. 23, pp. 279-86.
+\end{itemize}
+
+\end{document}
diff --git a/doc/cbdc-es/taler_figure_1_dora_SPANISH.jpg b/doc/cbdc-es/taler_figure_1_dora_SPANISH.jpg
new file mode 100644
index 000000000..0dfd64aea
--- /dev/null
+++ b/doc/cbdc-es/taler_figure_1_dora_SPANISH.jpg
diff --git a/doc/cbdc-es/taler_figure_2_dora_SPANISH.jpg b/doc/cbdc-es/taler_figure_2_dora_SPANISH.jpg
new file mode 100644
index 000000000..75f476a9c
--- /dev/null
+++ b/doc/cbdc-es/taler_figure_2_dora_SPANISH.jpg
diff --git a/src/exchange/taler-exchange-httpd_deposits_get.c b/src/exchange/taler-exchange-httpd_deposits_get.c
index 04e2acb02..c0c6fdfe2 100644
--- a/src/exchange/taler-exchange-httpd_deposits_get.c
+++ b/src/exchange/taler-exchange-httpd_deposits_get.c
@@ -141,7 +141,7 @@ struct DepositWtidContext
    * (and the above were not set).
    * Set to #GNUNET_SYSERR if there was a serious error.
    */
-  int pending;
+  enum GNUNET_GenericReturnValue pending;
 };