commit c16c0c6fc247da561b6c74d49b3111f53f3aff12
parent 0e734b4832c652b1760454acc9d6e732abb96d18
Author: Antoine A <>
Date: Fri, 3 Jun 2022 09:48:23 +0200
typos
Diffstat:
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/article-brains22/depolymerizer.tex b/article-brains22/depolymerizer.tex
@@ -68,7 +68,7 @@ limitations while preserving or enhancing privacy.
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
+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
@@ -76,9 +76,9 @@ 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
+Second, the block size and number of blocks mined are two factors limiting the
amount of transactions per second that distributed cryptocurrencies
-can perform. The number of transactions per second is currently small
+can perform. The number of transactions per second is currently small
(3 to 4 for Bitcoin and 20 for Ethereum).~\cite{speed} 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
@@ -90,6 +90,7 @@ 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
+% Mention blockchain alongside DLT ? as we talk about blockchain in conclusion
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
@@ -103,7 +104,7 @@ 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
+transfers an amount in cryptocurrency. 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
@@ -146,9 +147,9 @@ 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
+who check that all transactions are regular and that the exchange has
adequate funds in escrow to meet its obligations from tokens in
-ciruclation.
+circulation.
When a users need tokens, they make a money transfer to the
exchange. Then they generate tokens and have them signed by the
@@ -157,7 +158,7 @@ public key of the tokens it has signed~\cite{cbdc2021chaum}.
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
+present 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
@@ -166,13 +167,13 @@ received tokens.
\section{Depolymerization Architecture}\label{sec:architecture}
-The Depolymerization project consists of a a banking interface that
+The Depolymerization project consists of 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
+blockchain. Figure~\ref{fig:offchain} shows how Depolymerization
allows funds to be transferred to GNU Taler and then transactions to
be made off-chain.
@@ -180,7 +181,7 @@ be made off-chain.
\begin{center}
\input{figures/settlement_layer.tex}
\end{center}
- \caption{Blockchain settlement layer with depolymerization.}\label{fig:offchain}
+ \caption{Blockchain settlement layer with Depolymerization.}\label{fig:offchain}
\end{figure}
The Depolymerization system consists of several components.
@@ -196,10 +197,10 @@ 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
+the existing Bitcoin or Ethereum ``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
+ Depolymerization DLT Adapter is responsible for DLT-specific
adaptations.
\begin{figure}[hb]
@@ -209,7 +210,7 @@ the existing Bitcoin or Etherum ``full'' client
\caption{Depolymerization architecture.}\label{fig:architecture}
\end{figure}
-When a users want to withdraw tokens, they have to credit the
+When 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
@@ -246,7 +247,7 @@ Blockchain-specific problems.
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.
+and later have the original on-chain transfer reversed.
\begin{figure}[ht]
\begin{center}
@@ -260,13 +261,13 @@ 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
+authoritative longest chain. Moreover, we can also have in one of the
+new blocks (for instance 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
+different transfer. This would prevent the original transaction
from ever being committed on the longest chain.
-Since the blindely signed tokens cannot easily be identified (because
+Since the blindly 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
@@ -274,8 +275,8 @@ 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
+If the Depolymerizer detects that a fork has reverted an incoming
+transaction, it suspends operations until the reverted transactions
appear in the fork {\em or} until the operator manually intervenes
to resolve the situation.
@@ -286,16 +287,17 @@ 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
+mitigation for a Depolymerizer 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
+Due to the limited rate for on-chain transactions, it is possible for
+cryptocurrency transactions to 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.
+% I am not sure this can ever happen, from memory bitcoind announce again pending transactions every few days
This is problematic when merchants expect to be credited in a timely
manner. Depolymerizer keeps track of pending transactions and
@@ -324,7 +326,7 @@ 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
+amount that can be practically wired. Thus, in Depolymerizer, all
Ether amounts must be multiples of $10^{10} Wei$.
% \subsection{Meta data} % ???
@@ -361,10 +363,10 @@ be executed before transactions are confirmed. One way to work around
this problem are layer-2 solutions like Lightning, which is an
additional payment layer on top of Bitcoin. Its goal is to settle
transactions faster without involving a full transaction on the
-Blockckain every time that money is moved. Lightning works by
+blockchain every time that money is moved. Lightning works by
establishing {\em payment channels} between two parties, where one or
both parties ``lock'' an initial amount to the channel. Signatures
-communicated outside of the blockchain then change how money is
+communicated outside the blockchain then change how money is
allocated between the two sides of the payment channel. Eventually a
payment channel will be closed by submitting a multi-party signature
of the latest allocation between the two parties to the Blockchain,
@@ -387,10 +389,10 @@ federated structure, we simply use a centralized payment system to
provide virtually instant transactions, which also eliminates the need
for customers to operate a node that needs to be permanently online.
-Aside from scalability, Bitcoin and Etherum also suffer from coins not
+Aside from scalability, Bitcoin and Ethereum also suffer from coins not
being fungible, as they are traceable. As a result, freshly mined
coins may be considered more valuable as they cannot possibly have
-been tainted by criminal transactions in the unspend transaction
+been tainted by criminal transactions in the unspent transaction
output's (UTXO) transaction history, which may result in coins being
rejected by cryptocurrency exchanges or merchants. Mixing services
for DLTs attempt to re-introduce privacy and thus fungibility, but
@@ -419,7 +421,7 @@ the operation would typically be immediately global, which could
create challenges for practical KYC. Furthermore, the non-fungibility
of cryptocurrencies is expected to create problems for anti-money
laundering, it will require defining a threshold for when UTXOs should
-be considered tainted before the Deploymerization system allows the
+be considered tainted before the Depolymerization system allows the
wallet to withdraw tokens.
\section{Conclusion}\label{sec:conclusion}
@@ -428,7 +430,7 @@ Contemporary cryptocurrencies are too slow and expensive for daily
purchases and fail to meet the fungibility of cash. Thanks to
Depolymerization, one can use GNU Taler to pay for services in real
time with privacy, allowing merchants to deliver the goods without
-noticable delay.
+noticeable delay.
\section*{Acknowledgements}
