commit b5bb643e425598c604d993b9664888fad215a719
parent dffc5ba48b5031a229f7aa948c1853180b805639
Author: Antoine A <>
Date: Tue, 19 Apr 2022 12:48:45 +0200
Support any network in segwit demo
Diffstat:
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git 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 common::{
base32::{self, Alphabet},
@@ -6,7 +8,7 @@ use common::{
};
pub fn main() {
- let address = "bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4";
+ let address = Address::from_str("bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4").unwrap();
let amount = Amount::from_sat(10000000);
let reserve_pub = "0ZSX8SH0M30KHX8K3Y1DAMVGDQV82XEF9DG1HC4QMQ3QWYT4AF00";
let btc = amount.as_btc();
@@ -49,8 +51,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
@@ -60,11 +67,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/docs/report.tex b/docs/report.tex
@@ -190,7 +190,7 @@ Some properties of blockchain-based cryptocurrencies are problematic for their u
\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 deeper a block is in the blockchain, the harder it is to replace. The depth of a block determines its probability of persistence. The solution is therefore to wait until a block has a certain number of blocks linked to it before considering its transactions as final (Figure \ref{fig:conf_delay}).
+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, the harder it is to replace. The depth of a block determines its probability of persistence. The solution is therefore to wait until a block has a certain number of blocks linked to it before considering its transactions as final (Figure \ref{fig:conf_delay}).
\begin{figure}[H]
\begin{center}
@@ -242,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}
@@ -364,7 +364,7 @@ During a \ac{DLT} reconciliation, we first list all new transactions and any tra
\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.
@@ -378,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 the time of writing those lines. Therefore, it is not possible to represent all Ethereum amounts with the current format.
-A standard Ethereum transaction requires 21 000 units of gas\footnote{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}
@@ -386,7 +386,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 \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
@@ -449,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}
@@ -469,16 +469,23 @@ The Taler exchange has a taler-exchange-wire-gateway-client CLI that allowed me
\clearpage
-\section{Future work}
+\section{Conclusion}
-\subsection*{Paying for reorganization loss}
+\subsection*{Summary}
+
+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.
+
\clearpage
\bibliographystyle{alpha}
