commit dffc5ba48b5031a229f7aa948c1853180b805639
parent 074bb420b83fdb6f14e15253bc23cd0360416b8c
Author: Antoine A <>
Date: Wed, 6 Apr 2022 22:11:11 +0200
report progress
Diffstat:
10 files changed, 128 insertions(+), 68 deletions(-)
diff --git a/btc-wire/src/loops/worker.rs b/btc-wire/src/loops/worker.rs
@@ -186,7 +186,7 @@ fn sync_chain(
(txs, removed, list.lastblock)
};
- // Check if a confirmed incoming transaction have been removed by a blockchain reorganisation
+ // Check if a confirmed incoming transaction have been removed by a blockchain reorganization
let new_status = sync_chain_removed(&txs, &removed, rpc, db, conf_delay as i32)?;
// Sync status with database
diff --git a/docs/figures/reorg.tex b/docs/figures/reorg.tex
@@ -0,0 +1,34 @@
+\begin{tikzpicture}[
+ block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
+ conf/.style={draw=black!60!green,fill=black!60!green!10},
+ ar/.style={-stealth}
+ ]
+ % Common
+ \node[block](1){};
+ \node[block,right=5mm of 1](2){$D_0$};
+ \node[block,right=5mm of 2](3){};
+ \draw[ar] (1) -- (2);
+ \draw[ar] (2) -- (3);
+
+ % Current
+ \node[block,right=5mm of 3](4){};
+ \node[block,right=5mm of 4](5){};
+ \node[block,right=5mm of 5](6){$D_1$};
+ \draw[ar] (3) -- (4);
+ \draw[ar] (4) -- (5);
+ \draw[ar] (5) -- (6);
+
+ % Fork
+ \node[block,above=7mm of 4](4p){};
+ \node[block,right=5mm of 4p](5p){$D_2$};
+ \node[block,right=5mm of 5p](6p){};
+ \node[block,right=5mm of 6p](7p){};
+ \draw[ar] (3.east) -- (4p.west);
+ \draw[ar] (4p) -- (5p);
+ \draw[ar] (5p) -- (6p);
+ \draw[ar] (6p) -- (7p);
+
+ % Indication
+ \node [right=5mm of 7p]{\emph{fork}};
+ \node [right=17mm of 6]{\emph{active}};
+\end{tikzpicture}
+\ No newline at end of file
diff --git a/docs/literature.bib b/docs/literature.bib
@@ -56,4 +56,20 @@
pages = {3--22},
year = {2019},
publisher = {Springer}
-}
-\ No newline at end of file
+}
+
+@phdthesis{dold2019gnu,
+ title = {The GNU Taler system: practical and provably secure electronic payments},
+ author = {Dold, Florian},
+ year = {2019},
+ school = {Universit{\'e} Rennes 1}
+}
+
+@inproceedings{burdges2016enabling,
+ title = {Enabling secure web payments with GNU Taler},
+ author = {Burdges, Jeffrey and Dold, Florian and Grothoff, Christian and Stanisci, Marcello},
+ booktitle = {International Conference on Security, Privacy, and Applied Cryptography Engineering},
+ pages = {251--270},
+ year = {2016},
+ organization = {Springer}
+}
diff --git a/docs/presentation.tex b/docs/presentation.tex
@@ -168,7 +168,7 @@
\end{block}
\end{frame}
-\begin{frame}{Blockchain challenges}{Chain reorganisation}
+\begin{frame}{Blockchain challenges}{Chain reorganization}
\begin{center}
\begin{tikzpicture}[
block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
@@ -206,7 +206,7 @@
\end{center}
A fork is when concurrent blockchain states coexist. Nodes will follow
the longest chain, replacing recent blocks if necessary during a
- blockchain reorganisation. If a deposit transaction disappears from the
+ blockchain reorganization. If a deposit transaction disappears from the
blockchain, an irrevocable withdraw transactions would no longer be backed
by credit.
\end{frame}
@@ -301,7 +301,7 @@
\end{block}
\end{frame}
-\begin{frame}{Handling blockchain reorganisation}
+\begin{frame}{Handling blockchain reorganization}
\begin{center}
\begin{tikzpicture}[
block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
@@ -350,9 +350,9 @@
\node [right=17mm of 6]{\emph{active}};
\end{tikzpicture}
\end{center}
- \only<1>{As small reorganisations are common, Satoshi already recommended to
+ \only<1>{As small reorganizations are common, Satoshi already recommended to
apply a confirmation delay to handle most disturbances and attacks.}
- \only<2>{If a reorganisation longer than the confirmation delay happens,
+ \only<2>{If a reorganization longer than the confirmation delay happens,
but it did not remove credits, Depolymerizer is safe and automatically
resumes.}
\only<3>{If a fork removed a confirmed debit, an attacker may create a
@@ -415,8 +415,8 @@
\draw[confl,thick,dotted](I) -- (Ip);
\end{tikzpicture}
\end{center}
- If we experience a reorganisation once, its dangerously likely for another
- one of a similar scope to happen again. Depolymerizer learns from reorganisations
+ If we experience a reorganization once, its dangerously likely for another
+ one of a similar scope to happen again. Depolymerizer learns from reorganizations
by increasing its confirmation delay.
\end{frame}
diff --git a/docs/report.tex b/docs/report.tex
@@ -29,20 +29,18 @@
long=Bitcoin Improvement Proposal,
}
\DeclareAcronym{RPC}{
-short=RPC,
-long=Remote Procedure Call
+ short=RPC,
+ long=Remote Procedure Call
}
\DeclareAcronym{API}{
-short=API,
-long=Application programming interface
+ short=API,
+ long=Application programming interface
}
\DeclareAcronym{HTTP}{
-short=HTTP,
-long=Hypertext Transfer Protocol
+ short=HTTP,
+ long=Hypertext Transfer Protocol
}
-
-
\begin{document}
\maketitle
@@ -51,13 +49,17 @@ long=Hypertext Transfer Protocol
\subsection*{Abstract}
-GNU Taler is an electronic payment system implemented as free software. The goal of this project is to enable payment with blockchain-based cryptocurrency in GNU Taler.
+GNU Taler is an electronic payment system implemented as free software. The goal of this project is to enable payment with blockchain-based cryptocurrencies.
-By proving that blockchains can be used as a settlement layer for GNU Taler, we show that it is not only capable of handling bank money, but also widely used cryptocurrencies.
+To achieve this goal, we need to understand how the distributed ledgers of blockchain-based cryptocurrencies work, what their limitations are, and how to mitigate them so that they can serve as a settlement layer. Key challenges include finding a reliable way to write metadata to the blockchain, handling blockchain reorganization, and resolving stuck transactions.
-For cryptocurrencies owners, this integration offers a new solution for instant and low-cost payments that can scale beyond blockchains limitations while preserving or enhancing privacy.
+Blockchain reorganization prevents the finality of blockchain transactions, which is unacceptable for a settlement layer. By using a confirmation delay, we can create a semblance of finality. However, we still have to handle extreme cases where our delay is insufficient by suspending operations and gracefully recovering when possible.
+
+We have created a depolymerizer, which acts as an adapter between GNU Taler and a \ac{DLT}, allowing their use as a settlement layer. By using official DLT clients, and separating Taler specific from \ac{DLT} specific components, we achieved a simple and maintainable design.
+
+By proving that blockchains can be used as a settlement layer for GNU Taler, we show that it is not only capable of handling bank money, but also widely used cryptocurrencies.
-To achieve this goal, we need to understand how blockchain-based cryptocurrencies work, what their limitations are, and how to mitigate them so that they can serve as a settlement layer.
+For cryptocurrencies owners, this integration offers a new solution for instant and low-cost payments that can scale beyond \ac{DLT} limitations while preserving or enhancing privacy.
\subsection*{Acknowledgement}
@@ -93,23 +95,33 @@ The blockchain itself is just a storage system. To make it a \ac{DLT}, it needs
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.
+This falls short as soon as one node control significantly more computation power than others. This node will not be able to create invalid blocks, because the other nodes will reject them, but will be able to revise transaction history and control the mining of future transactions. This is a majority attack also known as the 51\% attacks.
Another problem is that miners are incentivized to invest more and more computing power, which leads to ever-increasing energy consumption and ecological impact. These problems have motivated the search for another mechanism: proof of stake.
\subsubsection*{Proof of stake}
-This mechanism replaces the use of computing power with the stacking of money. Validators (who replace miners) stake large sums of money to be allowed to verified blocks and be randomly selected to create them. In case of malicious behavior, the stacked money is burned by other validators.
+This mechanism replaces the use of computing power with the stacking of money. Validators (who replace miners) stake large sums of money to be allowed to verified blocks and be randomly selected to propose them. In case of malicious behaviour, the stacked money is burned by other validators.
The effectiveness and security of this mechanism have yet to be proven, but Ethereum plans to adopt it in the summer of 2022.
\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. 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.
+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. This limitation combined with a block size limit creates a transaction rate and a blockchain size growth limit that is difficult to change without disrupting the security of the system.
-\subsubsection*{Reorganisation}
+\subsubsection*{Reorganization}
-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 reorganisation of the blockchain. A reorganisation 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 blockchain state are followed in the network (Figure~\ref{fig:reorg}).
+
+\begin{figure}[H]
+ \begin{center}
+ \input{figures/reorg.tex}
+ \end{center}
+ \caption{Blockchain fork}
+ \label{fig:reorg}
+\end{figure}
+
+Over time, one fork will become longer than the other, and nodes will follow the longest chain. They will replace recent blocks as necessary during a reorganization of the blockchain. Those reorganizations can cause a transaction previously considered mined by a node to no longer be mined. Therefore, blockchain transactions lack finality.
\subsection{Mining incentive}
@@ -118,7 +130,7 @@ A minimum amount of mining power is required for the cryptocurrency to work. Wit
Rewards are of two kinds:
\begin{itemize}
\item \textbf{Coin generation} While mining a block, the miner creates money in it that he can use as he pleases. Bitcoins use this type of reward but to reach a constant amount of 21 million bitcoins, this reward decreases over time.
- \item \textbf{Transaction fee} Transactions may contain a tip for the miner to encourage mining. Miners will not mine transactions that cost them money and will mine the most profitable transaction first. Transaction fees are then market-based values, the more transactions that are waiting to be mined, the higher the fee you have to pay to in the next block. When a transaction is sent with a fee too small, it may not be mined in a timely fashion. Since transaction fees are unpredictable, it is possible to create stuck transactions.
+ \item \textbf{Transaction fee} Transactions may contain a tip for the miner to encourage mining. Miners will not mine transactions that cost them money and will mine the most profitable transaction first. Transaction fees are then market-based values, the more transactions that are waiting to be mined, the higher the fee you have to pay be in the next block. When a transaction is sent with a fee too small, it may not be mined in a timely fashion. Since transaction fees are unpredictable, transactions sometimes end being stuck for a long time.
\end{itemize}
\subsection{Blockchain-based cryptocurrencies limitations}
@@ -129,13 +141,13 @@ As we have seen, blockchain-based cryptocurrencies have certain limitations by d
\section{GNU Taler}
-GNU Taler is an electronic payment system implemented as free software. We provide only a superficial overview of GNU Taler necessary to understand how Depolymerization fits into the system. More information can be found in the project documentation and repository.
+GNU Taler is an anonymous, taxable payment system implemented as free software and inspired by David Chaum's Ecash \cite{burdges2016enabling} \cite{dold2019gnu}. Taler does not rely on a \ac{DLT}. Taler payments are made using digital form of traditional money anonymized using blind signatures. We provide only a superficial overview of GNU Taler necessary to understand how Depolymerization fits into the system. More information can be found in the project documentation and repository.
\subsection{Overview}
\begin{figure}[hb]
\begin{center}
- \input{figures/taler_arch.tex}
+ \scalebox{1.2}{\input{figures/taler_arch.tex}}
\end{center}
\caption{GNU Taler overview}
\end{figure}
@@ -154,74 +166,72 @@ Merchants accept coins in exchange for goods and services. They can then deposit
Auditors monitor the behaviour of the exchanges to ensure that exchanges operate correctly. They are typically operated by financial regulators.
\paragraph*{Settlement layer}
-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.
+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 DLT as a settlement layer to support blockchain-based cryptocurrencies.
-\subsection{Blockchain settlement layer}
+\subsection{DLT settlement layer}
-\begin{figure}[hb]
+\begin{figure}[h]
\begin{center}
\input{figures/settlement_layer.tex}
\end{center}
- \caption{Blockchain settlement layer with Depolymerizer}
+ \caption{DLT settlement layer with Depolymerizer}
+ \label{fig:DltSettlement}
\end{figure}
-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.
+Depolymerizer serves as a middleware between GNU Taler and cryptocurrencies \ac{DLT} (Figure \ref{fig:DltSettlement}). Customers can send money to the Depolymerizer via a credit transaction, to obtain coins that they can use in GNU Taler transactions. Using the Depolymerizer, Taler exchanges can materialize the coins back into the DLT via a debit transaction.
-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).
+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 DLT 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).
\clearpage
\section{Resolving blockchain challenges}
-Some properties of blockchain-based cryptocurrencies are problematic for their use as a Taler settlement layer. The two main issues are blockchain reorganisations and stuck transactions.
+Some properties of blockchain-based cryptocurrencies are problematic for their use as a Taler settlement layer. The two main issues are blockchain reorganizations and stuck transactions.
-\subsection{Solving chain reorganisation}
+\subsection{Solving chain reorganization}
-Taler expects credits to be final. If a credit disappears from the blockchain, an irrevocable debit would no longer be backed by credit. This problem is well known and already mentioned in the Bitcoin white paper \cite{nakamoto2008bitcoin}. The solution is to wait until a block has a certain amount of blocks linked to it, before considering its transactions final.
-
-\begin{figure}[H]
- \begin{center}
- \input{figures/fork.tex}
- \end{center}
- \caption{Blockchain fork}
-\end{figure}
-
-The choice of this confirmation delay is a compromise between speed and security. The longer you wait, the more resistant you are to attack. But since small reorganisations are common by design, a minimal delay is necessary for proper operation. To be resistant to an adversary with $30\%$ of the total mining power, we need to wait for 6 blocks in Bitcoin ($\approx$ 1h) and 37 blocks in Ethereum ($\approx$ 8min) \cite{gervais2016security}. These are the default values but are configurable.
+Taler expects credits to be final. If a credit disappears from the blockchain, an irrevocable debit would no longer be backed by credit. This problem is well known and already mentioned in the Bitcoin white paper \cite{nakamoto2008bitcoin}. The deeper a block is in the blockchain, the harder it is to replace. The depth of a block determines its probability of persistence. The solution is therefore to wait until a block has a certain number of blocks linked to it before considering its transactions as final (Figure \ref{fig:conf_delay}).
\begin{figure}[H]
\begin{center}
\input{figures/conf_delay.tex}
\end{center}
- \caption{Reorganisation mitigation using confirmation delay}
+ \caption{Reorganization mitigation using confirmation delay}
+ \label{fig:conf_delay}
\end{figure}
-Using a confirmation delay does not solve the problem, it only mitigates it. We still have to deal with a potential reorganisation that is longer than our delay. When this happens, we look for any missing confirmed credits, if there are none, we can ignore that reorganisation.
+The choice of this confirmation delay is a compromise between speed and security. As small reorganizations are common by design, a minimal delay is necessary for proper operation. To be resistant to an adversary with $30\%$ of the total mining power, we need to wait for 6 blocks in Bitcoin ($\approx$ 1h) and 37 blocks in Ethereum ($\approx$ 8min) \cite{gervais2016security}.
+
+Using a confirmation delay does not solve the problem, it only mitigates it. We still have to deal with a potential reorganization that is longer than our delay. When this happens, we look for any missing confirmed credits, if there are none, we can ignore that reorganization (Figure \ref{fig:harmless_reorg}).
\begin{figure}[H]
\begin{center}
\input{figures/harmless_reorg.tex}
\end{center}
- \caption{Harmless reorganisation}
+ \caption{Harmless reorganization}
+ \label{fig:harmless_reorg}
\end{figure}
-If confirmed credits have been removed, we will suspend operations. If we are not targeted by an attack and the blockchain network is behaving well, the credits will be mined again and we can wait for them to be confirmed again to resume operations. If the missing credits have been maliciously replaced, we will never be able to resume operation.
+If confirmed credits have been removed, we will suspend operations. If we are not targeted by an attack and the DLT network is behaving well, the credits will be mined again, and we can wait for them to be confirmed again to resume operations. In the case where the missing credits have been maliciously replaced (Figure \ref{fig:conflict}) we never resume operation.
\begin{figure}[H]
\begin{center}
\input{figures/conflict.tex}
\end{center}
- \caption{Reorganisation with conflicting transaction}
+ \caption{Reorganization with conflicting transaction}
+ \label{fig:conflict}
\end{figure}
\subsection{Adaptive confirmation}
-If we experience a reorganisation once, it is dangerously likely that another one of the same magnitudes will occur again. Depolymerizer learns from reorganisations by increasing its confirmation time. Since we understand that a longer delay can also be counterproductive, we limit the delay adjustment to twice the configured one.
+If we experience a reorganization once, it is dangerously likely that another one of the same magnitudes will occur again. Depolymerizer learns from reorganizations by increasing its confirmation time (Figure \ref{fig:analysis}). Since we understand that a longer delay can also be counterproductive, we also want to limit the delay adjustment.
\begin{figure}[H]
\begin{center}
\input{figures/analysis.tex}
\end{center}
\caption{Adaptive confirmation}
+ \label{fig:analysis}
\end{figure}
\subsection{Solving stuck transaction}
@@ -254,7 +264,7 @@ Incoming transaction metadata contains a reserve public key, which is a 32B hash
\subsubsection*{Outgoing transaction}
-Outgoing transactions can be of two types credit or bounce. Credit metadata contains the wire transfer ID which is a 32B hash and the exchange base URL which is of variable size. Bounce metadata contains the bounced transaction ID which is implementation-dependent but is 32B for Bitcoin and Ethereum. A prepended versioning byte differentiates the two types, 0 being a credit and 254 a bounce.
+Outgoing transactions can be of two types credit or bounce. Credit metadata contains the wire transfer ID which is a 32B hash and the exchange base URL which is of variable size and encoded using uri-packing (Section \ref{uri-packing}). Bounce metadata contains the bounced transaction ID which is implementation-dependent but is 32B for Bitcoin and Ethereum. A prepended versioning byte differentiates the two types, 0 being a credit and 254 a bounce.
\begin{figure}[h]
@@ -276,7 +286,7 @@ Outgoing transactions can be of two types credit or bounce. Credit metadata cont
There are many documented ways to encode metadata in a bitcoin transaction \cite{bartoletti2019journey}. In the early days of this cryptocurrency, users abused the transaction format to store metadata, and some of these techniques result in ecosystem pollution. For example, bitcoin clients keep a list of all addresses that currently have money to spend (UTXO), with fake addresses wasting space there indefinitely. To allow storage of a reasonable amount of metadata without polluting the blockchain, a new opcode script OP\_RETURN was created, allowing up to 80B of storage per transaction.
-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.
+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. 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.
@@ -311,7 +321,7 @@ Having a common random ID allows us to distinguish real addresses from fake ones
Ethereum is designed around the concept of smart contracts. Logging inside a smart contract is the recommended way to add metadata, but it is expensive (additional storage and execution costs) and adds an avoidable attack surface. We chose to use the transaction field typically used to call smart contracts to store our raw metadata.
-\subsection{Friendly behavior on format error}
+\subsection{Friendly behaviour 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 \ac{DOS} attack too costly and charges the recipient the transaction fee to ensure it can not lose money on a bounce.
@@ -340,7 +350,7 @@ The watcher loop looks for new incoming blocks and notifies the other loops of t
\paragraph*{Analysis}
-The analysis loop waits for new blocks and then analyzes the behavior of the blockchain network. If a dangerous reorganisation occurs, it is responsible for updating the confirmation delay.
+The analysis loop waits for new blocks and then analyzes the behavior of the DLT network. If a dangerous reorganization occurs, it is responsible for updating the confirmation delay.
\paragraph*{Worker}
@@ -350,7 +360,7 @@ The worker loop waits for new blocks or transaction requests (from the Wire Gate
\subsubsection*{DLT reconciliation}
-During a \ac{DLT} reconciliation, we first list all new transactions and any transactions that have been removed in a reorganisation 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.
+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}
@@ -380,7 +390,7 @@ A solution has been adopted in \ac{BIP} 125 \cite{BIP125}. It is now possible to
\clearpage
-\section{URI packing, a compression side quest}
+\section{URI packing, a compression side quest}\label{uri-packing}
\subsection*{The need for compact URI}
@@ -455,19 +465,19 @@ Then we chose an aggressive memory budget of 4kB, as all request bodies should b
% Move testing to its own section
-The taler exchange has a taler-exchange-wire-gateway-client CLI that allowed me to test that my implementation not only conforms to the \ac{API} documentation but also with how the official client handles it. I found confusion in the documentation where it was specified that timestamp should consist of time in milliseconds in epoch but the client will reject timestamps that are not rounded to second.
+The Taler exchange has a taler-exchange-wire-gateway-client CLI that allowed me to test that my implementation not only conforms to the \ac{API} documentation but also with how the official client handles it. I found confusion in the documentation where it was specified that timestamp should consist of time in milliseconds in epoch, but the client will reject timestamps that are not rounded to second.
\clearpage
\section{Future work}
-\subsection*{Paying for reorganisation loss}
+\subsection*{Paying for reorganization loss}
We could allow the administrator to pay for the missing transactions to resume operations, as sometimes the loss caused by the non-functioning depolymerizer exceeds the cost of the missing transactions.
\subsection*{Smarter analysis}
-There is an opportunity for a more intelligent analysis of network behaviours to adjust the confirmation delay to an estimated risk factor. For example, a brute force attack on a blockchain is very expensive, when we receive an important credit, we could apply a longer delay to it to make attacks harder to sustain.
+There is an opportunity for a more intelligent analysis of network behaviours to adjust the confirmation delay to an estimated risk factor. For example, a brute force attack on a DLT is very expensive, when we receive an important credit, we could apply a longer delay to it to make attacks harder to sustain.
\clearpage
diff --git a/eth-wire/src/loops/worker.rs b/eth-wire/src/loops/worker.rs
@@ -137,7 +137,7 @@ fn sync_chain(
let list = rpc.list_since_sync(&state.address, sync_state, conf_delay)?;
- // Check if a confirmed incoming transaction have been removed by a blockchain reorganisation
+ // Check if a confirmed incoming transaction have been removed by a blockchain reorganization
let new_status = sync_chain_removed(&list.txs, &list.removed, db, &state.address, conf_delay)?;
// Sync status with database
diff --git a/test/btc/hell.sh b/test/btc/hell.sh
@@ -1,6 +1,6 @@
#!/bin/bash
-## Test btc-wire correctness when a blockchain reorganisation occurs leading to past incoming transaction conflict
+## Test btc-wire correctness when a blockchain reorganization occurs leading to past incoming transaction conflict
set -eu
diff --git a/test/btc/reorg.sh b/test/btc/reorg.sh
@@ -1,6 +1,6 @@
#!/bin/bash
-## Test btc-wire correctness when a blockchain reorganisation occurs
+## Test btc-wire correctness when a blockchain reorganization occurs
set -eu
diff --git a/test/eth/hell.sh b/test/eth/hell.sh
@@ -1,6 +1,6 @@
#!/bin/bash
-## Test eth-wire correctness when a blockchain reorganisation occurs leading to past incoming transaction conflict
+## Test eth-wire correctness when a blockchain reorganization occurs leading to past incoming transaction conflict
set -eu
diff --git a/test/eth/reorg.sh b/test/eth/reorg.sh
@@ -1,6 +1,6 @@
#!/bin/bash
-## Test eth-wire correctness when a blockchain reorganisation occurs
+## Test eth-wire correctness when a blockchain reorganization occurs
set -eu
