[taler-depolymerization] branch master updated: first editing pass

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository depolymerization.

The following commit(s) were added to refs/heads/master by this push:
     new 2ce72ba  first editing pass
2ce72ba is described below

commit 2ce72ba10ff57a41c3b65201ffeae3d377d69e17
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Jun 2 14:57:04 2022 +0200

    first editing pass
---
 article-brains22/depolymerizer.tex | 364 +++++++++++++++++++++++++++++--------
 1 file changed, 287 insertions(+), 77 deletions(-)

diff --git a/article-brains22/depolymerizer.tex 
b/article-brains22/depolymerizer.tex
index af45806..bee907c 100644
--- a/article-brains22/depolymerizer.tex
+++ b/article-brains22/depolymerizer.tex
@@ -14,6 +14,7 @@
 % \usepackage{graphics}
 % \usepackage{parskip}
 \usepackage{tikz}
+\usepackage{url}
 % \usepackage{float}
 % \usepackage{authblk}
 % \usepackage{acro}
@@ -24,18 +25,18 @@
 \def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
     T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
 
-\title{Depolymerizer, tokenizing the blockchains}
+\title{Project Depolymerization: Tokenization of Blockchains}
 \author{\IEEEauthorblockN{1\textsuperscript{st} Antoine d'Aligny}
 \IEEEauthorblockA{student  \\
 \textit{EFREI Paris}\\
 Villejuif, France \\
 antoinedaligny@outlook.fr\\}
-\and 
+\and
 \IEEEauthorblockN{2\textsuperscript{nd} Emmanuel Benoist}
 \IEEEauthorblockA{\textit{School of Engineering and  Computer Science} \\
 \textit{Bern University of Applied Sciences}\\
 Biel, Switzerland\\}
-\and 
+\and
 \IEEEauthorblockN{3\textsuperscript{rd} Christian Grothoff}
 \IEEEauthorblockA{\textit{School of Engineering and  Computer Science} \\
 \textit{Bern University of Applied Sciences}\\
@@ -45,33 +46,94 @@ Biel, Switzerland}
 \maketitle
 
 \begin{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. 
-
-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.
-
-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. 
-
-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. 
-
+GNU Taler is an electronic payment system implemented as Free
+Software. The goal of this project is to enable payments with
+blockchain-based cryptocurrencies in GNU Taler.
+
+Blockchain-based cryptocurrencies come with their own special set of
+challenges, such as lack of finality and unpredictable delays and fees
+in transactions.  Our work analyzes the limitations that arise from
+using a blockchain as a settlement layer for GNU Taler and describes
+ways to mitigate their impact.  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.
+
+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.
 \end{abstract}
-\section{Introduction}
-
-Electronic payments are currently very widespread. We also have with 
currencies like Bitcoin \cite{nakamoto2008bitcoin}  and Ethereum \cite{} two 
very used currencies. However, it is not possible to use these two currencies 
in everyday life to buy bread, pay for a beer or a snack in a vending machine. 
A transaction in Bitcoin or Ethereum has to be entered in a block and then one 
has to wait for a certain number of blocks for this transaction to be 
considered valid. To have a serious vali [...]
-
-
-
-Block size and number of blocks are two factors limiting the amount of 
transactions per second. The number of transactions per second is currently 
very small (less than 10 for Bitcoin or 30 for Ethereum). This makes it 
impossible to use these two systems as a means of payment in the daily life of 
users, since millions of users will need to send transactions daily.
-
-We developed a way to integrate the GNU Taler electronic payment system to 
make payments for Distributed Ledger Technology (DLT) based currencies. The GNU 
Taler system is based on cryptographic tokens distributed by an exchange that 
can be used for instant payment. The users pay the merchants using their 
tokens, the merchants can then send the received tokens  back to a wallet on 
the blockchain.
 
-Our solution allows to use the GNU Taler system to make payments in Bitcoin 
and Ethereum. An exchange is created, to which the user transfers an amount in 
crypto-currency. In return, the user receives tokens corresponding to this 
amount and can dispose of them at will in any store that accepts these tokens. 
The transaction is then instantaneous. The merchant can then convert the 
obtained tokens into the original DLT.
-
-
-We present the GNU Taler payment system in section \ref{sec:taler}. Then in 
section \ref{sec:architecture} we present the depolymerizer system which allows 
to transform Bitcoin and Ethereum assets into GNU Taler tokens and vice versa. 
We also present in section \ref{sec:features} the different specificities of 
our system allowing to solve the inherent problems of blockchains.
+\section{Introduction}
 
-\section{GNU Taler}\label{sec:taler}
-The GNU Taler system has been designed as an electronic payment system for 
FIAT currencies (Fig.~\ref{fig:taler}). In a normal configuration, customers 
who want to use GNU Taler use a wallet. To get tokens into their wallet, the 
users make a bank transfer to an exchange. The exchange issues tokens %(based 
on a blind signature) 
-to the users who stores them in their wallet. 
+Today, popular cryptocurrencies like
+Bitcoin~\cite{nakamoto2008bitcoin} and Ethereum~\cite{ethereum} are
+not useful for electronic payments in everyday life (say to buy bread,
+pay for a beer or a snack in a vending machine).  There are three main
+reasons for this. First, the distributed character and the validation
+of blockchains do not allow fast transactions: a transaction in
+Bitcoin or Ethereum has to be entered in a block and then one has to
+wait for a certain number of blocks for this transaction to be
+considered valid. To have a serious validation, it may be necessary to
+wait for one hour~\cite{nakamoto2008bitcoin}.
+
+Second, the block size and number of blocks mined are two limiting the
+amount of transactions per second that distributed cryptocurrencies
+can perform.  The number of transactions per second is currently small
+(less than 10 for Bitcoin and less than 30 for
+Ethereum).~\cite{blockchaininfo} This makes it impossible to use these
+two systems as a means of payment in the daily life of users, since
+the systems simply cannot handle the transaction rates required by
+millions of users.  In practice, the transactions that are successful
+are those with the highest payment fees attached.  Which brings us to
+the third reason: the effective payment fees are too high for small
+purchases, as the fees may even exceed the value of the purchase,
+especially for small purchases like snacks from a vending machine.
+
+We developed a way to use the GNU Taler electronic payment system as a
+second-layer solution for Distributed Ledger Technology (DLT) based
+cryptocurrencies. The GNU Taler system is based on cryptographic
+tokens distributed by an exchange that can be used for instant
+payments. Users pay the merchants using digital tokens that were
+blindly signed by an issuing payment service provider, called an
+exchange.  Merchants receiving GNU Taler payments need to redeem the
+digital tokens at the exchange.  Merchants can either receive fresh
+tokens, or the exchange can aggregate many off-chain micropayments so
+that the merchant would receive one bulk transfer for many
+micropayments on the blockchain.
+
+Our solution allows to use the GNU Taler system to make payments in
+Bitcoin and Ethereum. An exchange is created, to which the user
+transfers an amount in crypto-currency. In return, the user receives
+(blindly signed) tokens corresponding to this amount and can spend
+them at will in any store that accepts these tokens. The transaction
+is then instantaneous: the exchange operator instantly confirms the
+validity of the tokens by checking its signature and ensuring that
+tokens are not double-spent.  The merchant can then immediately run
+the business logic, and freely determine when the payment is to be
+aggregated and converted into an on-chain transaction.
+
+A key issue with any layer-two solution is that the merchants must
+have some confidence that the operator can be trusted. GNU Taler
+includes an auditor component which can be used to provide real-time
+audits of an exchange operator.  By setting up one or more auditors
+that have both access to the exchange's database and see the on-chain
+transactions, this trust issue can be mitigated.
+
+We give some background on the GNU Taler payment system in
+Section~\ref{sec:taler}. Then in Section~\ref{sec:architecture} we
+present the Depolymerization system, which allows to transform Bitcoin
+and Ethereum assets into GNU Taler tokens and vice versa. We also
+present in Section~\ref{sec:features} the different specificities of
+our system allowing to solve the inherent problems of blockchains.
+
+\section{Background: GNU Taler}\label{sec:taler}
+
+The GNU Taler system has been designed as an electronic payment system
+for FIAT currencies (Figure~\ref{fig:taler}).~\cite{dold2019}
+Customers who want to use GNU Taler use a Taler wallet. To get tokens
+into their wallet, customers make a wire transfer to an exchange. In
+response, the exchange issues tokens to the users who store them in
+their wallet.
 
 \begin{figure}[hb]
     \begin{center}
@@ -80,54 +142,111 @@ to the users who stores them in their wallet.
     \caption{GNU Taler overview}\label{fig:taler}
 \end{figure}
 
-The GNU Taler system is based on four entities. The consumer who wants to buy 
goods from a merchant. The exchange that signs the user's tokens and collects 
the merchant's tokens. And the whole system is supervised by an auditor who 
checks that all transactions are regular.
-
-
-When a users need tokens, they make a money transfer to the exchange. Then 
they generate tokens and have them signed by the exchange. The signature is 
blind, so the exchange does not know the ID of the tokens it has signed 
\cite{chaum2021issue}. 
-
-The user transfers the tokens to the seller. The seller then presents them to 
the exchange. The exchange can verify the signature but cannot know by which 
consumer it was created (because of the blind signature). If the tokens are 
valid, the merchant's account is credited with the amount of the received 
tokens.
-
-The GNU-Taler tokens use asymmetric cryptography. The client creating a token 
generates a private key, public key pair. The public key is sent blind to the 
exchange, which signs it blind. During a payment, the customer transfers the 
real public key, the signature of the exchange and signs with his private key 
the transfer. The merchant sends this information to the exchange so that his 
account is credited.
-
-
-\section{Architecture}\label{sec:architecture}
-The depolymerizer project consists of providing an exchange for Bitcoin and 
Ethereum. We have developed a system that allows owners of digital currencies 
to deposit this currency in an exchange, to get tokens in exchange, and then to 
pay with these tokens. The transactions between customers and merchants are 
done in the GNU Taler system and not in the blockchain. 
Figure~\ref{fig:offchain} shows how the depolymerizer allows funds to be 
transferred to GNU Taler and then transactions to be  [...]
+The GNU Taler system is based on four types of entities. The consumers
+who want to buy goods from merchants. An exchange that signs the
+tokens into existence, and receives deposited tokens from
+merchants. Finally, the exchange is supervised by one or more auditors
+who checks that all transactions are regular and that the exchange has
+adequate funds in escrow to meet its obligations from tokens in
+ciruclation.
+
+When a users need tokens, they make a money transfer to the
+exchange. Then they generate tokens and have them signed by the
+exchange. The signature is blind, so the exchange does not know the
+public key of the tokens it has signed~\cite{chaum2021issue}.
+
+The user spends the tokens at a merchant by signing a digital contract
+with the private keys of one or more tokens. The merchant must then
+presents the tokens to the exchange, which verifies the signature and
+checks against double-spending. Here, the exchange cannot determine
+which consumer is spending the token (due to the blind signature). If
+the tokens are valid, the merchant is credited with the amount of the
+received tokens.
+
+
+\section{Depolymerization Architecture}\label{sec:architecture}
+
+The Depolymerization project consists of a a banking interface that
+connects an exchange to Bitcoin or Ethereum as the underlying
+settlement layer.  The system allows owners of digital currencies to
+deposit this currency in an exchange, get tokens in exchange, and then
+to pay with these tokens. The (micro) transactions between customers
+and merchants are then done within the GNU Taler system and not on the
+blockchain. Figure~\ref{fig:offchain} shows how depolymerization
+allows funds to be transferred to GNU Taler and then transactions to
+be made off-chain.
 
 \begin{figure}[hb]
     \begin{center}
         \input{figures/settlement_layer.tex}
     \end{center}
-    \caption{Blockchain settlement layer with 
Depolymerizer}\label{fig:offchain}
+    \caption{Blockchain settlement layer with 
depolymerization.}\label{fig:offchain}
 \end{figure}
 
-The system consists of several components. The Figure \ref{fig:architecture} 
shows the interactions between the Taler exchange, the Wire Gateway, the DLT 
Adapter and the DLT Full Node. Since the last two components are DLT-specific, 
there is an Adapter and a Full Node for Bitcoin and an Adapter and a Full Node 
for Ethereum. 
-
-At the center of this architecture is a database that collects the incoming 
and outgoing transactions in the system (those made on the blockchain). These 
transactions are called credits and debits in our accounts. When a credit is 
found, tokens must be distributed to a customer. When a merchant deposits 
tokens, we must debit our account to transfer the money back to the merchant's 
DLT account.
-
-
-
-
-
+The Depolymerization system consists of several components.
+Figure~\ref{fig:architecture} shows the interactions between the Taler
+exchange, the Depolymerization {\em Wire Gateway}, the
+Depolymerization {\em DLT Adapter}, and the DLT Full Node.  Here, the
+Taler exchange represents the previously existing Taler payment
+system, specifically the \texttt{taler-exchange-wirewatch} and
+\texttt{taler-exchange-transfer} components that are traditionally
+interacting with the banking system. The Depolymerization Wire Gateway
+is simply a REST API that presents the Taler exchange with a view of
+the blockchain that (largely) matches the expected semantics of a
+traditional settlement layer.  At the center of this architecture is a
+relational database (PostgreSQL) which collects the incoming (credit)
+and outgoing (debit) transactions of the system.  The DLT Full Node is
+the existing Bitcoin or Etherum ``full'' client
+({\texttt{bitcoind}\footnote{\url{https://bitcoincore.org/}} or
+  {\texttt{geth}\footnote{\url{https://geth.ethereum.org/}}).  The
+    Depolymerization DLT Adapter is responsible to for DLT-specific
+    adaptations.
 
 \begin{figure}[hb]
     \begin{center}
         \input{figures/depolymerizer_arch.tex}
     \end{center}
-    \caption{Depolymerizer architecture}\label{fig:architecture}
+    \caption{Depolymerization architecture.}\label{fig:architecture}
 \end{figure}
 
-When a user wants to withdraw tokens, he has to credit our account on the DLT. 
As all users' money is transferred to the same address, the user must add 
information allowing to assign this money to this client. The client sends a 
transaction that contains both the money and his public key. This public key 
will be used to validate the new tokens. While meta-information is easy to add 
in Ethereum, for Bitcoin we use a multi-output transaction system. The main 
output is our account, the oth [...]
-
-When the clients want to create the tokens corresponding to the transfer they 
made, they sign the new tokens with the private key corresponding to the public 
key indicated during the transfer.
-
-The Taler exchange retrieves the new token request. It checks that the public 
key used during the money transfer matches the signature used for the request. 
Then it signs the new coins blind and sends them back to the user. The user 
removes the blind factor from his coins and can use them.
-
-The Taler exchange will also be responsible for collecting the coins that the 
merchants receive. The money is then transferred to the address given by the 
merchant in the DLT.
-
-
-\section{Special features} \label{sec:features}
-The biggest risk for our system is to believe an amount transferred, to 
validate the creation of coins and to see later that the original money 
transfer is not valid. Since the tokens can not be revocated (because they were 
signed blind), the exchange will lose money.
-
+When a users want to withdraw tokens, they have to credit the
+exchange's account on the respective DLT. As all users' money is
+transferred to the same address of the exchange, each user must add
+information allowing the exchange to associate the incoming funds with
+the originating user's wallet. To do this, the customer sends a
+transaction that contains both the money and a public key of the
+user's wallet in transaction {\em meta-data}. This public key will be
+used to validate requests for issuing fresh tokens. While meta-data is
+easy to add in Ethereum, for Bitcoin we use a multi-output
+transaction.  Here, the main output is our account while the other
+outputs (whose transaction values are negligible) correspond to an
+ephemeral public key that identifies the user's wallet.
+
+When customers want to withdraw tokens corresponding to the transfer
+they made, they sign the requests for new tokens with the private key
+corresponding to the public key indicated during the transfer.  The
+Taler exchange retrieves the withdrawal request, checks that the
+public key used during the money transfer matches the signature used
+for the request, and finally blindly signs the new tokens and sends
+the signature back to the wallet.
+
+The Taler exchange is also responsible for redeeming tokens that were
+spent at merchants. If and when a merchant decides to be credited
+on-chain, the exchange will instruct the Depolymerization Wire Gateway
+to transfer the funds from its DLT escrow account to the DLT address
+indicated by the merchant.
+
+
+\section{Blockchain-specific Problems and Mitigations} \label{sec:features}
+
+In this section we describe how the Depolymerization system addresses
+Blockchain-specific problems.
+
+\subsection{Forks}
+
+A big risk for an exchange operator is to believe that an incoming
+on-chain transaction was final, allow the wallet to withdraw tokens,
+and to then later have see the original on-chain transfer reversed.
 
 \begin{figure}[ht]
     \begin{center}
@@ -136,26 +255,120 @@ The biggest risk for our system is to believe an amount 
transferred, to validate
     \caption{Blockchain fork}\label{fig:fork}
 \end{figure}
 
-This can happen with DLT systems in the case of a fork. If a transaction is 
included in a block (for instance D1 in Fig. \ref{fig:fork}). We could believe 
that it is valid. But if a fork happens that does not contain D1, our 
transaction may not appear in the new blocks. Moreover we can also have in one 
of the new blocks D2 a transaction using the money at the origin of our 
transaction and thus making our transaction invalid.
-
-To solve this problem, we wait a certain number of blocks before validating a 
transaction. This number depends on the DLT and also depends on the history of 
forks. Waiting is not a problem, because for privacy reasons, we should not 
withdraw the coins at the time of use to avoid correlations between withdrawals 
and expenses that could attack the privacy of the system.
+This can happen with DLT systems in the case of a fork. If a
+transaction is included in a block (for instance D1 in
+Figure~\ref{fig:fork}), the exchange might believe that it is durable
+and final. But if a fork happens that does not contain D1, the
+transaction may not appear in the new blocks of the ultimately
+authoritative longest chain. Moreover we can also have in one of the
+new blocks (for instnace D2 in Figure~\ref{fig:fork}) a conflicting
+transaction that uses the money at the origin of our transaction for a
+different transfer. This would preventing the original transaction
+from ever being committed on the longest chain.
+
+Since the blindely signed tokens cannot easily be identified (because
+they were signed {\em blind}), the exchange could lose money.  The
+canonical solution to the problem is to wait a certain number of
+blocks before validating a transaction. In Depolymerization, the
+number is set depending on the DLT and the history of forks observed
+by the system.  The resulting delay only impacts the initial issuing
+of coins, and not the off-chain transactions.
+
+If the Depolymerizer detects that an fork has reverted an incoming
+transactions, it suspends operations until the reverted transactions
+appear in the fork {\em or} until the operator manually intervenes
+to resolve the situation.
+
+One such possible intervention enabled by GNU Taler is for the
+exchange to revoke the affected denomination keys, and to request all
+wallets to reveal the blinding factors of tokens in circulation that
+correspond to those denominations. This would allow the exchange to
+re-issue the tokens that were from on-chain transfers that were not
+reversed. However, in theory it might be too late, as the token might
+also have already been spent.  Still, this remains a possible
+mitigation for a Deploymerizer operator in case the canonical solution
+was inadequate.
+
+\subsection{Fees are Bids}
+
+Due to the limited rate for on-chain transactions, it is possible that
+cryptocurrency transactions can get stuck for a long time. Especially
+if the transaction fee was set too low, it is even possible that transactions
+never make it out of the pending transaction pool onto the main chain and
+are abandoned by the DLT settlement layer.
+
+This is problematic when merchants expect to be credited in a timely
+manner.  Depolymerizer keeps track of pending transactions and
+identifies those that are taking an excessive amount of time to
+mine. For such stuck transactions, it eventually replaces the
+transaction~\cite{bip125} with one where the fee was increased to bump
+its mining priority. Since the process of replacing transactions is
+expensive, acceptable delays and transaction fees are configurable.
+
+\subsection{Tiny Amounts}
+
+The GNU Taler amount format is based on 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 smallest unit being the Satoshi, one Satoshi being
+worth $10^8$ Bitcoin. However, the smallest unit of Ether 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{\url{https://ethereum.org/en/developers/docs/gas/\#post-london}}.
 The
+average gas price is currently around 30 GWei. Therefore, a standard
+transaction costs about $63 \cdot 10^{18}$ Wei in transaction
+fees. Since the transaction fee is so high, even if we truncate
+amounts to $10^{-8}$ Ether ($10^{10}$ Wei), we can still represent any
+amount that can be prectically wired. Thus, in Depolymerizer, all
+Ether amounts must be multiples of $10^{10} Wei$.
+
+% \subsection{Meta data} % ???
 
 \section{Advantages}
 
-
-The depolymerizer system allows to turn Bitcoin or Ethereum funds temporarily 
into tokens. The tokens are very quickly exchangeable and can be used for daily 
payments. 
-
-While the number of transactions on blockchains is limited by the size of the 
blocks, their frequency and thus the size of the blockchain, the GNU Taler 
payment system has no intrinsic limit. Marco Boss \cite{} has successfully 
configured a GNU Taler exchange to process 50,000 tokens per second. Since each 
transaction uses a limited number of tokens (less than the binary logarithm of 
the amount spent) an exchange can therefore process at least 10,000 
transactions per second.
-This is comparable to the Visa network, which claims to be able to process 
65,000 messages per second (a transaction is also several messages). 
\cite{visafactsheet}.
-
-% 
https://www.visa.co.uk/dam/VCOM/download/corporate/media/visanet-technology/aboutvisafactsheet.pdf
-
-Blockchain-based systems are also dependent on their distributed aspect. Since 
there is no central instance to validate a transaction, the system waits for 
the transaction to be inserted into a block and then for that block to be 
confirmed by adding more blocks. This makes instantaneous transactions 
impossible with the Bitcoin and Ethereum systems. So you can never use these 
two systems directly to pay for coffee or bread, and a Bitcoin or Ethereum 
snake machine cannot work. Thanks to De [...]
+The Depolymerization system allows users to turn Bitcoin or Ethereum
+funds temporarily into tokens. The tokens are quickly exchangeable and
+can be used for daily expenses.
+
+While the number of transactions on blockchains is limited by the size
+of the blocks, their frequency and thus the size of the blockchain,
+the GNU Taler payment system has no intrinsic limit. Marco
+Boss~\cite{boss2022} has successfully configured a GNU Taler exchange
+to process over 23,000 token transactions per second. Since each
+transaction uses a limited number of tokens (on average, half of the
+binary logarithm of the number of currency units spent) an exchange
+can therefore be expected to process at least 2,300 transactions per
+second for typical amounts.  This is comparable to the Visa network,
+which is said to perform about 1'700 transaction per second
+globally.~\cite{tps-payment-systems}
+
+% FIXME: privacy?
+
+
+% FIXME: reword? Move into conclusion?
+Blockchain-based systems are also dependent on their distributed
+aspect. Since there is no central instance to validate a transaction,
+the system waits for the transaction to be inserted into a block and
+then for that block to be confirmed by adding more blocks. This makes
+instantaneous transactions impossible with the Bitcoin and Ethereum
+systems. So you can never use these two systems directly to pay for
+coffee or bread, and a Bitcoin or Ethereum snack machine cannot
+work. Thanks to Depolymerization, one can use GNU Taler to pay for
+services in real time. The customer can pay and the merchant can
+deliver the goods without noticable delay.
 
 
 \section{Conclusion}\label{sec:conclusion}
 
+% FIXME: link to actual deployment?
 
+% \section*{Acknowledgements}
+% Any?
 
 \bibliographystyle{IEEEtran}
 \bibliography{biblio}
@@ -227,7 +440,7 @@ Blockchain-based systems are also dependent on their 
distributed aspect. Since t
                 \bitbox{4}{ID} & \bitbox{16}{Half}
             \end{rightwordgroup}
         \end{bytefield}
-        
+
     \end{center}
     \begin{center}
         \begin{bytefield}[rightcurly=., rightcurlyspace=0pt]{32}
@@ -242,6 +455,3 @@ Blockchain-based systems are also dependent on their 
distributed aspect. Since t
     \end{center}
     \caption{Outgoing metadata format}
 \end{figure}
-
-
-

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.