[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-depolymerization] branch master updated (40dbf1f -> 0d2bd0c)
|
From: |
gnunet |
|
Subject: |
[taler-depolymerization] branch master updated (40dbf1f -> 0d2bd0c) |
|
Date: |
Tue, 19 Apr 2022 12:52:57 +0200 |
This is an automated email from the git hooks/post-receive script.
antoine pushed a change to branch master
in repository depolymerization.
from 40dbf1f add test decoding logic
new dffc5ba report progress
new b5bb643 Support any network in segwit demo
new 0d2bd0c Merge master
The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
btc-wire/src/bin/segwit-demo.rs | 21 ++++--
btc-wire/src/loops/worker.rs | 2 +-
docs/figures/{fork.tex => reorg.tex} | 1 +
docs/literature.bib | 18 ++++-
docs/presentation.tex | 14 ++--
docs/report.tex | 137 ++++++++++++++++++++---------------
eth-wire/src/loops/worker.rs | 2 +-
test/btc/hell.sh | 2 +-
test/btc/reorg.sh | 2 +-
test/eth/hell.sh | 2 +-
test/eth/reorg.sh | 2 +-
11 files changed, 123 insertions(+), 80 deletions(-)
copy docs/figures/{fork.tex => reorg.tex} (88%)
diff --git a/btc-wire/src/bin/segwit-demo.rs b/btc-wire/src/bin/segwit-demo.rs
index 891ef68..0be19a6 100644
--- a/btc-wire/src/bin/segwit-demo.rs
+++ b/btc-wire/src/bin/segwit-demo.rs
@@ -1,4 +1,6 @@
-use bitcoin::Amount;
+use std::str::FromStr;
+
+use bitcoin::{Address, Amount, Network};
use btc_wire::{rpc_utils, segwit::encode_segwit_addr};
use btc_wire::{segwit::decode_segwit_msg};
use common::{
@@ -7,7 +9,7 @@ use common::{
};
pub fn main() {
- let address = "tb1qhxrhccqexg0dv4nltgkuw4fg2ce7muplmjsn0v";
+ let address =
Address::from_str("tb1qhxrhccqexg0dv4nltgkuw4fg2ce7muplmjsn0v").unwrap();
let amount = Amount::from_sat(5000000);
let reserve_pub = "54ZN9AMVN1R0YZ68ZPVHHQA4KZE1V037M05FNMYH4JQ596YAKJEG";
let btc = amount.as_btc();
@@ -50,8 +52,13 @@ pub fn main() {
hex::encode(&second_half)
);
// bech32: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
- let first = encode_segwit_addr("bc", first_half[..].try_into().unwrap());
- let second = encode_segwit_addr("bc", second_half[..].try_into().unwrap());
+ let hrp = match address.network {
+ Network::Bitcoin => "bc",
+ Network::Testnet | Network::Signet => "tb",
+ Network::Regtest => "bcrt",
+ };
+ let first = encode_segwit_addr(hrp, first_half[..].try_into().unwrap());
+ let second = encode_segwit_addr(hrp, second_half[..].try_into().unwrap());
println!(
"Encode each half using bech32 to generate a segwit address:\n{}\n{}",
first, second
@@ -61,11 +68,13 @@ pub fn main() {
let minimum = rpc_utils::segwit_min_amount().as_btc();
println!("Send a single bitcoin transaction with the three addresses as
recipient as follow:");
println!("\nIn bitcoincore wallet use 'Add Recipient' button to add two
additional recipient and copy adresses and amounts");
- for (address, amount) in [(address, btc), (&first, minimum), (&second,
minimum)] {
+ let first = Address::from_str(&first).unwrap();
+ let second = Address::from_str(&second).unwrap();
+ for (address, amount) in [(&address, btc), (&first, minimum), (&second,
minimum)] {
println!("{} {:.8} BTC", address, amount);
}
println!("\nIn Electrum wallet paste the following three lines in 'Pay to'
field :");
- for (address, amount) in [(address, btc), (&first, minimum), (&second,
minimum)] {
+ for (address, amount) in [(&address, btc), (&first, minimum), (&second,
minimum)] {
println!("{},{:.8}", address, amount);
}
println!(
diff --git a/btc-wire/src/loops/worker.rs b/btc-wire/src/loops/worker.rs
index 8e09512..7cf23ba 100644
--- 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/fork.tex b/docs/figures/reorg.tex
similarity index 88%
copy from docs/figures/fork.tex
copy to docs/figures/reorg.tex
index 09a77f6..ea79320 100644
--- a/docs/figures/fork.tex
+++ b/docs/figures/reorg.tex
@@ -1,5 +1,6 @@
\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
diff --git a/docs/literature.bib b/docs/literature.bib
index 9a0b0ad..6f51e32 100644
--- 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
index d1ecbc5..0e824e4 100644
--- 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
index 5242f46..0ad803d 100644
--- 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.
-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.
+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.
+
+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/\#bloc [...]
+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/\#blo [...]
+
+\subsubsection*{Reorganization}
-\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 they found, we
have a blockchain fork where two different blockchain state are followed in the
network (Figure~\ref{fig:reorg}).
-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 [...]
+\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 unpredicta [...]
+ \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 unpredicta [...]
\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: [...]
+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 t [...]
\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. A malicious actor
able to rearrange the blockchain at will could use his Taler coins while
removing the credit that created those coins and thus get his cryptocurrencies
coins back, allowing for double spending. This problem is well known and
already mentioned in the Bitcoin white paper \cite{nakamoto2008bitcoin}. The
deeper a block is in the blockchain [...]
\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}
@@ -232,7 +242,7 @@ We know that transactions can get stuck for a long time,
which can be problemati
\section{Metadata} \label{metadata}
-Metadata is needed to link a wallet to credits and allow merchants to link
deposits to debits. Metadata is stored alongside transactions in the
blockchain, so it is possible to recover the full transaction history of any
depolymerizer from it.
+GNU Taler need additional metadata to link a wallet to credits and allow
merchants to link deposits to debits. Metadata need to be stored alongside
transactions in the blockchain, so it is possible to recover the full
transaction history of any depolymerizer from it.
\subsection{Metadata format}
@@ -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 b [...]
-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,11 +360,11 @@ 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}
-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.
+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 error 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 \ac{DLT} reconciliation, which is slow and does not play well with
database locking.
@@ -368,7 +378,7 @@ Since we know that blockchain-based cryptocurrencies have
low throughput, we do
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 [...]
-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 $10^{-8}$ eth
($10^{10}$ wei), we can still represent any amount you can send whiteout losing
money on the transaction fee.
\subsection*{Replaceable bitcoin transaction}
@@ -376,11 +386,11 @@ 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 \ac{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 \ac{DOS} attack.
+We use the solution has been adopted in \ac{BIP} 125 \cite{BIP125}, adding the
possibility to encode the replaceability of a bitcoin transaction at its
creation. It can thus 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 \ac{DOS} attack.
\clearpage
-\section{URI packing, a compression side quest}
+\section{URI packing, a compression side quest}\label{uri-packing}
\subsection*{The need for compact URI}
@@ -439,7 +449,7 @@ encoding we can encode in the best case 74 characters
instead of 47 which is mor
\section{Taler Wire Gateway HTTP API}
-Taler is a modular project where each module communicates through \ac{HTTP}
\ac{API}. The Wire Gateway \ac{API} allows the exchange to communicate to wire
adaptors. The Wire Gateway module allow Depolymerizer to communicate with Taler
exchanges. As the \ac{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 \ac{HTTP}
\ac{API}. The Wire Gateway \ac{API} allows the exchange to communicate to wire
adaptors. The Wire Gateway module allow Depolymerizer to communicate with Taler
exchanges. As the \ac{API} can be exposed on the Internet it has to be
resistant to most of the known attacks.
\subsection*{HTTP Authentication}
@@ -455,19 +465,26 @@ 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}
+\section{Conclusion}
+
+\subsection*{Summary}
-\subsection*{Paying for reorganisation loss}
+We have shown that is it possible to use Bitcoin and Ethereum \ac{DLT} as a
settlement layer for GNU Taler enabling payment with blockchain-based
cryptocurrencies using Depolymerization. Depolymerization act as a middleware
between Taler exchange and a \ac{DLT} mitigating their inconsistency especially
chain reorganization and stuck transactions.
+
+\subsection*{Future work}
+
+\subsubsection*{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}
+\subsubsection*{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 DLT 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 blockchain 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
index ea1d412..2d9d95e 100644
--- 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
index d58189b..ad1271a 100644
--- 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
index 3985fbe..69c272d 100644
--- 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
index 48b36b7..d3aa97c 100644
--- 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
index b129df5..220b687 100644
--- 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
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-depolymerization] branch master updated (40dbf1f -> 0d2bd0c),
gnunet <=