report progress

2 files changed, 111 insertions, 39 deletions

diff --git a/docs/literature.bib b/docs/literature.bib
new file mode 100644
index 0000000..9a0b0ad
--- /dev/null
+++ b/docs/literature.bib
@@ -0,0 +1,59 @@
+@article{nakamoto2008bitcoin,

+  title   = {Bitcoin whitepaper},

+  author  = {Nakamoto, Satoshi},

+  journal = {URL: https://bitcoin. org/bitcoin. pdf-(: 17.07. 2019)},

+  year    = {2008}

+}

+

+@inproceedings{gervais2016security,

+  title     = {On the security and performance of proof of work blockchains},

+  author    = {Gervais, Arthur and Karame, Ghassan O and W{\"u}st, Karl and Glykantzis, Vasileios and Ritzdorf, Hubert and Capkun, Srdjan},

+  booktitle = {Proceedings of the 2016 ACM SIGSAC conference on computer and communications security},

+  pages     = {3--16},

+  year      = {2016}

+}

+

+@techreport{RFC8905,

+  author       = {F. Dold and C. Grothoff},

+  title        = {The 'payto' URI Scheme for Payments},

+  howpublished = {Internet Requests for Comments},

+  type         = {RFC},

+  number       = {8905},

+  year         = {2020},

+  month        = {October},

+  issn         = {2070-1721},

+  publisher    = {RFC Editor},

+  institution  = {RFC Editor}

+}

+

+@techreport{BIP125,

+  author      = {David A. Harding and Peter Todd},

+  title       = {Opt-in Full Replace-by-Fee Signaling},

+  type        = {BIP},

+  number      = {125},

+  year        = {2015},

+  month       = {December},

+  institution = {Bitcoin Improvement Proposals}

+}

+

+@techreport{BIP173,

+  author      = {Pieter Wuille and Greg Maxwell},

+  title       = {Base32 address format for native v0-16 witness outputs},

+  type        = {BIP},

+  number      = {173},

+  year        = {2017},

+  month       = {Mars},

+  institution = {Bitcoin Improvement Proposals}

+}

+

+

+@article{bartoletti2019journey,

+  title     = {A journey into bitcoin metadata},

+  author    = {Bartoletti, Massimo and Bellomy, Bryn and Pompianu, Livio},

+  journal   = {Journal of Grid Computing},

+  volume    = {17},

+  number    = {1},

+  pages     = {3--22},

+  year      = {2019},

+  publisher = {Springer}

+}
\ No newline at end of file
diff --git a/docs/report.tex b/docs/report.tex
index 0c03429..3e54446 100644
--- a/docs/report.tex
+++ b/docs/report.tex
@@ -7,6 +7,7 @@
 \usepackage{tikz}

 \usepackage{float}

 \usepackage{authblk}

+\usepackage{acro}

 

 \usetikzlibrary{positioning,fit}

 

@@ -15,6 +16,15 @@
 \affil{Bern University of Applied Sciences}

 \date{\today}

 

+\DeclareAcronym{dlt}{

+  short=DLT,

+  long=Distributed Ledger,

+}

+\DeclareAcronym{dos}{

+  short=DOS,

+  long=Denial of service,

+}

+

 \begin{document}

 

 \maketitle

@@ -43,11 +53,11 @@ I would like to kindly thank Christian Grothoff and Emmanuel Benoist (Bern Unive
 

 \section{Blockchain-based cryptocurrencies}

 

-A cryptocurrency is a digital currency that relies on code and especially cryptography to secure transactions without a central authority. It is important to understand the basis of how they work and their limitations to understand the integration challenges they pose. For this project, only the two most famous, Bitcoin and Ethereum, were integrated. While other blockchain-based cryptocurrencies may work differently, we are only interested in the specific similarities between these two.

+A cryptocurrency is a digital currency that relies on code and especially cryptography to secure transactions without a central authority. It is important to understand the basis of how they work and their limitations to understand the integration challenges they pose. For this project, only the two most used one, Bitcoin and Ethereum, were integrated. While other blockchain-based cryptocurrencies may work differently, we are only interested in the specific similarities between these two.

 

 \subsubsection*{Bitcoin}

 

-Bitcoin is the first cryptocurrency to achieve a successful public rollout. Invented by an unknown person or group of people working under the name of Satoshi Nakamoto, it was first mentioned in his white paper published the 31 October 2009 \cite{nakamoto2008bitcoin}. Bitcoin assembled the technological foundation for many of the cryptocurrencies in use today.

+Bitcoin is the first cryptocurrency to achieve a successful public rollout. Invented by an unknown person or group of people working under the name of Satoshi Nakamoto, it was first mentioned in his white paper published the 28 October 2008 \cite{nakamoto2008bitcoin}. Bitcoin assembled the technological foundation for many of the cryptocurrencies in use today.

 

 \subsubsection*{Ethereum}

 

@@ -55,17 +65,17 @@ Bitcoin is focused on currency transfer transactions and some people wanted to d
 

 \subsection{Blockchain}

 

-At the heart of these currencies is a blockchain. A blockchain is an append-only database composed of a list of linked records called blocks. The content of each block, except the genesis block (the first block), depends on the content of its parent block. This chained dependency enforces the immutability of the database, preventing retroactive modification whiteout altering all subsequent blocks. Transactions are stored inside those blocks.

+At the heart of these currencies is a blockchain. A blockchain is an append-only database composed of a list of linked records called blocks. The content of each block, except the genesis block (the first block), depends on the content of its parent block. This chained dependency enforces the immutability of the database, preventing retroactive modification whiteout altering all subsequent blocks. Cryptocurrency transactions takes effect when they are stored inside those blocks.

 

 \subsection{Consensus}

 

-The blockchain itself is just a storage system. To make it a distributed ledger (DLT), it needs a peer-to-peer network to share its changes. But also a way for participants (nodes) to agree on a single state of the chain, to reach consensus in a network where nodes can be malicious and have an economic interest in deceiving others. There are many ways to create such consensus, but only two of them interest us: proof of work and proof of stake.

+The blockchain itself is just a storage system. To make it a \acf{dlt}, it needs a peer-to-peer network to share its changes. But also a way for participants (nodes) to agree on a single state of the chain, to reach consensus in a network where nodes can be malicious and have an economic interest in deceiving others. There are many ways to create such consensus, but only two of them interest us: proof of work and proof of stake.

 

 % DLT definition ?

 

 \subsubsection*{Proof of work}

 

-This mechanism consists in making the process of appending a block to the blockchain heavy in computation (mining) by requiring brute force hashing for example. Nodes, willing to invest their computation power (miners), work to extend the chain they consider the current state. Over time, the longest chain will be the one where the majority of computing power has been invested, which means that it is the one followed by the majority miners.

+This mechanism consists in making the process of appending a block to the blockchain heavy in computation (mining) by requiring brute force hashing for example. Nodes willing to invest their computation power (miners), work to extend the chain they consider the current state. Over time, the longest chain will be the one where the majority of computing power has been invested, which means that it is the one followed by the majority of miners.

 

 This falls short as soon as one node control significantly more computation power than others, the so-called 51\% attacks. This node will not be able to create invalid blocks, because the other nodes will reject them, but will be able to rewrite the past and control the mining of future transactions.

 

@@ -79,15 +89,15 @@ The effectiveness and security of this mechanism have yet to be proven, but Ethe
 

 \subsubsection*{Block time}

 

-Achieving consensus within the peer-to-peer network requires broadcasting the state of the blockchain to most nodes. This coordination takes some time and we do not want blocks to be mined faster than the network can keep up. The difficulty algorithm is used to keep the block time close to a constant. On Ethereum, the block time is 12 to 14 seconds \footnote{https://ethereum.org/en/developers/docs/blocks/\#block-time}. On Bitcoin, the block time is about 10 minutes.

+Achieving consensus within the peer-to-peer network requires broadcasting the state of the blockchain to most nodes. This coordination takes some time and we do not want blocks to be mined faster than the network can keep up. An adaptive difficulty algorithm is used to keep the block time close to a constant, by changing the amount of computation required to mine a block. On Ethereum, the block time is about 12 to 14 seconds \footnote{https://ethereum.org/en/developers/docs/blocks/\#block-time}. On Bitcoin, the block time is about 10 minutes.

 

 \subsubsection*{Reorganisation}

 

-These decentralized consensus mechanisms lead to the creation of competing blockchain states. When two miners broadcast a new valid block in a short period of time, one part of the network may receive them in a different order than another part. As nodes will follow the first valid block founded, we have a blockchain fork. Over time, one fork will become longer than the other, and nodes will follow the longer chain. They will replace recent blocks as necessary during a reorganization of the blockchain. A reorganization can cause a transaction previously considered mined by a node to no longer be mined. Therefore, blockchain transactions lack finality.

+These decentralized consensus mechanisms lead to the creation of competing blockchain states. When two miners broadcast a new valid block in a short period of time, one part of the network may receive them in a different order than another part. As nodes will follow the first valid block they found, we have a blockchain fork where two different blokchain state are followed in the network. Over time, one fork will become longer than the other, and nodes will follow the longer chain. They will replace recent blocks as necessary during a reorganization of the blockchain. A reorganization can cause a transaction previously considered mined by a node to no longer be mined. Therefore, blockchain transactions lack finality.

 

 \subsection{Mining incentive}

 

-A minimum amount of mining power is required for the cryptocurrency to work. Without new blocks, there can be no new transaction. The more mining power and diversity (different miners), the more resistant the currency is to attacks. Since mining is an expensive process, cryptocurrencies must incentivize it by offering rewards to miners.

+A minimum amount of mining power is required for the cryptocurrency to work. Without new blocks, there can be no new transaction. The more mining power and diversity (different miners), the more resistant the \ac{dlt} is to attacks. Since mining is an expensive process, cryptocurrencies must incentivize it by offering rewards to miners.

 

 Rewards are of two kinds:

 \begin{itemize}

@@ -128,7 +138,7 @@ A merchant accepts coins in exchange for goods and services. The merchant can th
 Auditors monitor the behaviour of the exchanges to ensure that exchanges operate correctly. They are typically operated by financial regulators.

 

 \subsubsection*{Settlement layer}

-The settlement layer provides finality for wire transfers that allow customers to deposit money and merchant to withdraw money from Taler. This settlement layer is typically provided by banks. The goal of this project is to use blockchains as a settlement layer to support blockchain-based cryptocurrencies.

+The settlement layer provides finality for wire transfers that allow customers to deposit money and merchant to withdraw money from Taler. It is typically provided by banks. The goal of this project is to use blockchains as a settlement layer to support blockchain-based cryptocurrencies.

 

 \subsection{Blockchain settlement layer}

 

@@ -136,10 +146,10 @@ The settlement layer provides finality for wire transfers that allow customers t
     \begin{center}

         \input{figures/settlement_layer.tex}

     \end{center}

-    \caption{Blockchain settlement layer}

+    \caption{Blockchain settlement layer with Depolymerizer}

 \end{figure}

 

-Depolymerization serves as a middleware between GNU taler and blockchain-based cryptocurrencies. Customers can send money to the Depolymerizer using an on-chain transaction to get coins that they can use in off-chain transactions. Using the Depolymerizer, Taler exchanges can materialize coins back into the blockchain.

+Depolymerizer serves as a middleware between GNU taler and cryptocurrencies \ac{dlt}. Customers can send money to the Depolymerizer using an on-chain transaction to get coins that they can use in off-chain transactions. Using the Depolymerizer, Taler exchanges can materialize coins back into the blockchain.

 

 Off-chain transactions have many advantages over on-chain transactions. At the cost of putting trust in exchange operators or auditors, you can have fast and low cost transactions with instant confirmation (ms). GNU Taler offers linear scalability that can solve blockchain throughput limitation and, by not relying on Proof of Work, has a much lower ecological impact. GNU Taler does not sacrifice privacy either; it provides privacy when it can and transparency when it has to (regulation: avoid tax evasion and money laundering). 

 

@@ -239,7 +249,7 @@ Outgoing transactions can be of two types credit or bounce. Credit metadata cont
                 \bitbox{1}{\tiny 0} & \bitbox{32}{Transfer ID} & \bitbox{10}{Base URL}

             \end{rightwordgroup} \\ \\

             \begin{rightwordgroup}{Bounce}

-                \bitbox{1}{\tiny \rotatebox{90}{255}} & \bitbox{32}{Transaction ID}

+                \bitbox{1}{\tiny \rotatebox{90}{254}} & \bitbox{32}{Transaction ID}

             \end{rightwordgroup}

         \end{bytefield}

     \end{center}

@@ -252,7 +262,7 @@ There are many documented ways to encode metadata in a bitcoin transaction \cite
 

 Debits are performed from code using OP\_RETURN to store metadata, but credits are done from common wallet clients and they do not yet support custom metadata. We had to find another format using fake addresses.

 

-We use the latest address type, segwit addresses, which can contain 20B of chosen data, and the reserve pub key is 32B. Therefore, we use two fake addresses consisting of the two key halves prepended with the same random pattern, except for the first bit, which must be 0 for the first half and 1 for the second. We then send a single transaction with the three addresses as recipients.

+We use the latest address type, segwit addresses, which can contain 20B of chosen data. The reserve pub key being 32B, we need two addresses. Therefore, we use two fake addresses consisting of the two key halves prepended with the same random pattern, except for the first bit, which must be 0 for the first half and 1 for the second. We then send a single transaction with three addresses as recipients.

 

 \begin{figure}[H]

     \begin{center}

@@ -286,13 +296,13 @@ Ethereum is designed around the concept of smart contracts. Logging inside a sma
 

 \subsection{Friendly behavior on format error}

 

-When we receive a transaction without any metadata or with an incompatible format (bogus wallet), we want to return the money to its owner (bounce). However, this is dangerous because we have created a potential attack loophole as anyone can now make Depolymerizer do a transaction, by sending a malformed transaction. Depolymerizer takes a bounce fee to make a potential DOS attack too costly and charges the recipient the transaction fee to ensure it can not lose money on a bounce.

+When we receive a transaction without any metadata or with an incompatible format (bogus wallet), we want to return the money to its owner (bounce). However, this is dangerous because we have created a potential attack loophole as anyone can now make Depolymerizer do a transaction, by sending a malformed transaction. Depolymerizer takes a bounce fee to make a potential \acs{dos} attack too costly and charges the recipient the transaction fee to ensure it can not lose money on a bounce.

 

 \clearpage

 

 \section{Architecture}

 

-Each cryptocurrency uses a different distributed ledger (DLT) with its own format and rules, which evolve over time. We do not want to manage the DLT logic ourselves, nor do we want to rely on third-party dependencies to implement their support properly and be maintained. The simplest solution is to rely on the official clients and communicate with them via RPC.

+Each cryptocurrency uses a different \ac{dlt} with its own format and rules, which evolve over time. We do not want to manage the \ac{dlt} logic ourselves, nor do we want to rely on third-party dependencies to implement their support properly and be maintained. The simplest solution is to rely on the official clients and communicate with them via RPC.

 

 \begin{figure}[hb]

     \begin{center}

@@ -301,9 +311,9 @@ Each cryptocurrency uses a different distributed ledger (DLT) with its own forma
     \caption{Depolymerizer architecture}

 \end{figure}

 

-While some parts of Depolymerizer are DLT specific, much of the logic is common and we want to reuse it. We have a Wire Gateway component that implements the Taler HTTP API to enable communication with Taler exchanges. Each supported cryptocurrency has its specific adapter to communicate with the official full node client via RPC. The Wire Gateway module and the DLT adapter use a common database to store transactions and communicate with notifications.

+While some parts of Depolymerizer are \ac{dlt} specific, much of the logic is common and we want to reuse it. We have a Wire Gateway component that implements the Taler HTTP API to enable communication with Taler exchanges. Each supported cryptocurrency has its specific adapter to communicate with the official full node client via RPC. The Wire Gateway module and the \ac{dlt} adapter use a common database to store transactions and communicate with notifications.

 

-\subsection{DLT adapter}

+\subsection{\acs{dlt} adapter}

 

 The DTL adapter uses an event-based architecture with three distinct loops.

 

@@ -317,21 +327,21 @@ The analysis loop waits for new blocks and then analyzes the behavior of the blo
 

 \paragraph*{Worker}

 

-The worker loop waits for new blocks or transaction requests (from the Wire Gateway API). When one of these events occurs, it first reconciles the local database with the DLT, then triggers requested debits, re-issues blocked debits and bounces malformed credits.

+The worker loop waits for new blocks or transaction requests (from the Wire Gateway API). When one of these events occurs, it first reconciles the local database with the \ac{dlt}, then triggers requested debits, re-issues blocked debits and bounces malformed credits.

 

 \subsection{Worker loop in detail}

 

-\subsubsection*{DLT reconciliation}

+\subsubsection*{\acs{dlt} reconciliation}

 

-During a DLT reconciliation, we first list all new transactions and any transactions that have been deleted in a reorganization since the last reconciliation. If any previously confirmed debits have been deleted without being reinserted into another block, we notify the Wire Gateway to cease activity and wait for the next block in hopes of recovering them. All newly confirmed debits and successful credits are registered in the database.

+During a \ac{dlt} reconciliation, we first list all new transactions and any transactions that have been removed in a reorganization since the last reconciliation. If any previously confirmed debits have been removed without being reinserted into another block, we notify the Wire Gateway to cease activity and wait for the next block in hopes of recovering them. All newly confirmed debits and successful credits are registered in the database.

 

 \subsubsection*{Reconciliation inconsistency}

 

-When we issue a transaction (debit or bounce), it is possible for the database or DLT request to fail. Since a DLT request does not mean that the cryptocurrency transaction was not successful and since the database may not record a successful transaction, it is possible to have an inconsistency in the DLT and the database where a successful transaction is not recorded as such. This is very problematic because we must perform each transaction once.

+When we issue a transaction (debit or bounce), it is possible for the database or \ac{dlt} request to fail. Since a \ac{dlt} request does not mean that the cryptocurrency transaction was not successful, and since the database may not record a successful transaction, it is possible to have an inconsistency between the DLT and the database where a successful transaction is not recorded as such. This is very problematic because we must perform each transaction once.

 

-This is also problematic because even if we used a status machine state in the database to detect this inconsistency, the only way to resolve it is to make another DLT reconciliation, which is slow and does not play well with database locking.

+This is also problematic because, even if we used a status machine state in the database to detect this inconsistency, the only way to resolve it is to make another \ac{dlt} reconciliation, which is slow and does not play well with database locking.

 

-Since we know that blockchain-based cryptocurrencies have low throughput, we don not need parallel worker loops to stay synchronized. Therefore, we can use a cross-process locking mechanism to ensure that only one working loop is running at a time. Then, when a database or DLT request error occurs, we can restart the loop, which will start by performing a DLT reconciliation that will recover all successful unregistered transactions.

+Since we know that blockchain-based cryptocurrencies have low throughput, we do not need parallel worker loops to stay synchronized. Therefore, we can use a cross-process locking mechanism to ensure that only one working loop is running at a time. Then, when a database or \ac{dlt} request error occurs, we can restart the loop, which will start by performing a \ac{dlt} reconciliation that will recover all successful unregistered transactions.

 

 \clearpage

 

@@ -339,9 +349,9 @@ Since we know that blockchain-based cryptocurrencies have low throughput, we don
 

 \subsection*{Ethereum amount precision}

 

-The Taler amount format comes from RFC 8905\cite{RFC8905}. It allows up to $2^{53}$ unit and 8 decimal digits. This format is perfectly suited for Bitcoin where the maximal amount is 21 million bitcoins and the minimum amount is the satoshi, one satoshi being worth 108 bitcoin. However, the minimum amount of Ethereum is the wei, with one ether being worth $10^{18}$ wei. The amount of ether in circulation continues to grow without a cap, with over 119 000 000 ether in circulation at the time of writing. Therefore, it is not possible to represent all Ethereum amounts with the current format.

+The Taler amount format comes from RFC 8905 \cite{RFC8905}. It allows up to $2^{53}$ unit and 8 decimal digits. This format is perfectly suited for Bitcoin where the maximal amount is 21 million bitcoins and the minimum amount is the satoshi, one satoshi being worth $10^{8}$ bitcoin. However, the minimum amount of Ethereum is the wei, with one ether being worth $10^{18}$ wei. The amount of ether in circulation continues to grow without a cap, with over 119.000.000 ether in circulation at the time of writing those lines. Therefore, it is not possible to represent all Ethereum amounts with the current format.

 

-A standard Ethereum transaction requires 21 000 units of gas \footnote{https://ethereum.org/en/developers/docs/gas/\#post-london}. The average gas price is currently around 30 Gwei. Therefore, a standard transaction cost about $63.10^{18}$Wei in transaction fees. Since the transaction fee is so high, even if we truncate Ethereum value to its 8 first decimal, we can still represent any amount you can send whiteout losing money on the transaction fee.

+A standard Ethereum transaction requires 21 000 units of gas \footnote{https://ethereum.org/en/developers/docs/gas/\#post-london}. The average gas price is currently around 30 Gwei. Therefore, a standard transaction cost about $63.10^{18}$ wei in transaction fees. Since the transaction fee is so high, even if we truncate Ethereum value to its 8 first decimal, we can still represent any amount you can send whiteout losing money on the transaction fee.

 

 \subsection*{Replaceable bitcoin transaction}

 

@@ -349,7 +359,7 @@ When some merchants wanted to allow instant payments with Bitcoin, they chose to
 

 This becomes problematic when you want to make a legitimate replacement, to unstuck a transaction by increasing its transaction fee for example. At the same time, it is always dangerous to give an easy way to attackers and scammers to change the content of a pending transaction.

 

-A solution has been adopted in BIP 125 \cite{BIP125}. It is now possible to encode the replaceability of a bitcoin transaction when creating it. This allows it to be replaced by a new transaction within certain rules: you cannot send less money to existing recipients and you must pay a replacement fee as a countermeasure to a DOS attack.

+A solution has been adopted in BIP 125 \cite{BIP125}. It is now possible to encode the replaceability of a bitcoin transaction when creating it. This allows it to be replaced by a new transaction within certain rules: you cannot send less money to existing recipients and you must pay a replacement fee as a countermeasure to a \acs{dos} attack.

 

 \clearpage

 

@@ -357,22 +367,22 @@ A solution has been adopted in BIP 125 \cite{BIP125}. It is now possible to enco
 

 \subsection*{The need for compact URI}

 

-As discussed in the previous chapter, storing metadata in blockchain is

-expensive and limited. Therefore we want our metadata to be as small as possible.

+As discussed previously, storing metadata in blockchain is

+expensive and limited. Therefore, we want our metadata to be as small as possible.

 

 \noindent

 Transactions metadata are composed of three parts:

 \begin{itemize}

     \item Version and identity metadata ($\sim$ 1B)

     \item Reserve public key or wire transfer id (32B)

-    \item Base uri (debit only, variable)

+    \item Base url (debit only, variable)

 \end{itemize}

 

-The only variable and so problematic part is the base url. Those url have some

+The only variable, and so problematic, part is the base url. Those url have some

 property in common, they always use a few different scheme (http or https) and

 are composed of a domain and a small path.

 

-We would normally encode the url using ASCII but we known only a few ASCII

+We would normally encode the url using ASCII, but we known only a few ASCII

 character are actually used.

 

 \subsection*{5 or 11 encoding}

@@ -380,7 +390,7 @@ character are actually used.
 Our idea is to encode the most commonly used characters using five bits, and the

 remaining characters using eleven bits. As an ASCII character take eights bits

 we gain on size if more than half of the characters composing the uri are

-encodable using only 5 bits.

+encodable using less bits.

 

 \begin{center}

     \begin{tabular}{l l l}

@@ -394,8 +404,7 @@ encodable using only 5 bits.
 

 Using this encoding format on all domains on the

 majestic-million\footnote{https://majestic.com/reports/majestic-million}

-database, $98.77\%$ of the domain name where smaller, going from an average encoded

-size of 14B in ASCII to 10B using our format.

+database, $98.77\%$ of the domain name where smaller, going from an average encoded size of 14B in ASCII to 10B using our format.

 

 \subsection*{Uri in metadata}

 

@@ -403,7 +412,7 @@ To further optimize metadata size we chose to encode the URI scheme into the
 version and identity metadata byte and the remaining domain and path using our

 custom format.

 

-For example for bitcoin the maximum amount of data than is accepted in

+For example, for bitcoin the maximum amount of data than is accepted in

 OP\_RETURN is currently 80 bytes, leaving us 47 bytes to store the URI. With our

 encoding we can encode in the best case 74 characters instead of 47 which is more

 enough for our use case.

@@ -412,17 +421,17 @@ enough for our use case.
 

 \section{Taler Wire Gateway HTTP API}

 

-Taler is a modular project where each module communicates through HTTP API. The Wire Gateway API allows the exchange to communicate to wire adaptors. My first task was to implement a server in Rust to link the depolymerizer implementation to the Taler system. As the API can be exposed on the Internet it has to be resistant to easy attacks.

+Taler is a modular project where each module communicates through HTTP API. The Wire Gateway API allows the exchange to communicate to wire adaptors. The Wire Gateway module allow Depolymerizer to communicate with Taler exchanges. As the API can be exposed on the Internet it has to be resistant to easy attacks.

 

 \subsection*{HTTP Authentication}

 

 The wire API only supports the Basic HTTP Authentication method and it has to be optional. Making it optional can lead to security issues by misconfiguration. If the default behavior in case of missing configuration is to deactivate authentication, a typo could lead to an exposed API. We made the authentication method configuration mandatory to make its deactivation explicit.

 

-\subsection*{OOS DOS}

+\subsection*{OOM \acs{dos}}

 

-A common Denial Of Service attack consists of sending many requests with huge bodies to saturate a server memory and, in the worst case, create an Out Of Memory error. To be resilient against such attacks we only read body after request authentication to prevent any person without authorization to access the API to perform such attacks.

+A common Denial Of Service attack consists of sending many requests with huge bodies to saturate a server memory and, in the worst case, create an Out Of Memory error. To be resilient against such attacks we only read body after request authentication, to prevent any person without authorization to access the API to perform such attacks.

 

-Then we chose an aggressive memory budget of 4kB as all request bodies should be very small and we only read and parse them under this budget. In the case of compressed bodies, we also apply this budget to the decompression process to protect ourselves against decompression bombs.

+Then we chose an aggressive memory budget of 4kB, as all request bodies should be very small, and we only read and parse them under this budget. In the case of compressed bodies, we also apply this budget to the decompression process to protect ourselves against decompression bombs.

 

 \subsection*{Testing}

 

@@ -447,4 +456,8 @@ There is an opportunity for a more intelligent analysis of network behaviours to
 \bibliographystyle{alpha}

 \bibliography{literature}

 

+\clearpage

+

+\printacronyms

+

 \end{document}