[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-exchange] 01/02: math typesetting
|
From: |
gnunet |
|
Subject: |
[taler-exchange] 01/02: math typesetting |
|
Date: |
Wed, 06 Oct 2021 13:29:49 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository exchange.
commit e16892070216840d1cc9b2295288a3f0d8f8e65b
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Oct 6 13:24:56 2021 +0200
math typesetting
---
doc/cbdc-es/cbdc-es.tex | 505 +++++++++++++++++++++++-------------------------
1 file changed, 237 insertions(+), 268 deletions(-)
diff --git a/doc/cbdc-es/cbdc-es.tex b/doc/cbdc-es/cbdc-es.tex
index d38b4d12..ee6341fa 100644
--- a/doc/cbdc-es/cbdc-es.tex
+++ b/doc/cbdc-es/cbdc-es.tex
@@ -1,4 +1,4 @@
-\documentclass{article}
+\documentclass[10pt,spanish]{article}
\usepackage[a4paper,
top=2cm,
bottom=2cm,
@@ -6,57 +6,33 @@ includefoot,
left=3cm,
right=2cm,
footskip=1cm]{geometry}
-
-%\usepackage{lastpage} % enables \pageref{LastPage}
-
-%\cfoot*{\normalfont Page \pagemark{} of \normalfont \pageref{LastPage}}
-
-% Adjust variables in brackets for special indentation
-%\setlength{\parindent}{0pt}
-%\setlength{\parskip}{0.5ex plus 1pt minus 1pt}
-
-% Set fonts for a nicer PDF view
+\usepackage{url}
\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{}
-
\usepackage{graphicx}
\usepackage{mathpazo}
\usepackage{amsmath}
-%\usepackage{newtxmath}
\usepackage{mathptmx}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{color}
\usepackage[hidelinks]{hyperref}
-\clubpenalty=10000
-\widowpenalty=10000
-\displaywidowpenalty=10000
-\brokenpenalty=10000
-\doublehyphendemerits=10000
-\finalhyphendemerits=5000
-\tolerance=10000
-\urlstyle{same}
-
\begin{document}
\title{Cómo Emitir una Moneda Digital del Banco Central*}
-\author{David Chaum \textsuperscript{a},
-Christian Grothoff \textsuperscript{b}
-y Thomas Moser \textsuperscript{c}}
-\date{\today}
+\author{David Chaum\footnote{david@chaum.com} \\
+ xx Network \and
+ Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\
+ Universidad de Ciencias Aplicadas de Berna y Proyecto GNU \and
+ Thomas Moser\footnote{thomas.moser@snb.ch}\\
+ Banco Nacional de Suiza}
+\date{Primera versión: mayo 2020}
\maketitle
-\begin{center} \textsuperscript{a} xx Network,
-\textsuperscript{b} Universidad de Ciencias Aplicadas de Berna y Proyecto GNU,
-\textsuperscript{c} Banco Nacional de Suiza
-\end{center}
+\renewcommand{\abstractname}{Resumen}
+\renewcommand{\refname}{Referencias}
-\vspace{20pt}
-\begin{center}
-\vspace{20pt}
-\textbf{Resumen}
-\end{center}
-\emph{
+\begin{abstract}% [Resumen]
Con la aparición de Bitcoin y monedas estables propuestas recientemente
por grandes empresas tecnológicas como Diem (antes Libra), los bancos
centrales se enfrentan a la creciente competencia de particulares que
@@ -73,19 +49,18 @@ reglamentarios de modo convincente y ofrecer un nivel de
protección de
resistencia cuántica contra los riesgos sistémicos que amenazan la
privacidad. Ni la política monetaria ni la estabilidad financiera se
verían materialmente afectadas porque una CBDC con este diseño
-replicaría el efectivo físico en lugar de los depósitos bancarios.}
-\vspace{20pt}
+replicaría el efectivo físico en lugar de los depósitos bancarios. \\
JEL: E42, E51, E52, E58, G2
-\newline
-\newline
+\\
Keywords: Monedas digitales, banco central, CBDC, firmas ciegas, monedas
estables
+\end{abstract}
\vspace{20pt}
-\newline
-* David Chaum (david@chaum.com), Christian Grothoff
(christian.grothoff@bfh.ch),
-Thomas Moser (thomas.moser@snb.ch).
-\newline
-Agradecemos a Michael Barczay, Roman Baumann, Morten Bech, Nicolas Cuche,
+\vspace{20pt}
+
+
+\section*{Agradecimientos}
+Agradecemos a Michael Barczay, Roman Baumann, Morten Bech, Nicolas Cuche,
Florian Dold, Andreas Fuster, Stefan Kügel, Benjamin Müller, Dirk Niepelt,
Oliver Sigrist, Richard Stallman, Andreas Wehrli, y tres colaboradores
anónimos por sus comentarios y sugerencias. Las ideas, opiniones,
@@ -94,13 +69,13 @@ documento pertenecen estrictamente a los autores. No
reflejan
necesariamente los puntos de vista del Banco Nacional de Suiza (BNS). El
BNS no asume ninguna responsabilidad por errores u omisiones ni por la
exactitud de la información contenida en este documento.
-\vspace{20pt}
-\newline
-{Primera versión: mayo 2020}
+
+Traducción: Javier Sepulveda y Dora Scilipoti (verano 2021)
+
\newpage
\hypertarget{introducciuxf3n}{%
-\section{\texorpdfstring{ \textbf{Introducción}}{1. Introducción}}
+\section{Introducción}
\label{1.-introducciuxf3n}}
Desde la aparición de los ordenadores personales en los años ochenta, y
@@ -173,12 +148,12 @@ transacción, no proporciona beneficios tangibles en una
implementación
por parte de un banco central. Utilizar la DLT para emitir dinero
digital puede ser útil si no hay un banco central para empezar (p. ej.
el proyecto Sovereign de las Islas Marshall) o si la intención explícita
-es prescindir de un banco central (p. ej. Bitcoin).\footnote{Puede haber
-buenos casos de uso para la DLT en el caso de infraestructura de
-mercado financiero, tal como los intercambios digitales, donde surge la
-cuestión de como obtener dinero del banco central en la DLT a efectos de
-liquidación. Sin embargo en esas situaciones, los beneficios potenciales
-de la DLT, por ejemplo menos costes o reconciliación automática, no surgen
+es prescindir de un banco central (p. ej. Bitcoin).\footnote{Puede haber
+buenos casos de uso para la DLT en el caso de infraestructura de
+mercado financiero, tal como los intercambios digitales, donde surge la
+cuestión de como obtener dinero del banco central en la DLT a efectos de
+liquidación. Sin embargo en esas situaciones, los beneficios potenciales
+de la DLT, por ejemplo menos costes o reconciliación automática, no surgen
de una emisión descentralizada del dinero del banco central.}
La CBCD basada en tokens que se propone aquí permite también la
@@ -205,7 +180,7 @@ problemáticos incluso si las personas creen que no tienen
nada que
esconder, simplemente por la posibilidad de error y abuso,
particularmente si los programas carecen de transparencia e
imputabilidad (véase Solove 2011). Segundo, porque la privacidad en las
-transacciones protege a los usuarios frente a la explotación de datos por
parte
+transacciones protege a los usuarios frente a la explotación de datos por parte
de los proveedores de servicios de pago.
Tercero, porque protege a los usuarios frente a la contraparte en la
transacción, descartando la posibilidad de un posterior comportamiento
@@ -221,9 +196,7 @@ consideraciones políticas y normativas (5) y trabajos
relacionados (6);
en fin, concluimos (7).
\hypertarget{quuxe9-es-el-dinero-del-banco-central}{%
-\section{\texorpdfstring{ \textbf{¿Qué es el dinero del banco central?}}
-{2. ¿Qué es el dinero del banco central?}}
-\label{2.-quuxe9-es-el-dinero-del-banco-central}}
+\section{¿Qué es el dinero del banco central?}
\label{2.-quuxe9-es-el-dinero-del-banco-central}}
El dinero es un activo que puede ser usado para comprar bienes y
servicios. Para ser considerado dinero, este activo debe ser aceptado
@@ -237,13 +210,13 @@ cotizan los precios y cómo se registran las deudas)
coincide con el
medio de intercambio por razones de conveniencia. La separación puede
ocurrir, sin embargo, si el valor del medio de intercambio carece de
estabilidad en relación a los bienes y servicios
-comercializados.\footnote{Esto puede ocurrir espontáneamente en un entorno
-de alta-inflación, p. ej. cuando los precios se fijan en USD pero los pagos
-se realizan en divisa local. Lo mismo es ciertopara los pagos en Bitcoin,
-donde los precios usualmente se fijan en USA u otras divisas locales debido a
-la alta volatilidad de Bitcoin. Una eparación también puede ocurrir por el
-diseño, p. ej. en la Unidad de Fomento (UF) de Chile o la Special Drawing
Right
-(SDR) del fondo monetario internacional (IMF). Sin embargo, también entonces
el
+comercializados.\footnote{Esto puede ocurrir espontáneamente en un entorno
+de alta-inflación, p. ej. cuando los precios se fijan en USD pero los pagos
+se realizan en divisa local. Lo mismo es ciertopara los pagos en Bitcoin,
+donde los precios usualmente se fijan en USA u otras divisas locales debido a
+la alta volatilidad de Bitcoin. Una eparación también puede ocurrir por el
+diseño, p. ej. en la Unidad de Fomento (UF) de Chile o la Special Drawing Right
+(SDR) del fondo monetario internacional (IMF). Sin embargo, también entonces el
propósito es tener una unidad de cuenta más estable.} El dinero debe también
ser
un depósito de valor para poder actuar como medio de intercambio, porque
debe preservar su poder de compra desde el momento en que se recibe
@@ -339,9 +312,9 @@ monedas en relación al activo o los activos subyacentes
depende de
manera crucial de los derechos legales que adquieran los titulares de
las monedas estables. Si una moneda estable es canjeable a un precio
fijo (p. ej. 1 moneda = 1 USD, o 1 moneda = 1 onza de oro), tal
-estabilidad teóricamente se conseguirá.\footnote{Si también estabilice o
-no el valor de las monedas estables en relación con los bienes y
-servicios negociados depende de la estabilidad del valor del respectivo
+estabilidad teóricamente se conseguirá.\footnote{Si también estabilice o
+no el valor de las monedas estables en relación con los bienes y
+servicios negociados depende de la estabilidad del valor del respectivo
activo en relación con el valor de los bienes y servicios.} Lo que el esquema
esencialmente hace es replicar a los bancos comerciales garantizando la
convertibilidad al activo subyacente a la vista. Sin embargo, a
@@ -359,18 +332,18 @@ dinero (billetes o depósitos bancarios) no es muy
rentable. En
consecuencia, los proveedores de monedas estables tienen un incentivo
para economizar su tenencia de activos y trasladarse hacia un sistema de
reserva fraccionado, tal como lo hicieron los bancos comerciales.\footnote
-{La incertidumbre sobre si un moneda estable está
-totalmente garantizada puede ser una de las razones por las que una
-moneda stable puede negociarse por debajo de la par en el mercado
-secundario (véase Lyons y Ganesh Viswanath-Natraj, 2020). Este fue
-también historícamente el caso con los billetes cuando eran emitidos
-por los bancos comerciales. Tales billetes solían negociarse con
-diversos descuentos en el mercado secundario antes de que la emisión
-de billetes fuera nacionalizada y transferida al monopolio de los
-bancos centrales.} Esto implica que reducen su tenencia de activos de
-bajo rendimiento al mínimo que se considere necesario para satisfacer el
-requisito de convertibilidad. Añadiendo en cambio activos líquidos de
-alto rendimiento tales como bonos del Estado. Esto mejora la
+{La incertidumbre sobre si un moneda estable está
+totalmente garantizada puede ser una de las razones por las que una
+moneda stable puede negociarse por debajo de la par en el mercado
+secundario (véase Lyons y Ganesh Viswanath-Natraj, 2020). Este fue
+también historícamente el caso con los billetes cuando eran emitidos
+por los bancos comerciales. Tales billetes solían negociarse con
+diversos descuentos en el mercado secundario antes de que la emisión
+de billetes fuera nacionalizada y transferida al monopolio de los
+bancos centrales.} Esto implica que reducen su tenencia de activos de
+bajo rendimiento al mínimo que se considere necesario para satisfacer el
+requisito de convertibilidad. Añadiendo en cambio activos líquidos de
+alto rendimiento tales como bonos del Estado. Esto mejora la
rentabilidad pero también incrementa el nivel de riesgo.
Sin embargo, incluso si una moneda estable está garantizada al 100\% por
@@ -403,9 +376,7 @@ regulan adecuadamente. Sin embargo, la disponibilidad de
CBDC limitaría
significativamente su utilidad.
\hypertarget{diseuxf1os-simplistas-de-cbdc}{%
-\section{\texorpdfstring{ \textbf{Diseños simplistas de CBDC}}
-{3. Diseños simplistas de CBDC}}
-\label{3.-diseuxf1os-simplistas-de-cbdc}}
+\section{Diseños simplistas de CBDC} \label{3.-diseuxf1os-simplistas-de-cbdc}}
Como se ha señalado, una CBDC sería una obligación del banco central.
Dos posibles diseños que se analizan en la literatura son: (a) una CBDC
@@ -441,10 +412,10 @@ activos (tokens) incluyen información acerca de su valor
y de la entidad
que emitió el token. Por tanto, la única posibilidad de lograr la
propiedad de privacidad de la transacción como la que se obtiene con el
dinero efectivo reside en los sistemas basados en tokens.\footnote
-{Si bien el término "Bitcoin" sugiere el uso de tokens, Bitcoin es un
-sistema basado en cuentas. La única diferencia entre un sistema
-tradicional basado en cuentas y una blockchain es que las cuentas no
-se guardan en una base de datos central, sino en una base de datos
+{Si bien el término "Bitcoin" sugiere el uso de tokens, Bitcoin es un
+sistema basado en cuentas. La única diferencia entre un sistema
+tradicional basado en cuentas y una blockchain es que las cuentas no
+se guardan en una base de datos central, sino en una base de datos
descentralizada del tipo "solo por anexión".}
\hypertarget{cbdc-basada-en-cuentas}{%
@@ -567,31 +538,30 @@ pista de los clientes, lo cual no es compatible con la
privacidad de la
transacción.
\hypertarget{diseuxf1o-de-cbdc-basado-en-tokens-para-salvaguardar-la-privacidad}{%
-\section{\texorpdfstring{ \textbf{Diseño de CBDC basado en tokens para
salvaguardar la
-privacidad}}{4. Diseño de CBDC basado en tokens para salvaguardar la
-privacidad}}
+\section{Diseño de CBDC basado en tokens para salvaguardar la
+privacidad}
\label{4.-diseuxf1o-de-cbdc-basado-en-tokens-para-salvaguardar-la-privacidad}}
La CBDC que se propone aquí es de tipo "solo software", simplemente una
aplicación para teléfonos inteligentes que no requiere ningún hardware
adicional por parte de los usuarios. La CBDC se basa en eCash y GNU
Taler. Taler es parte del Proyecto GNU, cuyo fundador, Richard Stallman,
-acuñó el término "Software Libre", actualmente denominado "Software
-Libre y de Código Abierto" (Free/Libre Open Source Software --
-FLOSS).\footnote{Para más información sobre GNU, véase
-https://www.gnu.org y Stallman (1985). GNU Taler se publica
-gratuitamente bajo la Licencia Pública General Affero del Proyecto
-GNU. Otros programas del Proyecto GNU populares entre los economistas
-son «R» y ``GNU Regression, Econometrics and Time-series Library''
-(GRETL). Un análisis de los beneficios del FLOSS en comparación con el
-software privativo en el campo de la investigación puede consultarse
-en Baiocchi y Distaso (2003), Yalta y Lucchetti (2008) y Yalta y Yalta
-(2010). Sobre el licenciamiento de código abierto véase Lerner y
-Tirole (2005).} Un programa se considera "Software Libre" si la licencia
-otorga a los usuarios cuatro libertades esenciales: la libertad
-de ejecutar el programa como deseen, la libertad de estudiar el programa
-y modificarlo, la libertad de redistribuir copias del programa y la
-libertad de distribuir copias de las versiones modificadas del programa.
+acuñó el término \emph{Software Libre}, actualmente denominado \emph{Software
+Libre y de Código Abierto} (Free/Libre Open Source Software --
+FLOSS).\footnote{Para más información sobre GNU, véase
+\url{https://www.gnu.org} y Stallman (1985). GNU Taler se publica
+gratuitamente bajo la Licencia Pública General Affero del Proyecto
+GNU. Otros programas del Proyecto GNU populares entre los economistas
+son «R» y ``GNU Regression, Econometrics and Time-series Library''
+(GRETL). Un análisis de los beneficios del FLOSS en comparación con el
+software privativo en el campo de la investigación puede consultarse
+en Baiocchi y Distaso (2003), Yalta y Lucchetti (2008) y Yalta y Yalta
+(2010). Sobre el licenciamiento de código abierto véase Lerner y
+Tirole (2005).} Un programa se considera "Software Libre" si la licencia
+otorga a los usuarios cuatro libertades esenciales: la libertad
+de ejecutar el programa como deseen, la libertad de estudiar el programa
+y modificarlo, la libertad de redistribuir copias del programa y la
+libertad de distribuir copias de las versiones modificadas del programa.
El software libre no tiene por qué ser no comercial: proporcionar
soporte técnico para software es un modelo de negocio estándar para el
FLOSS.
@@ -605,24 +575,24 @@ probablemente un obstáculo para la adopción desde el
principio. Con el
FLOSS, todas las partes interesadas tienen acceso a cada detalle de la
solución y el derecho de adaptar el software a sus necesidades. Esto
conduce a una integración más fácil y una mejor interoperabilidad y
-competencia entre proveedores.\footnote{Sin embargo, puede haber otros
-roles para hardware privado. Por ejemplo, proteger los depósitos de
-claves y ciertas funciones de auditoría, en la medida en que tal
-seguridad pueda demostrarse solo como aditiva, puede ser un área donde
-el hardware dedicado evaluado por solo un número limitado de expertos
+competencia entre proveedores.\footnote{Sin embargo, puede haber otros
+roles para hardware privado. Por ejemplo, proteger los depósitos de
+claves y ciertas funciones de auditoría, en la medida en que tal
+seguridad pueda demostrarse solo como aditiva, puede ser un área donde
+el hardware dedicado evaluado por solo un número limitado de expertos
podría tener ventajas.} Además, permite que el banco central cumpla
con los requisitos de transparencia y responsabilidad. Los beneficios
del FLOSS para la seguridad son también ampliamente reconocidos. La
disponibilidad del código fuente y el derecho a modificarlo facilitan la
-detección de fallos y su rápida solución.\footnote{Por ejemplo, un
-boletín de seguridad cibernética emitido por la Agencia de Seguridad
-Nacional de EE. UU. en abril de 2020 insta a los usuarios a priorizar
-el software de código abierto en la selección y el uso de servicios de
-colaboración para la comunicación por Internet: ``El desarrollo de
-código abierto puede proporcionar confiabilidad de que el código está
-escrito para asegurar las mejores prácticas de programación y no es
-probable que introduzca vulnerabilidades o debilidades que puedan
-poner en riesgo a los usuarios y los datos '' (U / OO / 134598-20).}
+detección de fallos y su rápida solución.\footnote{Por ejemplo, un
+boletín de seguridad cibernética emitido por la Agencia de Seguridad
+Nacional de EE. UU. en abril de 2020 insta a los usuarios a priorizar
+el software de código abierto en la selección y el uso de servicios de
+colaboración para la comunicación por Internet: ``El desarrollo de
+código abierto puede proporcionar confiabilidad de que el código está
+escrito para asegurar las mejores prácticas de programación y no es
+probable que introduzca vulnerabilidades o debilidades que puedan
+poner en riesgo a los usuarios y los datos '' (U/OO/134598-20).}
En esta nuestra arquitectura que proponemos todas las interacciones del
consumidor y el comerciante son con bancos comerciales. Sin embargo, la
@@ -641,9 +611,9 @@ instrumento digital al portador porque cuando el usuario
retira una suma
de dinero en forma de número, el número es ``cegado'' u ocultado por el
teléfono inteligente con un cifrado especial. En el sistema real, una
moneda es un par de claves pública / privada, y la clave privada solo la
-conoce el propietario de la moneda.\footnote{En Bitcoin, que es un
-sistema basado en cuentas, el par de claves es una cuenta, siendo la
-clave pública la "dirección" de la cuenta y por tanto un tipo de
+conoce el propietario de la moneda.\footnote{En Bitcoin, que es un
+sistema basado en cuentas, el par de claves es una cuenta, siendo la
+clave pública la "dirección" de la cuenta y por tanto un tipo de
"identidad'', incluso si se trata de un pseudónimo.} La moneda deriva
su valor financiero de la firma del banco central en la clave pública de
la moneda. El banco central hace la firma con su clave privada y dispone
@@ -680,8 +650,8 @@ conocimiento.
esquema de firma con clave pública es que el propietario de una clave
privada es el único que puede firmar un mensaje, mientras que la clave
pública permite a cualquiera verificar la validez de la
-firma.\footnote{La criptografía de clave pública fué introducida por
-Diffie y Hellman (1976), y la primera implentación de firmas digitales
+firma.\footnote{La criptografía de clave pública fué introducida por
+Diffie y Hellman (1976), y la primera implentación de firmas digitales
fué introducida por Rivest, Shamir y Adleman (1978).} El resultado de
la función de verificación es la declaración binaria "verdadero" o
"falso". Si el mensaje está firmado con la clave privada que pertenece a
@@ -691,34 +661,34 @@ contrario es falso. En nuestra propuesta, el mensaje es
una "moneda" o
su validez. Si bien GNU Taler usa por defecto firmas EdDSA modernas
(véase Bernstein et al. 2012), presentamos un esquema de firma
criptográfica simple basado en el bien estudiado sistema criptográfico
-RSA (Rivest et al. 1978).\footnote{Para un análisis de la larga historia
-del criptosistema RSA y un estudio de los ataques al criptosistema RSA,
-consulte Boneh (1999).} Sin embargo, en principio se puede utilizar
+RSA (Rivest et al. 1978).\footnote{Para un análisis de la larga historia
+del criptosistema RSA y un estudio de los ataques al criptosistema RSA,
+consulte Boneh (1999).} Sin embargo, en principio se puede utilizar
cualquier esquema de firma criptográfica (DSA, ECDSA, EdDSA, RSA, etc.).
Para generar las claves RSA, el firmante elige primero dos grandes e
-independientes números primos \(p\) y \(q\) y calcula \(n = \emph{pq}\)
+independientes números primos $p$ y $q$ y calcula $n = \emph{pq}$
así como la función totient de Euler
-\(\phi\left( n \right) = \left( p - 1 \right)\left( q - 1 \right)\).
-Entonces, cualquier \(e\) con \(1 < e < \phi\left( n \right)\) y
-\(\emph{gcd}\left( e,\phi\left( n \right) \right) = 1\) se puede usar para
-definir una clave pública \(\left( e,n \right)\). La condición de que el
-mayor común divisor (greatest common divisor - \emph{gcd}) de \(e\) y
-\(\phi\left( n \right)\) tiene que ser 1 (p. ej., que deben ser
+$\phi(n) = (p - 1)(q - 1)$.
+Entonces, cualquier $e$ con $1 < e < \phi(n)$ y
+$\gcd(e, \phi(n)) = 1$ se puede usar para
+definir una clave pública $(e,n)$. La condición de que el
+mayor común divisor (greatest common divisor - $\gcd$) de $e$ y
+$\phi(n)$ tiene que ser 1 (p. ej., que deben ser
relativamente primos) asegura que la inversa de
-\(e \hspace*{1pt} \text{mod} \hspace*{1pt} \phi\left( n \right)\) existe.
+$e \mod \phi(n)$ existe.
Esta inversa es la
-correspondiente clave privada \emph{d}. Dado \(\phi\left( n \right)\), la clave
-privada \emph{d} se puede calcular usando el algoritmo extendido
-Euclídeo de modo que
-\(d \bullet e \equiv 1 \hspace*{1pt} \text{mod} \hspace*{1pt} \phi\left( n
\right)\).
-
-Dada la clave privada \emph{d} y la clave pública (\emph{e, n}), una firma
simple RSA
-\emph{s} sobre un mensaje \emph{m} es
-\(s \equiv m^{d} \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
-Para verificar la firma, se calcula
-\(m' \equiv s^{e} \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
-Si \(m'\) y \emph{m} coinciden, la firma es válida, lo que prueba que el
+correspondiente clave privada $d$. Dado $\phi(n)$, la clave
+privada $d$ se puede calcular usando el algoritmo extendido
+Euclídeo de modo que
+$d \cdot e \equiv 1 \mod \phi(n)$.
+
+Dada la clave privada $d$ y la clave pública $(e, n)$, una firma simple RSA
+$s$ sobre un mensaje $m$ es
+$s \equiv m^{d} \mod n$.
+Para verificar la firma, se calcula
+$m' \equiv s^{e} \mod n$.
+Si $m'$ y $m$ coinciden, la firma es válida, lo que prueba que el
mensaje fue firmado con la clave privada que pertenece a la clave
publica de verificación (autenticación de mensaje) y que ese mensaje no
ha sido cambiado en tránsito (integridad de mensaje). En la práctica,
@@ -728,7 +698,7 @@ mensajes, que son identificadores únicos y cortos para los
mensajes.
Firmar un hash corto es mucho más rápido que firmar un mensaje largo, y
la mayoría de los algoritmos de firma solo funcionan con entradas
relativamente cortas.\footnote{En el caso del criptosistema RSA el
-límite de la longitud es \(\log_{2}n\) bits.}
+límite de la longitud es $\log_{2}n$ bits.}
\emph{Firmas ciegas.} Usamos firmas ciegas, introducidas por Chaum
(1983), para proteger la privacidad de los compradores. Una firma ciega
@@ -748,38 +718,38 @@ privacidad incluso contra ataques informáticos cuánticos.
El banco
central, por su parte, establece múltiples denominaciones de pares de
claves disponibles para realizar la firma ciega de monedas con
diferentes valores, y publica/provee las correspondientes claves
-públicas \emph{(e, n)} para estos valores.
+públicas $(e, n)$ para estos valores.
-Sea \(f\) el valor hash de una moneda y por tanto un identificador único
+Sea $f$ el valor hash de una moneda y por tanto un identificador único
para esta moneda. El cliente que retira la moneda primero genera una
-factor ciego aleatorio \(b\) y calcula
-\(f' \equiv fb^{e} \hspace*{1pt} \text{mod} \hspace*{1pt} n\)
-con la clave pública del banco central para ese valor.
-La moneda cegada \(f'\) se transmite luego
-al banco central para ser firmada. El banco central firma \(f'\) con su
-clave privada \(d\) calculando la firma ciega
-\(s' \equiv \left( f' \right)^{d} \hspace*{1pt} \text{mod} \hspace*{1pt} n\),
-añade la firma \(s'\) a la moneda cegada \(f'\) y devuelve el par
-\(\left( s',f' \right)\) al cliente.
-El cliente puede entonces des-cegar la firma calculando
-\(s \equiv s'b^{- 1} \hspace*{1pt} \text{mod} \hspace*{1pt} n\).
+factor ciego aleatorio $b$ y calcula
+$f' \equiv fb^{e} \mod n$
+con la clave pública del banco central para ese valor.
+La moneda cegada $f'$ se transmite luego
+al banco central para ser firmada. El banco central firma $f'$ con su
+clave privada $d$ calculando la firma ciega
+$s' \equiv \left(f' \right)^{d} \mod n$,
+añade la firma $s'$ a la moneda cegada $f'$ y devuelve el par
+$(s',f')$ al cliente.
+El cliente puede entonces des-cegar la firma calculando
+$s \equiv s'b^{- 1} \mod n$.
Esto funciona porque
-\(\left( f' \right)^{d} = f^{d}b^{\text{ed}} = f^{d}b\) y, así,
-multiplicar \(s'\) con \(b^{- 1}\) produce \(f^{d}\), que es una firma RSA
-válida sobre \(f\) como antes:
-\(s^{e} \equiv f^{\text{de}} \equiv f \hspace*{1pt} \text{mod} \hspace*{1pt}
n\).
+$\left( f' \right)^{d} = f^{d}b^{\text{ed}} = f^{d}b$ y, así,
+multiplicar $s'$ con $b^{- 1}$ produce $f^{d}$, que es una firma RSA
+válida sobre $f$ como antes:
+$s^{e} \equiv f^{\text{de}} \equiv f \mod n$.
En la propuesta original de Chaum, las monedas eran solo tokens. Sin
embargo, nosotros queremos que los consumidores puedan realizar
contratos usando firmas digitales. Para lograrlo, cuando una billetera
digital retira una moneda, primero crea una clave privada aleatoria
-\(c\) y calcula la correspondiente clave publica \(C\) de esta moneda
+$c$ y calcula la correspondiente clave publica $C$ de esta moneda
para crear firmas digitales con esquemas de firma criptográfica
-regulares (como DSA, ECDSA, EdDSA e RSA). Entonces, se deriva \(f\)
-usando una hash criptográfica de la clave pública \(C\), que luego es
+regulares (como DSA, ECDSA, EdDSA, and RSA). Entonces, se deriva $f$
+usando una hash criptográfica de la clave pública $C$, que luego es
firmada en modalidad ciega por el banco central (usando un factor
aleatorio ciego actualizado para cada moneda). Ahora el cliente puede
-usar \(c\) para firmar compras electrónicamente, gastando así la moneda.
+usar $c$ para firmar compras electrónicamente, gastando así la moneda.
Como se ha señalado anteriormente, el banco central establecería pares
de claves para los diferentes valores de las monedas y publicaría las
@@ -792,12 +762,12 @@ similar existe para los billetes físicos, donde las
series de los
billetes se renuevan regularmente para que los billetes vayan equipados
con las últimas características de seguridad, excepto que los billetes
generalmente permanecen en circulación durante décadas en vez de por
-unos pocos meses o años.\footnote{En Suiza, por ejemplo, el Swiss
-National Bank empezó la eliminación paulatina la serie octava de
-billetes en abril de 2016. Estos billetes fueron puestos en
-circulación al final de los 90. A partir del dia 1 de enero de 2020,
-sin embargo, todos los billetes que empiezan por la serie sexta
-emitidos en 1976, así como cualquier futura serie, permanecen válidas
+unos pocos meses o años.\footnote{En Suiza, por ejemplo, el Swiss
+National Bank empezó la eliminación paulatina la serie octava de
+billetes en abril de 2016. Estos billetes fueron puestos en
+circulación al final de los 90. A partir del dia 1 de enero de 2020,
+sin embargo, todos los billetes que empiezan por la serie sexta
+emitidos en 1976, así como cualquier futura serie, permanecen válidas
y se pueden cambiar por billetes actuales de forma indefenida.}
Desde un punto de vista técnico, una fecha de vencimiento tiene dos
@@ -806,7 +776,7 @@ central puede descartar entradas vencidas y no tiene que
almacenar y
buscar una lista siempre creciente de monedas (gastadas) para detectar
el doble gasto. Segundo, reduce los riesgos de seguridad porque el banco
central no tiene que preocuparse sobre ataques contra sus claves
-(\emph{d}) de denominación (privadas) vencidas. Además , incluso si una
+($d$) de denominación (privadas) vencidas. Además , incluso si una
clave privada se ve comprometida, el tiempo durante el cual el atacante
puede usar la clave es limitado. Además cobrar una comisión por el
cambio permitiría al banco central implementar tasas de interés
@@ -833,104 +803,103 @@ intercambio justo en sistemas tradicionales de efectivo
electrónico.
La construcción matemática más común para un protocolo de intercambio de
claves es la construcción Diffie-Hellman (Diffie y Hellman 1976). Esta
permite que dos partes puedan derivar una clave secreta compartida. Para
-hacerlo, comparten dos parámetros del dominio \emph{p} y \emph{g}, que
-pueden ser públicos, donde \emph{p} es un número primo grande y \emph{g}
-es una raíz primitiva módulo \emph{p}.\footnote{Un entero \emph{g} es una raíz
-primitiva módulo \emph{p} si para cada entero \emph{a} coprimo a \emph{p} hay
-algún entero \emph{k} para el cual
-\(g^{k} \equiv a\left( \hspace*{1pt} \text{mod} \hspace*{1pt} p \right)\).
-En la práctica, \emph{g} deberia ser tal raíz primitiva \emph{p-1}, que se
-llama también generador, para prevenir ataques de subgrupo tales como ataques
+hacerlo, comparten dos parámetros del dominio $p$ y $g$, que
+pueden ser públicos, donde $p$ es un número primo grande y $g$
+es una raíz primitiva módulo $p$.\footnote{Un entero $g$ es una raíz
+primitiva módulo $p$ si para cada entero $a$ coprimo a $p$ hay
+algún entero $k$ para el cual
+$g^k \equiv a \mod p$.
+En la práctica, $g$ deberia ser tal raíz primitiva $p-1$, que se
+llama también generador, para prevenir ataques de subgrupo tales como ataques
Pohlig-Hellman (véase Lim y Pil, 1997).} Ahora, las dos partes eligen sus
claves
privadas \emph{a} y \emph{b}, que son dos números enteros grandes. Con estas
claves
privadas y los parámetros del dominio, generan sus respectivas claves
-públicas \(A \equiv g^{a} \hspace*{1pt} \text{mod} \hspace*{1pt} p\) y
-\(B \equiv g^{b} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
+públicas $A \equiv g^{a} \mod p$ y $B \equiv g^{b} \mod p$.
Cada una de las partes ahora puede usar su propia clave privada y la
clave pública de la otra parte para calcular la clave secreta compartida
-\(k \equiv \left( g^{b} \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv
g^{\text{ab}} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
-\footnote{El mismo mecanismo también se podría usar para garantizar que
-las monedas no se transfieran a un tercero durante el retiro. Para
-lograr esto, los consumidores tendrían que salvaguardar una clave de
-identidad a largo plazo. Luego, el proceso de retiro podría usar la
-misma construcción que usa GNU Taler para obtener el cambio, excepto
-que se usaría la clave de identidad a largo plazo de un cliente en
-lugar de la moneda original cuando se retira de la cuenta bancaria del
-cliente. Sin embargo, si el cliente no proteje la clave de identidad a
-largo plazo las garantías de privacidad podrían quedar anuladas con
-consecuente riesgo de robo de todas las monedas restantes. Dado el
-riesgo limitado en las transferencias a terceros al retirar monedas,
+$k \equiv \left( g \middle| b \right)^{a} \equiv \left( g^{a} \right)^{b}
\equiv g^{\text{ab}} \mod p$.
+\footnote{El mismo mecanismo también se podría usar para garantizar que
+las monedas no se transfieran a un tercero durante el retiro. Para
+lograr esto, los consumidores tendrían que salvaguardar una clave de
+identidad a largo plazo. Luego, el proceso de retiro podría usar la
+misma construcción que usa GNU Taler para obtener el cambio, excepto
+que se usaría la clave de identidad a largo plazo de un cliente en
+lugar de la moneda original cuando se retira de la cuenta bancaria del
+cliente. Sin embargo, si el cliente no proteje la clave de identidad a
+largo plazo las garantías de privacidad podrían quedar anuladas con
+consecuente riesgo de robo de todas las monedas restantes. Dado el
+riesgo limitado en las transferencias a terceros al retirar monedas,
no está claro si esta mitigación sería una buena compensación.}
Para obtener el cambio (también llamado ``vuelto''), el cliente empieza
-con la clave privada de la moneda \emph{c}. gastada parcialmente. Sea \emph{C}
la
-correspondiente clave pública, p. ej.
-\(C = g^{c} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
+con la clave privada de la moneda c. gastada parcialmente. Sea C la
+correspondiente clave pública, p. ej.
+$C = g^{c} \mod p$.
Cuando la moneda se gastó parcialmente, el banco central grabó en su base de
-datos la transacción en la que se incluye a \emph{C}. Para simplificar, daremos
+datos la transacción en la que se incluye a C. Para simplificar, daremos
por sentado que existe una denominación que coincide exactamente con el
valor residual. De no ser así, se puede simplemente ejecutar
repetidamente el protocolo de cambio hasta obtener todo el cambio
-necesario. Sea \(\left( e,n \right)\) la clave de denominación para el
+necesario. Sea $(e,n)$ la clave de denominación para el
cambio que se tiene que emitir.
-Para obtener el cambio, el cliente primero crea \(\kappa\) claves de
-transferencia privada \(t_{i}\) para
-\(i \in \left\{ 1,\ldots,\kappa \right\}\) y calcula las
-correspondientes claves públicas \(T_{i}\). Estas claves de
-transferencia \(\kappa\) son simplemente pares de claves pública-privada
+Para obtener el cambio, el cliente primero crea $\kappa$ claves de
+transferencia privada $t_{i}$ para
+$i \in \left\{ 1,\ldots,\kappa \right\}$ y calcula las
+correspondientes claves públicas $T_{i}$. Estas claves de
+transferencia $\kappa$ son simplemente pares de claves pública-privada
que permiten al cliente ejecutar localmente el protocolo de intercambio
-de claves -- con el cliente jugando en ambos lados -- \(\kappa\) veces
-entre \emph{c} y cada \(t_{i}\). Si se usa Diffie-Hellman para el protocolo de
-intercambio de claves, tendremos
-\(T_{i} \equiv g^{t_{i}} \hspace*{1pt} \text{mod} \hspace*{1pt} p\).
+de claves -- con el cliente jugando en ambos lados -- $\kappa$ veces
+entre $c$ y cada $t_{i}$. Si se usa Diffie-Hellman para el protocolo de
+intercambio de claves, tendremos
+$T_{i} \equiv g^{t_{i}} \mod p$.
El resultado son tres secretos de transferencia
-\(K_{i} \equiv \emph{KX}\left( c,t_{i} \right)\). El protocolo de
+$K_{i} \equiv \emph{KX}(c,t_{i})$. El protocolo de
intercambio de claves se puede usar de diferentes maneras para llegar al
-mismo valor
-\(K_{i} \equiv \emph{KX}\left( C,t_{i} \right) = \emph{KX}\left( c,T_{i}
\right)\).
-Dada \(K_{i}\), el cliente usa una función criptográfica hash \emph{H} para
+mismo valor
+$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$.
+Dada $K_{i}$, el cliente usa una función criptográfica hash H para
derivar valores
-\(\left( b_{i},c_{i} \right) \equiv H\left( K_{i} \right)\), donde
-\(b_{i}\) es un factor ciego válido para la clave de denominación
-\(\left( e,n \right)\) y \(c_{i}\) es una clave privada para obtener la
-moneda recién creada como cambio. \(c_{i}\) debe ser adecuada tanto para
+$(b_{i},c_{i}) \equiv H(K_{i})$, donde
+$b_{i}$ es un factor ciego válido para la clave de denominación
+$(e,n)$ y $c_{i}$ es una clave privada para obtener la
+moneda recién creada como cambio. $c_{i}$ debe ser adecuada tanto para
crear firmas criptográficas como para su futuro uso con el protocolo de
-intercambio de claves (como \emph{c}, para obtener cambio a partir del cambio).
-Sea \(C_{i}\) la clave pública correspondiente a \(c_{i}\). El cliente
+intercambio de claves (como $c$, para obtener cambio a partir del cambio).
+Sea $C_{i}$ la clave pública correspondiente a $c_{i}$. El cliente
solicita entonces al banco central que cree una firma ciega sobre
-\(C_{i}\) para \(i \in \left\{ 1,\ldots,\kappa \right\}\).\footnote
-{Si se usara el criptosistema RSA para firmas ciegas, usaríamos
-\(f \equiv \emph{FDH}_{n}\left( C_{i} \right)\), donde
-\(\emph{FDH}_{n}\left( \right)\) es el hash de dominio completo sobre
-el dominio \emph{n}.} En esta petición, el cliente también se compromete a
-las claves públicas \(T_{i}\). La petición es autorizada usando una
-firma hecha con la clave privada \emph{c}.
+$C_{i}$ para $i \in \{ 1,\ldots,\kappa\}$. \footnote
+{Si se usara el criptosistema RSA para firmas ciegas, usaríamos
+$f \equiv \emph{FDH}_{n}(C_{i})$, donde
+$\emph{FDH}_{n}()$ es el hash de dominio completo sobre
+el dominio $n$.} En esta petición, el cliente también se compromete a
+las claves públicas $T_{i}$. La petición es autorizada usando una
+firma hecha con la clave privada $c$.
En lugar de devolver directamente la firma ciega, el banco central
primero desafía al cliente para comprobar que el cliente haya usado
correctamente la construcción mencionada anteriormente proveyendo
-\(\gamma \in \left\{ 1,\ldots,\kappa \right\}\). El cliente debe
-entonces revelar al banco central la \(t_{i}\) para \(i \neq \gamma\) .
+$\gamma \in \left\{ 1,\ldots,\kappa \right\}$. El cliente debe
+entonces revelar al banco central la $t_{i}$ para $i \neq \gamma$ .
El banco central puede entonces calcular
-\(K_{i} \equiv \emph{KX}\left(C,t_{i} \right)\) y derivar los valores
-de \(\left( b_{i},c_{i} \right)\). Si para todas las \(i \neq \gamma\)
-la \(t_{i}\) provista demuestra que el cliente usó la construcción
+$K_{i} \equiv \emph{KX}(C,t_{i})$ y derivar los valores
+de $(b_{i},c_{i})$. Si para todas las $i \neq \gamma$
+la $t_{i}$ provista demuestra que el cliente usó la construcción
correctamente, el banco central devuelve la firma ciega sobre
-\(C_{\gamma}\). Si el cliente no provee una prueba correcta, se pierde
+$C_{\gamma}$. Si el cliente no provee una prueba correcta, se pierde
el valor residual de la moneda original. Esto penaliza efectivamente a
quienes intentan evadir la transparencia de sus ingresos con una tasa de
-impuestos estimada de \(1 - \frac{1}{\kappa}\).
+impuestos estimada de $1 - \frac{1}{\kappa}$.
Para evitar que un cliente conspire con un comerciante que está tratando
de ocultar sus ingresos, el banco central permite que cualquiera que
-conozca \emph{C} pueda obtener, en cualquier momento, los valores de
-\(T_{\gamma}\) y las correspondientes firmas ciegas de todas las monedas
-vinculadas a la moneda original \emph{C}. Esto permite que el propietario de la
-moneda original -- que conoce \emph{c} -- calcule
-\(K_{\gamma} \equiv \emph{KX}\left( c,T_{\gamma} \right)\) y, a partir de
-allí, pueda derivar \(\left( b_{i},c_{i} \right)\) y descifrar la firma
+conozca $C$ pueda obtener, en cualquier momento, los valores de
+$T_{\gamma}$ y las correspondientes firmas ciegas de todas las monedas
+vinculadas a la moneda original $C$. Esto permite que el propietario de la
+moneda original -- que conoce $c$ -- calcule
+$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$ y, a partir de
+allí, pueda derivar $(b_{i},c_{i})$ y descifrar la firma
ciega. En consecuencia, un comerciante que oculte sus ingresos de este
modo formaría básicamente una unión económica limitada con el cliente en
lugar de obtener un control exclusivo.
@@ -950,29 +919,29 @@ automático. La transacción entre el banco comercial del
usuario y el
banco central tiene lugar en segundo plano. El procedimiento para
retirar CBDC sería como se muestra en la Figura 1.
-\includegraphics[width=6.13681in,height=4.60208in]{taler_figure_1_dora_SPANISH.jpg}
+\includegraphics[width=\textwidth]{taler_figure_1_dora_SPANISH.jpg}
Un cliente (1) proporciona autenticación a su banco comercial usando la
autenticación respectiva del banco comercial y los procedimientos de
autorización. A continuación, el teléfono (u ordenador) del cliente
-obtiene la clave de denominación \emph{(e, n)} provista por el banco central
+obtiene la clave de denominación (e, n) provista por el banco central
para ese valor; calcula entonces (2) un par de claves para una moneda,
-con la clave privada \emph{c} y la clave pública \emph{C}, y elige un factor
de cegado
-\emph{b}. A la clave pública de la moneda se le aplica una función hash
-(→ \emph{f}) y es cegada (→ \(f'\)). A continuación, (3) el teléfono
-del cliente envía \(f'\) junto con una autorización para retirar la
+con la clave privada c y la clave pública C, y elige un factor de cegado
+$b$. A la clave pública de la moneda se le aplica una función hash
+($\to$ $f$) y es cegada ($\to$ $f'$). A continuación, (3) el teléfono
+del cliente envía $f'$ junto con una autorización para retirar la
moneda y debitar de la cuenta del cliente en el banco comercial a través
de un canal seguro establecido. El banco comercial entonces (4) debita
-la cantidad en la cuenta de depósito del cliente, (5) autoriza
+la cantidad en la cuenta de depósito del cliente , (5) autoriza
digitalmente la petición con la propia firma digital de su sucursal
bancaria y reenvía la petición y la moneda cegada al banco central para
su firma. El banco central (6) deduce el valor de la moneda en la cuenta
del banco comercial, firma la moneda de forma ciega con la clave privada
del banco central para el valor respectivo, y (7) devuelve la firma
-ciega \emph{s'} al banco comercial. (8) reenvía la firma ciega \emph{s'}
+ciega $s'$ al banco comercial. (8) reenvía la firma ciega $s'$
a la billetera electrónica del cliente. Finalmente, el teléfono del
-cliente (9) usa \emph{b} para descifrar la firma (→ \emph{f}) y almacena la
-moneda recién acuñada \emph{(c, s)}.
+cliente (9) usa b para descifrar la firma ($\to$ $f$) y almacena la
+moneda recién acuñada (c, s).
Cuando se gastan CBDC, el proceso es análogo a pagar al vendedor en
efectivo. Sin embargo, para asegurar el acuerdo, el vendedor debe
@@ -981,14 +950,14 @@ Figura 2.
Un cliente y un vendedor negocian un contrato comercial, y (1) el
cliente usa una moneda electrónica para firmar el contrato o factura de
-venta con la clave privada \emph{c} de la moneda y transmite la firma al
+venta con la clave privada c de la moneda y transmite la firma al
vendedor. La firma de una moneda en un contrato con una moneda válida es
una instrucción del cliente para pagar al vendedor que es identificado
por la cuenta bancaria en el contrato. Los clientes pueden firmar
contratos con múltiples monedas en caso de que una sola moneda fuera
insuficiente para pagar la cantidad total. El vendedor (2) valida
entonces la firma de la moneda sobre el contrato y la firma s del banco
-central sobre \emph{f} que corresponde a la \emph{C} de la moneda con las
+central sobre $f$ que corresponde a la C de la moneda con las
respectivas claves públicas y reenvía la moneda firmada (junto con la
información de la cuenta del vendedor) al banco comercial del vendedor.
El banco comercial del vendedor (3) confirma que el vendedor es uno de
@@ -1002,7 +971,7 @@ continuación, (7) el banco comercial acredita la cuenta
del vendedor e
(8) informa al vendedor. El vendedor (9) entrega el producto o servicio
al cliente. Todo el proceso dura solo unos pocos milisegundos.
-\includegraphics[width=6.13681in,height=4.60208in]{taler_figure_2_dora_SPANISH.jpg}.
+\includegraphics[width=\textwidth]{taler_figure_2_dora_SPANISH.jpg}.
\hypertarget{consideraciones-acerca-de-la-seguridad}{%
\subsection{Consideraciones acerca de la Seguridad}
@@ -1032,8 +1001,8 @@ monedas que no han gastado. El banco central anunciaría
la revocación de
clave mediante la API (Application Programming Interface), que sería
detectada por las billeteras e iniciarían el siguiente protocolo de
actualización: el usuario revela al banco central la clave pública
-\emph{C} de la moneda, la firma \emph{s} del banco central, y el factor
-ciego \emph{b}, posibilitando así que el banco central verifique el
+$C$ de la moneda, la firma $s$ del banco central, y el factor
+ciego $b$, posibilitando así que el banco central verifique el
retiro legítimo del usuario y devuelva el valor de la moneda no gastada.
Para detectar un posible compromiso de esta clave, el banco central
puede monitorear la base de datos en busca de casos de depósitos que
@@ -1099,9 +1068,7 @@ banda y computación) a escala estaría por debajo de USD
0,0001 por
transacción (para obtener detalles sobre los datos, consulte Dold 2019).
\hypertarget{consideraciones-normativas-y-poluxedticas}{%
-\section{\texorpdfstring{ \textbf{Consideraciones normativas y políticas}}
-{5. Consideraciones normativas y políticas}}
-\label{5.-consideraciones-normativas-y-poluxedticas}}
+\section{Consideraciones normativas y
políticas}\label{5.-consideraciones-normativas-y-poluxedticas}}
En el esquema propuesto, los bancos centrales no conocen la identidad de
los consumidores o comerciantes ni los montos totales de las
@@ -1188,14 +1155,12 @@ menor tenga un ritmo de circulación diferente a la del
efectivo físico,
pero esto no sería un problema material para las políticas monetarias.
\hypertarget{trabajos-relacionados}{%
-\section{\texorpdfstring{ \textbf{Trabajos relacionados}}
-{6. Trabajos relacionados}}
-\label{6.-trabajos-relacionados}}
+\section{Trabajos relacionados}\label{6.-trabajos-relacionados}}
Como se señaló anteriormente, la CBDC propuesta en el presente documento
-se basa en eCash y GNU Taler.\footnote{La implementación de eCash por la
-compañía DigiCash en los años noventa está documentada en
-\href{https://www.chaum.com/ecash}{{https://www.chaum.com/ecash}}.} A
+se basa en eCash y GNU Taler.\footnote{La implementación de eCash por la
+compañía DigiCash en los años noventa está documentada en
+\url{https://www.chaum.com/ecash}.} A
partir de la propuesta original de Chaum para el efectivo electrónico,
la investigación se ha centrado en tres cuestiones principales. Primero,
en la propuesta original de Chaum las monedas tenían un valor fijo y
@@ -1267,7 +1232,7 @@ tanto, no está claro qué ventajas de privacidad,
rendimiento o seguridad
tiene la EUROchain sobre el dinero existente en depósito.
\hypertarget{conclusiuxf3n}{%
-\section{\texorpdfstring{ \textbf{Conclusión}}{7. Conclusión}}
+\section{Conclusión}
\label{7.-conclusiuxf3n}}
Con la aparición de Bitcoin y monedas digitales recientemente propuestas
@@ -1311,6 +1276,7 @@ evitar perturbaciones significativas en sus políticas
monetarias y
estabilidad financiera cosechando al mismo tiempo los beneficios de la
digitalización.
+
\newpage
REFERENCIAS
@@ -1690,4 +1656,7 @@ and Freedom Respecting Software for Economists.'' Journal
of Applied
Econometrics, Vol. 23, pp. 279-86.
\end{itemize}
+\bibliographystyle{plain}
+\bibliography{cbdc,rfc}
+
\end{document}
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.