[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-depolymerization] branch master updated (9d00fd8 -> d6195b5)
|
From: |
gnunet |
|
Subject: |
[taler-depolymerization] branch master updated (9d00fd8 -> d6195b5) |
|
Date: |
Tue, 22 Mar 2022 17:40:22 +0100 |
This is an automated email from the git hooks/post-receive script.
antoine pushed a change to branch master
in repository depolymerization.
from 9d00fd8 remove all occurrence of withdraw and deposit
new 29a34e9 report progress
new 6384473 abstract draft
new 38cd588 report progress
new d6195b5 Check unsupported URI scheme in metadata
The 4 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:
.gitignore | 1 +
btc-wire/README.md | 6 +-
btc-wire/src/loops/worker.rs | 25 ++++---
common/src/metadata.rs | 44 ++++++++---
docs/figures/settlement_layer.tex | 48 ++++++++++++
docs/figures/taler_arch.tex | 35 +++++++++
docs/literature.bib | 59 +++++++++++++++
docs/report.tex | 150 +++++++++++++++++++++++++++-----------
eth-wire/src/lib.rs | 4 +-
9 files changed, 306 insertions(+), 66 deletions(-)
create mode 100644 docs/figures/settlement_layer.tex
create mode 100644 docs/figures/taler_arch.tex
create mode 100644 docs/literature.bib
diff --git a/.gitignore b/.gitignore
index b8616bc..e36de34 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,6 +5,7 @@ log
!/docs/*.docx
!/docs/*.tex
!/docs/*.conf
+!/docs/*.bib
!/docs/media
!/docs/figures
/tmp
diff --git a/btc-wire/README.md b/btc-wire/README.md
index 9e281f7..3a1ef1d 100644
--- a/btc-wire/README.md
+++ b/btc-wire/README.md
@@ -9,11 +9,11 @@ Starting from a bitcoin payto URI you will have to generate
fake segwit
addresses to encode the reserve public key as metadata into a common bitcoin
transaction.
-A single segwit address can contain 20B of chosen data and the reserve pub key
-is 32B. We use two fake addresses consisting of the two key halves prepended
+A single segwit address 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 one. You must then send a single transaction
-with the three addresses as recipients.
+with three addresses as recipients.
Segwit addresses are encoded using a bitcoin specific format:
[bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)
diff --git a/btc-wire/src/loops/worker.rs b/btc-wire/src/loops/worker.rs
index 7ab6390..8e09512 100644
--- a/btc-wire/src/loops/worker.rs
+++ b/btc-wire/src/loops/worker.rs
@@ -29,7 +29,10 @@ use btc_wire::{
};
use common::{
api_common::base32,
- log::log::{error, info, warn},
+ log::{
+ log::{error, info, warn},
+ OrFail,
+ },
metadata::OutMetadata,
postgres,
reconnect::AutoReconnectDb,
@@ -392,12 +395,7 @@ fn sync_chain_debit(
DebitStatus::Requested => {
let nb_row = db.execute(
"UPDATE tx_out SET status=$1, txid=$2 WHERE id=$3 AND
status=$4",
- &[
- &(DebitStatus::Sent as i16),
- &id.as_ref(),
- &row_id,
- &status,
- ],
+ &[&(DebitStatus::Sent as i16), &id.as_ref(), &row_id,
&status],
)?;
if nb_row > 0 {
warn!(
@@ -565,7 +563,12 @@ fn debit(db: &mut Client, rpc: &mut Rpc, state:
&WireState) -> LoopResult<bool>
let url = sql_url(row, 4);
let metadata = OutMetadata::Debit { wtid, url };
- let tx_id = rpc.send(&addr, &amount, Some(&metadata.encode()), false)?;
+ let tx_id = rpc.send(
+ &addr,
+ &amount,
+ Some(&metadata.encode().or_fail(|e| format!("{}", e))),
+ false,
+ )?;
fail_point("(injected) fail debit", 0.3)?;
db.execute(
"UPDATE tx_out SET status=$1, txid=$2 WHERE id=$3",
@@ -591,7 +594,11 @@ fn bounce(db: &mut Client, rpc: &mut Rpc, fee: &BtcAmount)
-> LoopResult<bool> {
bounced: *bounced.as_inner(),
};
- match rpc.bounce(&bounced, fee, Some(&metadata.encode())) {
+ match rpc.bounce(
+ &bounced,
+ fee,
+ Some(&metadata.encode().or_fail(|e| format!("{}", e))),
+ ) {
Ok(it) => {
fail_point("(injected) fail bounce", 0.3)?;
db.execute(
diff --git a/common/src/metadata.rs b/common/src/metadata.rs
index d38594a..a273226 100644
--- a/common/src/metadata.rs
+++ b/common/src/metadata.rs
@@ -28,6 +28,12 @@ pub enum DecodeErr {
UnexpectedEOF,
}
+#[derive(Debug, Clone, thiserror::Error)]
+pub enum EncodeErr {
+ #[error("Unsupported URI scheme {0}")]
+ UnsupportedScheme(String),
+}
+
/// Encoded metadata for outgoing transaction
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum OutMetadata {
@@ -39,11 +45,16 @@ pub enum OutMetadata {
const BOUNCE_BYTE: u8 = u8::MAX - 1;
impl OutMetadata {
- pub fn encode(&self) -> Vec<u8> {
+ pub fn encode(&self) -> Result<Vec<u8>, EncodeErr> {
let mut buffer = Vec::new();
match self {
OutMetadata::Debit { wtid, url } => {
- buffer.push(if url.scheme() == "http" { 1 } else { 0 });
+ let scheme_id = match url.scheme() {
+ "https" => 0,
+ "http" => 1,
+ scheme => return
Err(EncodeErr::UnsupportedScheme(scheme.to_string())),
+ };
+ buffer.push(scheme_id);
buffer.extend_from_slice(wtid);
let parts = format!("{}{}", url.domain().unwrap_or(""),
url.path());
let packed = uri_pack::pack_uri(&parts).unwrap();
@@ -54,7 +65,7 @@ impl OutMetadata {
buffer.extend_from_slice(bounced.as_slice());
}
}
- return buffer;
+ return Ok(buffer);
}
pub fn decode(bytes: &[u8]) -> Result<Self, DecodeErr> {
@@ -66,11 +77,12 @@ impl OutMetadata {
if bytes.len() < 33 {
return Err(DecodeErr::UnexpectedEOF);
}
- let packed = format!(
- "http{}://{}",
- if bytes[0] == 0 { "s" } else { "" },
- uri_pack::unpack_uri(&bytes[33..])?,
- );
+ let scheme = match bytes[0] {
+ 0 => "https",
+ 1 => "http",
+ _ => unreachable!(),
+ };
+ let packed = format!("{}://{}", scheme,
uri_pack::unpack_uri(&bytes[33..])?,);
let url = Url::parse(&packed).unwrap();
Ok(OutMetadata::Debit {
wtid: bytes[1..33].try_into().unwrap(),
@@ -160,18 +172,30 @@ mod test {
let wtid = rand_slice();
let url = Url::parse(url).unwrap();
let metadata = OutMetadata::Debit { wtid, url };
- let encoded = metadata.encode();
+ let encoded = metadata.encode().unwrap();
let decoded = OutMetadata::decode(&encoded).unwrap();
assert_eq!(decoded, metadata);
}
}
+ #[test]
+ fn encode_unknown_scheme() {
+ let url = "https+wtf://git.taler.net";
+ let url = Url::parse(url).unwrap();
+ let metadata = OutMetadata::Debit {
+ wtid: rand_slice(),
+ url,
+ };
+ let encoded = metadata.encode();
+ assert!(encoded.is_err())
+ }
+
#[test]
fn decode_encode_bounce() {
for _ in 0..4 {
let id: [u8; 32] = rand_slice();
let info = OutMetadata::Bounce { bounced: id };
- let encoded = info.encode();
+ let encoded = info.encode().unwrap();
let decoded = OutMetadata::decode(&encoded).unwrap();
assert_eq!(decoded, info);
}
diff --git a/docs/figures/settlement_layer.tex
b/docs/figures/settlement_layer.tex
new file mode 100644
index 0000000..72d945e
--- /dev/null
+++ b/docs/figures/settlement_layer.tex
@@ -0,0 +1,48 @@
+\begin{tikzpicture}[
+ rect/.style={rectangle, draw=black, minimum width=30mm},
+ sym/.style={stealth-stealth, shorten >= 2pt, shorten <= 2pt},
+ block/.style={rectangle,draw=black,fill=black!10,minimum size=7mm},
+ ]
+
+ %% Architecture
+ \node(Tt){Taler};
+ \node[rect,below=0cm of Tt](Tc){Exchange};
+ \node[rect,fit={(Tt) (Tc)}](T){};
+
+ \node[rect,below=7mm of Tc](D) {\textbf{Depolymerization}};
+
+ \node[rect,below=7mm of D](Bc){Node};
+ \node[below=0cm of Bc](Bt){Blockchain};
+ \node[rect,fit={(Bt) (Bc)}](B){};
+
+ \draw[sym] (T) -- (D);
+ \draw[sym] (D) -- (B);
+
+ %% Blockchain
+ \node[block,right=8mm of B] (1){};
+ \node[block,right=4mm of 1] (2){};
+ \node[block,right=4mm of 2] (3){};
+ \node[block,right=4mm of 3] (4){};
+ \node[block,right=4mm of 4] (5){};
+ \node[block,right=4mm of 5] (6){};
+ \draw[-stealth] (1) -- (2);
+ \draw[-stealth] (2) -- (3);
+ \draw[-stealth] (3) -- (4);
+ \draw[-stealth] (4) -- (5);
+ \draw[-stealth] (5) -- (6);
+
+ \node[left=4mm of 1] (S){};
+ \node[right=4mm of 6] (E){};
+ \draw[-stealth] (S) -- (1);
+ \draw[-stealth] (6) -- (E);
+
+ %% Taler
+ \node[block, below right=-7.5mm and 20.5mm of T] (off){Off-chain
transactions};
+ \node[above=-0.5mm of off] {\includegraphics[height=7mm]{media/taler.png}};
+
+ %% Depolymerization
+ \node[right=11mm of D] {\small{Credit}};
+ \node[right=50mm of D] {\small{Debit}};
+ \draw[dashed,-stealth] (1.north) |- (off.west);
+ \draw[dashed,-stealth] (off.east) -| (6.north);
+\end{tikzpicture}
\ No newline at end of file
diff --git a/docs/figures/taler_arch.tex b/docs/figures/taler_arch.tex
new file mode 100644
index 0000000..5d220ce
--- /dev/null
+++ b/docs/figures/taler_arch.tex
@@ -0,0 +1,35 @@
+\begin{tikzpicture}[
+ rect/.style={circle, draw=black},
+ sym/.style={-stealth, shorten >= 2pt, shorten <= 2pt}
+ ]
+ % Taler payment system
+ \node[rect](1) {Exchange};
+ \node[rect,below left=2cm and 1cm of 1](2) {Customer};
+ \node[rect,below right=2cm and 1cm of 1](3) {Merchant};
+
+ \draw[sym] (1) -- node [midway, above, sloped] {\tiny Withdraw coins} (2);
+ \draw[sym] (2) -- node [midway, above, sloped] {\tiny Spend coins} (3);
+ \draw[sym] (3) -- node [midway, above, sloped] {\tiny Deposit coins} (1);
+
+ % Settlement layer
+ \node[left=2.5cm of 1](E1){};
+ \node[right=2.5cm of 1](E2){};
+ \draw[sym] (E1) -- node [midway, above] {\tiny Deposit money} (1);
+ \draw[sym] (1) -- node [midway, above] {\tiny Withdraw money} (E2);
+
+ % Auditor
+ \node[above= of 1](A){Auditor};
+ \draw[sym] (A) -- node [midway, right] {\tiny Verify} (1);
+
+ % Separator
+ \node[below=1mm of E1] (S1S) {};
+ \node[below=1mm of E2] (S1E) {};
+ \node[above=6mm of E1] (S2S) {};
+ \node[above=6mm of E2] (S2E) {};
+
+ \draw[dotted] (S1S) -- (S1E);
+ \draw[dotted] (S2S) -- (S2E);
+
+ \node[below right=-2mm and -1.5mm of S2S] {\tiny{\emph{Settlement Layer}}};
+ \node[below right=-2mm and -1.5mm of S1S] {\tiny{\emph{Taler payment
system}}};
+\end{tikzpicture}
\ No newline at end of file
diff --git a/docs/literature.bib b/docs/literature.bib
new file mode 100644
index 0000000..9a0b0ad
--- /dev/null
+++ b/docs/literature.bib
@@ -0,0 +1,59 @@
+@article{nakamoto2008bitcoin,
+ title = {Bitcoin whitepaper},
+ author = {Nakamoto, Satoshi},
+ journal = {URL: https://bitcoin. org/bitcoin. pdf-(: 17.07. 2019)},
+ year = {2008}
+}
+
+@inproceedings{gervais2016security,
+ title = {On the security and performance of proof of work blockchains},
+ author = {Gervais, Arthur and Karame, Ghassan O and W{\"u}st, Karl and
Glykantzis, Vasileios and Ritzdorf, Hubert and Capkun, Srdjan},
+ booktitle = {Proceedings of the 2016 ACM SIGSAC conference on computer and
communications security},
+ pages = {3--16},
+ year = {2016}
+}
+
+@techreport{RFC8905,
+ author = {F. Dold and C. Grothoff},
+ title = {The 'payto' URI Scheme for Payments},
+ howpublished = {Internet Requests for Comments},
+ type = {RFC},
+ number = {8905},
+ year = {2020},
+ month = {October},
+ issn = {2070-1721},
+ publisher = {RFC Editor},
+ institution = {RFC Editor}
+}
+
+@techreport{BIP125,
+ author = {David A. Harding and Peter Todd},
+ title = {Opt-in Full Replace-by-Fee Signaling},
+ type = {BIP},
+ number = {125},
+ year = {2015},
+ month = {December},
+ institution = {Bitcoin Improvement Proposals}
+}
+
+@techreport{BIP173,
+ author = {Pieter Wuille and Greg Maxwell},
+ title = {Base32 address format for native v0-16 witness outputs},
+ type = {BIP},
+ number = {173},
+ year = {2017},
+ month = {Mars},
+ institution = {Bitcoin Improvement Proposals}
+}
+
+
+@article{bartoletti2019journey,
+ title = {A journey into bitcoin metadata},
+ author = {Bartoletti, Massimo and Bellomy, Bryn and Pompianu, Livio},
+ journal = {Journal of Grid Computing},
+ volume = {17},
+ number = {1},
+ pages = {3--22},
+ year = {2019},
+ publisher = {Springer}
+}
\ No newline at end of file
diff --git a/docs/report.tex b/docs/report.tex
index 19158cd..3e54446 100644
--- a/docs/report.tex
+++ b/docs/report.tex
@@ -7,6 +7,7 @@
\usepackage{tikz}
\usepackage{float}
\usepackage{authblk}
+\usepackage{acro}
\usetikzlibrary{positioning,fit}
@@ -15,30 +16,48 @@
\affil{Bern University of Applied Sciences}
\date{\today}
+\DeclareAcronym{dlt}{
+ short=DLT,
+ long=Distributed Ledger,
+}
+\DeclareAcronym{dos}{
+ short=DOS,
+ long=Denial of service,
+}
+
\begin{document}
\maketitle
\clearpage
-\tableofcontents
+\subsection*{Abstract}
-\clearpage
+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.
-\section{Taler}
+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.
-% TODO
+\subsection*{Acknowledgement}
-% Briefly presenting Taler
-% Settlement layer -> blockchain-based cryptocurrency
+I would like to kindly thank Christian Grothoff and Emmanuel Benoist (Bern
University of Applied Sciences) for their extensive guidance and support during
this project.
+
+\clearpage
+
+\tableofcontents
+
+\clearpage
\section{Blockchain-based cryptocurrencies}
-A cryptocurrency is a digital currency that relies on code and especially
cryptography to secure transactions without a central authority. It is
important to understand the basis of how they work and their limitations to
understand the integration challenges they pose. For this project, only the two
most famous, Bitcoin and Ethereum, were integrated. While other
blockchain-based cryptocurrencies may work differently, we are only interested
in the specific similarities between these two.
+A cryptocurrency is a digital currency that relies on code and especially
cryptography to secure transactions without a central authority. It is
important to understand the basis of how they work and their limitations to
understand the integration challenges they pose. For this project, only the two
most used one, Bitcoin and Ethereum, were integrated. While other
blockchain-based cryptocurrencies may work differently, we are only interested
in the specific similarities between these two.
\subsubsection*{Bitcoin}
-Bitcoin is the first cryptocurrency to achieve a successful public rollout.
Invented by an unknown person or group of people working under the name of
Satoshi Nakamoto, it was first mentioned in his white paper published the 31
October 2009 \cite{nakamoto2008bitcoin}. Bitcoin assembled the technological
foundation for many of the cryptocurrencies in use today.
+Bitcoin is the first cryptocurrency to achieve a successful public rollout.
Invented by an unknown person or group of people working under the name of
Satoshi Nakamoto, it was first mentioned in his white paper published the 28
October 2008 \cite{nakamoto2008bitcoin}. Bitcoin assembled the technological
foundation for many of the cryptocurrencies in use today.
\subsubsection*{Ethereum}
@@ -46,17 +65,17 @@ Bitcoin is focused on currency transfer transactions and
some people wanted to d
\subsection{Blockchain}
-At the heart of these currencies is a blockchain. A blockchain is an
append-only database composed of a list of linked records called blocks. The
content of each block, except the genesis block (the first block), depends on
the content of its parent block. This chained dependency enforces the
immutability of the database, preventing retroactive modification whiteout
altering all subsequent blocks. Transactions are stored inside those blocks.
+At the heart of these currencies is a blockchain. A blockchain is an
append-only database composed of a list of linked records called blocks. The
content of each block, except the genesis block (the first block), depends on
the content of its parent block. This chained dependency enforces the
immutability of the database, preventing retroactive modification whiteout
altering all subsequent blocks. Cryptocurrency transactions takes effect when
they are stored inside those blocks.
\subsection{Consensus}
-The blockchain itself is just a storage system. To make it a distributed
ledger (DLT), it needs a peer-to-peer network to share its changes. But also a
way for participants (nodes) to agree on a single state of the chain, to reach
consensus in a network where nodes can be malicious and have an economic
interest in deceiving others. There are many ways to create such consensus, but
only two of them interest us: proof of work and proof of stake.
+The blockchain itself is just a storage system. To make it a \acf{dlt}, it
needs a peer-to-peer network to share its changes. But also a way for
participants (nodes) to agree on a single state of the chain, to reach
consensus in a network where nodes can be malicious and have an economic
interest in deceiving others. There are many ways to create such consensus, but
only two of them interest us: proof of work and proof of stake.
% DLT definition ?
\subsubsection*{Proof of work}
-This mechanism consists in making the process of appending a block to the
blockchain heavy in computation (mining) by requiring brute force hashing for
example. Nodes, willing to invest their computation power (miners), work to
extend the chain they consider the current state. Over time, the longest chain
will be the one where the majority of computing power has been invested, which
means that it is the one followed by the majority miners.
+This mechanism consists in making the process of appending a block to the
blockchain heavy in computation (mining) by requiring brute force hashing for
example. Nodes willing to invest their computation power (miners), work to
extend the chain they consider the current state. Over time, the longest chain
will be the one where the majority of computing power has been invested, which
means that it is the one followed by the majority of miners.
This falls short as soon as one node control significantly more computation
power than others, the so-called 51\% attacks. This node will not be able to
create invalid blocks, because the other nodes will reject them, but will be
able to rewrite the past and control the mining of future transactions.
@@ -70,15 +89,15 @@ The effectiveness and security of this mechanism have yet
to be proven, but Ethe
\subsubsection*{Block time}
-Achieving consensus within the peer-to-peer network requires broadcasting the
state of the blockchain to most nodes. This coordination takes some time and we
do not want blocks to be mined faster than the network can keep up. The
difficulty algorithm is used to keep the block time close to a constant. On
Ethereum, the block time is 12 to 14 seconds
\footnote{https://ethereum.org/en/developers/docs/blocks/\#block-time}. On
Bitcoin, the block time is about 10 minutes.
+Achieving consensus within the peer-to-peer network requires broadcasting the
state of the blockchain to most nodes. This coordination takes some time and we
do not want blocks to be mined faster than the network can keep up. An adaptive
difficulty algorithm is used to keep the block time close to a constant, by
changing the amount of computation required to mine a block. On Ethereum, the
block time is about 12 to 14 seconds
\footnote{https://ethereum.org/en/developers/docs/blocks/\#bloc [...]
\subsubsection*{Reorganisation}
-These decentralized consensus mechanisms lead to the creation of competing
blockchain states. When two miners broadcast a new valid block in a short
period of time, one part of the network may receive them in a different order
than another part. As nodes will follow the first valid block founded, we have
a blockchain fork. Over time, one fork will become longer than the other, and
nodes will follow the longer chain. They will replace recent blocks as
necessary during a reorganization of [...]
+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 [...]
\subsection{Mining incentive}
-A minimum amount of mining power is required for the cryptocurrency to work.
Without new blocks, there can be no new transaction. The more mining power and
diversity (different miners), the more resistant the currency is to attacks.
Since mining is an expensive process, cryptocurrencies must incentivize it by
offering rewards to miners.
+A minimum amount of mining power is required for the cryptocurrency to work.
Without new blocks, there can be no new transaction. The more mining power and
diversity (different miners), the more resistant the \ac{dlt} is to attacks.
Since mining is an expensive process, cryptocurrencies must incentivize it by
offering rewards to miners.
Rewards are of two kinds:
\begin{itemize}
@@ -92,6 +111,50 @@ As we have seen, blockchain-based cryptocurrencies have
certain limitations by d
\clearpage
+\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.
+
+\subsection{Overview}
+
+\begin{figure}[hb]
+ \begin{center}
+ \input{figures/taler_arch.tex}
+ \end{center}
+ \caption{GNU Taler overview}
+\end{figure}
+
+
+\subsubsection*{Exchange}
+The exchange is the payment service provider for financial transactions
between customers and merchants. The exchange holds money as a reserve for
anonymous digital coins.
+
+\subsubsection*{Customer}
+A customer can withdraw coins from the exchange and store them in his
electronic wallet. These coins can then be spent at a merchant.
+
+\subsubsection*{Merchant}
+A merchant accepts coins in exchange for goods and services. The merchant can
then deposit these coins at the exchange to receive money in return.
+
+\subsubsection*{Auditor}
+Auditors monitor the behaviour of the exchanges to ensure that exchanges
operate correctly. They are typically operated by financial regulators.
+
+\subsubsection*{Settlement layer}
+The settlement layer provides finality for wire transfers that allow customers
to deposit money and merchant to withdraw money from Taler. It is typically
provided by banks. The goal of this project is to use blockchains as a
settlement layer to support blockchain-based cryptocurrencies.
+
+\subsection{Blockchain settlement layer}
+
+\begin{figure}[hb]
+ \begin{center}
+ \input{figures/settlement_layer.tex}
+ \end{center}
+ \caption{Blockchain settlement layer with Depolymerizer}
+\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.
+
+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: [...]
+
+\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.
@@ -186,7 +249,7 @@ Outgoing transactions can be of two types credit or bounce.
Credit metadata cont
\bitbox{1}{\tiny 0} & \bitbox{32}{Transfer ID} &
\bitbox{10}{Base URL}
\end{rightwordgroup} \\ \\
\begin{rightwordgroup}{Bounce}
- \bitbox{1}{\tiny \rotatebox{90}{255}} &
\bitbox{32}{Transaction ID}
+ \bitbox{1}{\tiny \rotatebox{90}{254}} &
\bitbox{32}{Transaction ID}
\end{rightwordgroup}
\end{bytefield}
\end{center}
@@ -199,7 +262,7 @@ There are many documented ways to encode metadata in a
bitcoin transaction \cite
Debits are performed from code using OP\_RETURN to store metadata, but credits
are done from common wallet clients and they do not yet support custom
metadata. We had to find another format using fake addresses.
-We use the latest address type, segwit addresses, which can contain 20B of
chosen data, and the reserve pub key is 32B. Therefore, we use two fake
addresses consisting of the two key halves prepended with the same random
pattern, except for the first bit, which must be 0 for the first half and 1 for
the second. We then send a single transaction with the three addresses as
recipients.
+We use the latest address type, segwit addresses, which can contain 20B of
chosen data. The reserve pub key being 32B, we need two addresses. Therefore,
we use two fake addresses consisting of the two key halves prepended with the
same random pattern, except for the first bit, which must be 0 for the first
half and 1 for the second. We then send a single transaction with three
addresses as recipients.
\begin{figure}[H]
\begin{center}
@@ -233,13 +296,13 @@ Ethereum is designed around the concept of smart
contracts. Logging inside a sma
\subsection{Friendly behavior on format error}
-When we receive a transaction without any metadata or with an incompatible
format (bogus wallet), we want to return the money to its owner (bounce).
However, this is dangerous because we have created a potential attack loophole
as anyone can now make Depolymerizer do a transaction, by sending a malformed
transaction. Depolymerizer takes a bounce fee to make a potential DOS attack
too costly and charges the recipient the transaction fee to ensure it can not
lose money on a bounce.
+When we receive a transaction without any metadata or with an incompatible
format (bogus wallet), we want to return the money to its owner (bounce).
However, this is dangerous because we have created a potential attack loophole
as anyone can now make Depolymerizer do a transaction, by sending a malformed
transaction. Depolymerizer takes a bounce fee to make a potential \acs{dos}
attack too costly and charges the recipient the transaction fee to ensure it
can not lose money on a bounce.
\clearpage
\section{Architecture}
-Each cryptocurrency uses a different distributed ledger (DLT) with its own
format and rules, which evolve over time. We do not want to manage the DLT
logic ourselves, nor do we want to rely on third-party dependencies to
implement their support properly and be maintained. The simplest solution is to
rely on the official clients and communicate with them via RPC.
+Each cryptocurrency uses a different \ac{dlt} with its own format and rules,
which evolve over time. We do not want to manage the \ac{dlt} logic ourselves,
nor do we want to rely on third-party dependencies to implement their support
properly and be maintained. The simplest solution is to rely on the official
clients and communicate with them via RPC.
\begin{figure}[hb]
\begin{center}
@@ -248,9 +311,9 @@ Each cryptocurrency uses a different distributed ledger
(DLT) with its own forma
\caption{Depolymerizer architecture}
\end{figure}
-While some parts of Depolymerizer are DLT specific, much of the logic is
common and we want to reuse it. We have a Wire Gateway component that
implements the Taler HTTP API to enable communication with Taler exchanges.
Each supported cryptocurrency has its specific adapter to communicate with the
official full node client via RPC. The Wire Gateway module and the DLT adapter
use a common database to store transactions and communicate with notifications.
+While some parts of Depolymerizer are \ac{dlt} specific, much of the logic is
common and we want to reuse it. We have a Wire Gateway component that
implements the Taler HTTP API to enable communication with Taler exchanges.
Each supported cryptocurrency has its specific adapter to communicate with the
official full node client via RPC. The Wire Gateway module and the \ac{dlt}
adapter use a common database to store transactions and communicate with
notifications.
-\subsection{DLT adapter}
+\subsection{\acs{dlt} adapter}
The DTL adapter uses an event-based architecture with three distinct loops.
@@ -264,21 +327,21 @@ The analysis loop waits for new blocks and then analyzes
the behavior of the blo
\paragraph*{Worker}
-The worker loop waits for new blocks or transaction requests (from the Wire
Gateway API). When one of these events occurs, it first reconciles the local
database with the DLT, then triggers requested debits, re-issues blocked debits
and bounces malformed credits.
+The worker loop waits for new blocks or transaction requests (from the Wire
Gateway API). When one of these events occurs, it first reconciles the local
database with the \ac{dlt}, then triggers requested debits, re-issues blocked
debits and bounces malformed credits.
\subsection{Worker loop in detail}
-\subsubsection*{DLT reconciliation}
+\subsubsection*{\acs{dlt} reconciliation}
-During a DLT reconciliation, we first list all new transactions and any
transactions that have been deleted in a reorganization since the last
reconciliation. If any previously confirmed debits have been deleted without
being reinserted into another block, we notify the Wire Gateway to cease
activity and wait for the next block in hopes of recovering them. All newly
confirmed debits and successful credits are registered in the database.
+During a \ac{dlt} reconciliation, we first list all new transactions and any
transactions that have been removed in a reorganization since the last
reconciliation. If any previously confirmed debits have been removed without
being reinserted into another block, we notify the Wire Gateway to cease
activity and wait for the next block in hopes of recovering them. All newly
confirmed debits and successful credits are registered in the database.
\subsubsection*{Reconciliation inconsistency}
-When we issue a transaction (debit or bounce), it is possible for the database
or DLT request to fail. Since a DLT request does not mean that the
cryptocurrency transaction was not successful and since the database may not
record a successful transaction, it is possible to have an inconsistency in the
DLT and the database where a successful transaction is not recorded as such.
This is very problematic because we must perform each transaction once.
+When we issue a transaction (debit or bounce), it is possible for the database
or \ac{dlt} request to fail. Since a \ac{dlt} request does not mean that the
cryptocurrency transaction was not successful, and since the database may not
record a successful transaction, it is possible to have an inconsistency
between the DLT and the database where a successful transaction is not recorded
as such. This is very problematic because we must perform each transaction once.
-This is also problematic because even if we used a status machine state in the
database to detect this inconsistency, the only way to resolve it is to make
another DLT reconciliation, which is slow and does not play well with database
locking.
+This is also problematic because, even if we used a status machine state in
the database to detect this inconsistency, the only way to resolve it is to
make another \ac{dlt} reconciliation, which is slow and does not play well with
database locking.
-Since we know that blockchain-based cryptocurrencies have low throughput, we
don not need parallel worker loops to stay synchronized. Therefore, we can use
a cross-process locking mechanism to ensure that only one working loop is
running at a time. Then, when a database or DLT request error occurs, we can
restart the loop, which will start by performing a DLT reconciliation that will
recover all successful unregistered transactions.
+Since we know that blockchain-based cryptocurrencies have low throughput, we
do not need parallel worker loops to stay synchronized. Therefore, we can use a
cross-process locking mechanism to ensure that only one working loop is running
at a time. Then, when a database or \ac{dlt} request error occurs, we can
restart the loop, which will start by performing a \ac{dlt} reconciliation that
will recover all successful unregistered transactions.
\clearpage
@@ -286,9 +349,9 @@ Since we know that blockchain-based cryptocurrencies have
low throughput, we don
\subsection*{Ethereum amount precision}
-The Taler amount format comes from RFC 8905\cite{RFC8905}. It allows up to
$2^{53}$ unit and 8 decimal digits. This format is perfectly suited for Bitcoin
where the maximal amount is 21 million bitcoins and the minimum amount is the
satoshi, one satoshi being worth 108 bitcoin. However, the minimum amount of
Ethereum is the wei, with one ether being worth $10^{18}$ wei. The amount of
ether in circulation continues to grow without a cap, with over 119 000 000
ether in circulation at the t [...]
+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 its 8 first
decimal, we can still represent any amount you can send whiteout losing money
on the transaction fee.
\subsection*{Replaceable bitcoin transaction}
@@ -296,7 +359,7 @@ When some merchants wanted to allow instant payments with
Bitcoin, they chose to
This becomes problematic when you want to make a legitimate replacement, to
unstuck a transaction by increasing its transaction fee for example. At the
same time, it is always dangerous to give an easy way to attackers and scammers
to change the content of a pending transaction.
-A solution has been adopted in BIP 125 \cite{BIP125}. It is now possible to
encode the replaceability of a bitcoin transaction when creating it. This
allows it to be replaced by a new transaction within certain rules: you cannot
send less money to existing recipients and you must pay a replacement fee as a
countermeasure to a DOS attack.
+A solution has been adopted in BIP 125 \cite{BIP125}. It is now possible to
encode the replaceability of a bitcoin transaction when creating it. This
allows it to be replaced by a new transaction within certain rules: you cannot
send less money to existing recipients and you must pay a replacement fee as a
countermeasure to a \acs{dos} attack.
\clearpage
@@ -304,22 +367,22 @@ A solution has been adopted in BIP 125 \cite{BIP125}. It
is now possible to enco
\subsection*{The need for compact URI}
-As discussed in the previous chapter, storing metadata in blockchain is
-expensive and limited. Therefore we want our metadata to be as small as
possible.
+As discussed previously, storing metadata in blockchain is
+expensive and limited. Therefore, we want our metadata to be as small as
possible.
\noindent
Transactions metadata are composed of three parts:
\begin{itemize}
\item Version and identity metadata ($\sim$ 1B)
\item Reserve public key or wire transfer id (32B)
- \item Base uri (debit only, variable)
+ \item Base url (debit only, variable)
\end{itemize}
-The only variable and so problematic part is the base url. Those url have some
+The only variable, and so problematic, part is the base url. Those url have
some
property in common, they always use a few different scheme (http or https) and
are composed of a domain and a small path.
-We would normally encode the url using ASCII but we known only a few ASCII
+We would normally encode the url using ASCII, but we known only a few ASCII
character are actually used.
\subsection*{5 or 11 encoding}
@@ -327,7 +390,7 @@ character are actually used.
Our idea is to encode the most commonly used characters using five bits, and
the
remaining characters using eleven bits. As an ASCII character take eights bits
we gain on size if more than half of the characters composing the uri are
-encodable using only 5 bits.
+encodable using less bits.
\begin{center}
\begin{tabular}{l l l}
@@ -341,8 +404,7 @@ encodable using only 5 bits.
Using this encoding format on all domains on the
majestic-million\footnote{https://majestic.com/reports/majestic-million}
-database, $98.77\%$ of the domain name where smaller, going from an average
encoded
-size of 14B in ASCII to 10B using our format.
+database, $98.77\%$ of the domain name where smaller, going from an average
encoded size of 14B in ASCII to 10B using our format.
\subsection*{Uri in metadata}
@@ -350,7 +412,7 @@ To further optimize metadata size we chose to encode the
URI scheme into the
version and identity metadata byte and the remaining domain and path using our
custom format.
-For example for bitcoin the maximum amount of data than is accepted in
+For example, for bitcoin the maximum amount of data than is accepted in
OP\_RETURN is currently 80 bytes, leaving us 47 bytes to store the URI. With
our
encoding we can encode in the best case 74 characters instead of 47 which is
more
enough for our use case.
@@ -359,17 +421,17 @@ enough for our use case.
\section{Taler Wire Gateway HTTP API}
-Taler is a modular project where each module communicates through HTTP API.
The Wire Gateway API allows the exchange to communicate to wire adaptors. My
first task was to implement a server in Rust to link the depolymerizer
implementation to the Taler system. As the API can be exposed on the Internet
it has to be resistant to easy attacks.
+Taler is a modular project where each module communicates through HTTP API.
The Wire Gateway API allows the exchange to communicate to wire adaptors. The
Wire Gateway module allow Depolymerizer to communicate with Taler exchanges. As
the API can be exposed on the Internet it has to be resistant to easy attacks.
\subsection*{HTTP Authentication}
The wire API only supports the Basic HTTP Authentication method and it has to
be optional. Making it optional can lead to security issues by
misconfiguration. If the default behavior in case of missing configuration is
to deactivate authentication, a typo could lead to an exposed API. We made the
authentication method configuration mandatory to make its deactivation explicit.
-\subsection*{OOS DOS}
+\subsection*{OOM \acs{dos}}
-A common Denial Of Service attack consists of sending many requests with huge
bodies to saturate a server memory and, in the worst case, create an Out Of
Memory error. To be resilient against such attacks we only read body after
request authentication to prevent any person without authorization to access
the API to perform such attacks.
+A common Denial Of Service attack consists of sending many requests with huge
bodies to saturate a server memory and, in the worst case, create an Out Of
Memory error. To be resilient against such attacks we only read body after
request authentication, to prevent any person without authorization to access
the API to perform such attacks.
-Then we chose an aggressive memory budget of 4kB as all request bodies should
be very small and we only read and parse them under this budget. In the case of
compressed bodies, we also apply this budget to the decompression process to
protect ourselves against decompression bombs.
+Then we chose an aggressive memory budget of 4kB, as all request bodies should
be very small, and we only read and parse them under this budget. In the case
of compressed bodies, we also apply this budget to the decompression process to
protect ourselves against decompression bombs.
\subsection*{Testing}
@@ -394,4 +456,8 @@ There is an opportunity for a more intelligent analysis of
network behaviours to
\bibliographystyle{alpha}
\bibliography{literature}
+\clearpage
+
+\printacronyms
+
\end{document}
diff --git a/eth-wire/src/lib.rs b/eth-wire/src/lib.rs
index 6336c4f..041f3ba 100644
--- a/eth-wire/src/lib.rs
+++ b/eth-wire/src/lib.rs
@@ -77,7 +77,7 @@ pub trait RpcExtended: RpcClient {
value,
nonce: None,
gas_price: None,
- data: Hex(metadata.encode()),
+ data: Hex(metadata.encode().or_fail(|e| format!("{}", e))),
})
}
@@ -94,7 +94,7 @@ pub trait RpcExtended: RpcClient {
value: bounce_value,
nonce: None,
gas_price: None,
- data: Hex(metadata.encode()),
+ data: Hex(metadata.encode().or_fail(|e| format!("{}", e))),
};
// Estimate fee price using node
let fill = self.fill_transaction(&request)?;
--
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 (9d00fd8 -> d6195b5),
gnunet <=