diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/cbdc-es/cbdc-es.tex | 182 | ||||
| -rw-r--r-- | doc/cbdc-es/cbdc.bib | 34 | ||||
| -rw-r--r-- | doc/cbdc-es/deposito.pdf | bin | 0 -> 96830 bytes | |||
| -rw-r--r-- | doc/cbdc-es/graphic-es.odp | bin | 0 -> 145669 bytes | |||
| -rw-r--r-- | doc/cbdc-es/retirada.pdf | bin | 0 -> 59155 bytes |
5 files changed, 109 insertions, 107 deletions
diff --git a/doc/cbdc-es/cbdc-es.tex b/doc/cbdc-es/cbdc-es.tex index fcf1982dc..f49c5f171 100644 --- a/doc/cbdc-es/cbdc-es.tex +++ b/doc/cbdc-es/cbdc-es.tex @@ -71,7 +71,7 @@ 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. -Traducción: Javier Sepulveda y Dora Scilipoti (verano 2021) +Traducción: Javier Sepulveda \& Dora Scilipoti (verano 2021) \newpage @@ -83,10 +83,10 @@ 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 +propuesta la realizó~\citet{Chaum1983}. 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~\cite{Nakamoto} para un sistema P2P de dinero +línea. La propuesta de~\citet{Nakamoto} 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 @@ -116,7 +116,7 @@ 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 +crédito bancario y la actividad económica~\cite[véase][]{Agur}. Sin embargo, una CBDC al por menor podría también tener beneficios~\cite[véase][]{Bordo,Berentsen,Bindseil,Niepelt,Riksbank,BoE}. Poner a disposición de @@ -292,7 +292,7 @@ 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).\nocite{Bullmann}} +de las monedas stables véase~\citet{Bullmann}.} Las ``monedas estables algorítmicas'' dependen de algoritmos para regular su suministro. En otras palabras, intentan alcanzar la @@ -380,7 +380,7 @@ 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 +banco central y sus correspondientes sistemas de pago (Kahn \& 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 @@ -464,12 +464,12 @@ 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)\nocite{Brunnermeier} argumentan que la transferencia de fondos desde un +Existen sin embargo argumentos contrarios. \citet{Brunnermeier} 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)\nocite{Berentsen} +prestamista de última instancia. \citet{Berentsen} 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 @@ -484,7 +484,7 @@ 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~\cite{Kumhof,Bindseil}. Además, para disuadir las -caídas bancarias, Kumhof y Noone (2018)\nocite{Kumhof} sugieren que las CBDC no +caídas bancarias, \citet{Kumhof} 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. @@ -496,7 +496,7 @@ cuentas requeriría un análisis más profundo de estas cuestiones. 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 +imposibles de clonar~\cite[véase][]{Katzenbeisser} y las zonas seguras en el hardware~\cite[véase][]{Alves,Pinto} 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 @@ -539,26 +539,24 @@ 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 \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)\nocite{Stallman}. 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)\nocite{Baiocchi}, Yalta y Lucchetti (2008)\nocite{Yalta2008} y Yalta y Yalta -(2010)\nocite{Yalta2010}. Sobre el licenciamiento de código abierto véase Lerner y -Tirole (2005)\nocite{Lerner}.} 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. +Taler. Taler es parte del Proyecto GNU, cuyo fundador, Richard Stallman, 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 +\citet{Stallman}. 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~\citet{Baiocchi}, \citet{Yalta2008} y \citet{Yalta2010}. Sobre el +licenciamiento de código abierto véase \citet{Lerner}.} 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 @@ -626,7 +624,7 @@ 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)\nocite{Dold} describe detalles +bancario existente para crear una CBDC. \citet{Dold} describe detalles adicionales. \hypertarget{componentes-fundamentales}{% @@ -640,25 +638,23 @@ 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)\nocite{Diffie}, y la primera implentación de firmas digitales -fué introducida por Rivest, Shamir y Adleman (1978)\nocite{Rivest}.} 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~\cite[véase][]{Bernstein2012}, presentamos un esquema de firma -criptográfica simple basado en el bien estudiado sistema criptográfico -RSA~\cite{Rivest}.\footnote{Para un análisis de la larga historia -del criptosistema RSA y un estudio de los ataques al criptosistema RSA, -consulte Boneh (1999)\nocite{Boneh}.} Sin embargo, en principio se puede utilizar -cualquier esquema de firma criptográfica (DSA, ECDSA, EdDSA, RSA, etc.). +\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~\citet{Diffie}, y la primera implentación de +firmas digitales fué introducida por~\citet{Rivest}.} 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~\cite[véase][]{Bernstein2012}, presentamos un esquema de +firma criptográfica simple basado en el bien estudiado sistema criptográfico +RSA~\cite{Rivest}.\footnote{Para un análisis de la larga historia del +criptosistema RSA y un estudio de los ataques al criptosistema RSA, +consulte~\citet{Boneh}.} 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}$ @@ -694,15 +690,14 @@ 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)\nocite{Chaum1983}, 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)\nocite{Chaum1983}. +\emph{Firmas ciegas.} Usamos firmas ciegas, introducidas +por~\citet{Chaum1983}, 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~\citet{Chaum1983}. El cegamiento lo realizan los clientes, quienes ciegan sus monedas antes de transmitirlas al banco central para ser firmadas. Los clientes por @@ -910,9 +905,13 @@ 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. +retirar CBDC sería como se muestra en la Figura~\ref{fig:fig1}. -\includegraphics[width=\textwidth]{taler_figure_1_dora_SPANISH.jpg} +\begin{figure}[h!] + \includegraphics[width=\textwidth]{retirada.pdf} + \caption{CBDC Retirada} + \label{fig:fig1} +\end{figure} Un cliente (1) proporciona autenticación a su banco comercial usando la autenticación respectiva del banco comercial y los procedimientos de @@ -939,7 +938,7 @@ 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. +Figura~\ref{fig:fig2}. 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 @@ -964,7 +963,11 @@ 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=\textwidth]{taler_figure_2_dora_SPANISH.jpg}. +\begin{figure}[h!] + \includegraphics[width=\textwidth]{deposito.pdf} + \caption{CBDC Depósito} + \label{fig:fig2} +\end{figure} \hypertarget{consideraciones-acerca-de-la-seguridad}{% \subsection{Consideraciones acerca de la Seguridad} @@ -1057,7 +1060,7 @@ 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\nocite{Dold}). +transacción (para obtener detalles sobre los datos, consulte~\citet{Dold}). \hypertarget{consideraciones-normativas-y-poluxedticas}{% \section{Consideraciones normativas y políticas}\label{5.-consideraciones-normativas-y-poluxedticas}} @@ -1134,9 +1137,8 @@ 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)\nocite{Keynes}, y reviven Goodfriend -(2000)\nocite{Goodfriend}, Buiter y Panigirtzoglou (2003)\nocite{Buiter} y -Agarwal y Kimball (2019)\nocite{Agarwal}. +referencia~\citet{Keynes}, y reviven~\citet{Goodfriend}, \citet{Buiter} +y~\citet{Agarwal}. En cuanto a las posibles implicaciones para las políticas monetarias, no anticipamos efectos materiales porque nuestra CBDC está diseñada para @@ -1149,24 +1151,22 @@ pero esto no sería un problema material para las políticas monetarias. \hypertarget{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 -\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 -solo podían gastarse en su totalidad. Pagar grandes cantidades con -monedas denominadas en centavos sería ineficiente, por lo que Okamoto -(1995)\nocite{Okamoto}, Camenisch (2005)\nocite{Camenisch2005}, -Canard y Gouget (2007)\nocite{Canard} y Dold (2019)\nocite{Dold} idearon -formas de abordar este problema. Estas soluciones involucran protocolos -para dar cambio o para posibilitar la divisibilidad de las monedas. +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 +\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 solo podían gastarse en su totalidad. Pagar grandes +cantidades con monedas denominadas en centavos sería ineficiente, por lo +que~\citet{Okamoto}, \citet{Camenisch2005}, \citet{Canard} y~\citet{Dold} +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)\nocite{Camenisch2007} y Dold (2019)\nocite{Dold} abordan este tema en +privacidad. \citet{Camenisch2007} y~\citet{Dold} 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 @@ -1174,7 +1174,7 @@ 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)\nocite{Fuchsbauer} diseñaron deliberadamente un sistema que +KYC. \citet{Fuchsbauer} 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 @@ -1187,14 +1187,14 @@ transparencia de los ingresos, al mismo tiempo que proporciona un cambio eficiente, intercambios atómicos~\cite[consulte][]{Camenisch2007} 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)\nocite{Danezis} 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. +Con respecto a los sistemas de pago para las CBDC, \citet{Danezis} 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~\citet{Danezis} 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\cite[véase][]{ECB} es otro prototipo para CBDC con libro mayor distribuido. Similar a la diff --git a/doc/cbdc-es/cbdc.bib b/doc/cbdc-es/cbdc.bib index ec6b0e66f..51c7a6812 100644 --- a/doc/cbdc-es/cbdc.bib +++ b/doc/cbdc-es/cbdc.bib @@ -53,7 +53,7 @@ @article{AuerCornelli, author = {Auer, Raphael and Giulio Cornelli and Jon Frost}, year = {2020}, - title = {Taking stock: ongoing retail CBDC projects}, + title = {Taking stock: ongoing retail {CBDC} projects}, journal = {BIS Quarterly Review}, month = {March}, pages = {97--98}, @@ -75,7 +75,7 @@ @article{Baiocchi, author = {Baiocchi, Giovanni and Walter Distaso}, year = {2003}, - title = {GRETL: Econometric Software for the GNU Generation}, + title = {{GRETL}: Econometric Software for the {GNU} Generation}, journal = {Journal of Applied Econometrics}, volume = {18}, pages = {105-110}, @@ -103,7 +103,7 @@ @article{Bernstein2020, author = {Bernstein, Daniel J. and Tanja Lange}, year = {2020}, - title = {eBACS: ECRYPT Benchmarking of Cryptographic Systems}, + title = {{eBACS}: {ECRYPT} Benchmarking of Cryptographic Systems}, url = {https://bench.cr.yp.to, accessed 17 March 2020}, } @@ -116,12 +116,13 @@ pages = {77--89}, } -@article{Bindseil, +@InCollection{Bindseil, author = {Bindseil, Ulrich}, year = {2020}, - title = {Tiered CBDC and the financial system}, - journal = {ECB Working Paper}, - volume = {2351}, + title = {Tiered {CBDC} and the financial system}, + publisher = {European Central Bank}, + series = {ECB Working Paper}, + number = {2351}, month = {January}, } @@ -136,7 +137,7 @@ @article{Boneh, author = {Boneh, Dan}, year = {1999}, - title = {Twenty Years of Attacks on the RSA Cryptosystem}, + title = {Twenty Years of Attacks on the {RSA} Cryptosystem}, journal = {Notices of the AMS}, volume = {42}, number = {2}, @@ -185,7 +186,7 @@ author = {Camenisch, Jan and Aanna Lysyanskaya and Mira Meyerovich}, year = {2007}, title = {Endorsed E-Cash}, - booktitle = {2007 IEEE Symposium on Security and Privacy (SP '07)}, + booktitle = {2007 IEEE Symposium on Security and Privacy (SP'07)}, month = {May}, pages = {101--115}, } @@ -224,7 +225,7 @@ @article{Chapman, author = {Chapman, James and Rodney Garratt and Scott Hendry and Andrew McCormack and Wade McMahon}, year = {2017}, - title = {Project Jasper: Are Distributed Wholesale Payment Systems Feasible Yet?}, + title = {Project {J}asper: Are Distributed Wholesale Payment Systems Feasible Yet?}, journal = {Financial System Review}, publisher = {Bank of Canada}, month = {June}, @@ -269,7 +270,7 @@ @phdthesis{Dold, author = {Dold, Florian}, year = {2019}, - title = {The GNU Taler System: Practical and Provably Secure Electronic Payments. PhD Thesis}, + title = {The {GNU} {T}aler System: Practical and Provably Secure Electronic Payments. PhD Thesis}, school = {University of Rennes 1}, } @@ -371,8 +372,8 @@ @inproceedings{Katzenbeisser, author = {Katzenbeisser, Stefan and Ünal Kocabaş and Vladimir Rožić and Ahmad-Reza Sadeghi and Ingrid Verbauwhede and Christian Wachsmann}, year = {2012}, - title = {PUFs: Myth, Fact or Busted? A Security Evaluation of Physically Unclonable Functions (PUFs) Cast in Silicon}, - journal = {Cryptographic Hardware and Embedded Systems -- CHES 2012. Lecture Notes in Computer Science}, + title = {{PUF}s: Myth, Fact or Busted? A Security Evaluation of Physically Unclonable Functions ({PUF}s) Cast in Silicon}, + booktitle = {Cryptographic Hardware and Embedded Systems -- CHES 2012. Lecture Notes in Computer Science}, volume = {7428}, pages = {283--301}, } @@ -404,7 +405,7 @@ @inproceedings{Lapid, author = {Lapid, Ben and Avishai Wool}, year = {2018}, - title = {Cache-Attacks on the ARM TrustZone Implementations of AES-256 and AES-256-GCM via GPU-Based Analysis}, + title = {Cache-Attacks on the {ARM} TrustZone Implementations of {AES}-256 and {AES}-256-{GCM} via {GPU}-Based Analysis}, booktitle = {International Conference on Selected Areas in Cryptography. Lecture Notes in Computer Science}, volume = {11349}, } @@ -486,7 +487,7 @@ @article{Pinto, author = {Pinto, S. and N. Santos}, year = {2019}, - title = {Demystifying Arm TrustZone: A Comprehensive Survey}, + title = {Demystifying {ARM} TrustZone: A Comprehensive Survey}, journal = {ACM Computing Surveys}, volume = {51}, number = {6}, @@ -533,7 +534,8 @@ @TechReport{Riksbank, author = {{Sveriges Riksbank}}, year = {2020}, - title = {The Riksbank's e-krona project. February}, + title = {The {R}iksbank's e-krona project}, + month = {Feb}, institution = {Sveriges Riksbank}, url = {https://www.riksbank.se/globalassets/media/rapporter/e-krona/2019/the-riksbanks-e-krona-pilot.pdf}, } diff --git a/doc/cbdc-es/deposito.pdf b/doc/cbdc-es/deposito.pdf Binary files differnew file mode 100644 index 000000000..b798478d1 --- /dev/null +++ b/doc/cbdc-es/deposito.pdf diff --git a/doc/cbdc-es/graphic-es.odp b/doc/cbdc-es/graphic-es.odp Binary files differnew file mode 100644 index 000000000..818c2b185 --- /dev/null +++ b/doc/cbdc-es/graphic-es.odp diff --git a/doc/cbdc-es/retirada.pdf b/doc/cbdc-es/retirada.pdf Binary files differnew file mode 100644 index 000000000..c723330b6 --- /dev/null +++ b/doc/cbdc-es/retirada.pdf |