181 lines
7.3 KiB
TeX
181 lines
7.3 KiB
TeX
\documentclass[12pt,a4paper]{article}
|
|
|
|
\usepackage[cm]{fullpage}
|
|
\usepackage{amsthm}
|
|
\usepackage{amsmath}
|
|
\usepackage{amsfonts}
|
|
\usepackage{amssymb}
|
|
\usepackage{xspace}
|
|
\usepackage[english]{babel}
|
|
\usepackage{fancyhdr}
|
|
\usepackage{titling}
|
|
\usepackage{url}
|
|
\usepackage{minted}
|
|
\usepackage{xcolor} % to access the named colour LightGray
|
|
\definecolor{LightGray}{gray}{0.9}
|
|
\renewcommand{\thesection}{Exercise \Alph{section}:}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% This part needs customization from you %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
% please enter your group number your names and matriculation numbers here
|
|
\newcommand{\groupnumber}{04}
|
|
\newcommand{\name}{Tobias Eidelpes, Mehmet Ege Demirsoy, Nejra Komic}
|
|
\newcommand{\matriculation}{01527193, 01641187, 11719704}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% End of customization %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
\newcommand{\projnumber}{3}
|
|
\newcommand{\Title}{Bitcoin Applications}
|
|
\setlength{\headheight}{15.2pt}
|
|
\setlength{\headsep}{20pt}
|
|
\setlength{\textheight}{680pt}
|
|
\pagestyle{fancy}
|
|
\fancyhf{}
|
|
\fancyhead[L]{Cryptocurrencies - Project \projnumber\ - Bitcoin applications}
|
|
\fancyhead[C]{}
|
|
\fancyhead[R]{\name}
|
|
\renewcommand{\headrulewidth}{0.4pt}
|
|
\fancyfoot[C]{\thepage}
|
|
|
|
|
|
\begin{document}
|
|
\thispagestyle{empty}
|
|
\noindent\framebox[\linewidth]{%
|
|
\begin{minipage}{\linewidth}%
|
|
\hspace*{5pt} \textbf{Cryptocurrencies (WS2021/22)} \hfill Prof.~Matteo Maffei \hspace*{5pt}\\
|
|
|
|
\begin{center}
|
|
{\bf\Large Project \projnumber~-- \Title}
|
|
\end{center}
|
|
|
|
\vspace*{5pt}\hspace*{5pt} Deadline: February 27, 2022 at 23:59\hfill TU Wien \hspace*{5pt}
|
|
\end{minipage}%
|
|
}
|
|
\vspace{0.5cm}
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
\section*{Group \groupnumber}
|
|
Our group consists of the following members:
|
|
\begin{center}
|
|
\textbf{\name}
|
|
|
|
\matriculation
|
|
\end{center}
|
|
|
|
\section{Payment Channel: honest closure}
|
|
|
|
\paragraph{Your task:} You have been provided with a secret key for both Alice
|
|
$\langle$ALICE\_SK$\rangle$ and Bob $\langle$BOB\_SK$\rangle$, as well as an
|
|
on-chain funding transaction of the channel $\langle$TX\_IN\_EX1\_HASH$\rangle$.
|
|
This funding transaction locks some money in a Multisig address of Alice and
|
|
Bob. They have used this channel for a while now and wish to close it. In the
|
|
final state of the channel, Alice has a balance of 1000 satoshis and Bob has
|
|
2000 satoshis. %Note that Bob cannot spend his funds right away, but needs to
|
|
wait for some time. Only after some time, Bob can claim his balance. Since they
|
|
both cooperatively wish to close the channel, they create a new transaction that
|
|
does not have any timelock or revocation mechanism, but simply takes the
|
|
Multisig from the funding as input and creates two outputs, one for Alice and
|
|
one for Bob. You need to create the transaction of the final state of Bob, sign
|
|
it and post it on the Bitcoin testnet. \textbf{This exercise is considered
|
|
solved if your UTXO for exercise A is spent in a transaction with two outputs,
|
|
Alice owning 1000 and Bob 2000 satoshis, both as P2PKH (see
|
|
\url{https://learnmeabitcoin.com/technical/p2pkh}).} In other words, this means
|
|
that, e.g., for Alice, 1000 satoshis need to be locked in the following script:
|
|
\texttt{OP\_DUP OP\_HASH160 <Alice\_pubKeyHash> OP\_EQUALVERIFY OP\_CHECKSIG}.
|
|
You can use the attribute \texttt{Id.p2pkh} of the helper class \texttt{Id} we
|
|
provide.
|
|
|
|
\paragraph{Hint:} The opcode \texttt{OP\_CHECKMULTISIG} actually has a bug where
|
|
it pops one extra element of the stack. Take this into account when spending
|
|
from the Multisig.
|
|
|
|
\paragraph{Bonus question:} As described, this final state differs from a
|
|
regular state, as it has no revocation mechanism, timelock and is not
|
|
duplicated. Why do we need these things in a regular state and how does the
|
|
duplication work?
|
|
|
|
% Fill here your answers for exercise A
|
|
|
|
\section{Payment Channel: punishing misbehavior}
|
|
|
|
\paragraph{Your task:} Carol $\langle$CAROL\_SK$\rangle$ and Mallory have opened
|
|
a Lightning-style payment channel. You have been provided with a secret key for
|
|
Carol, as well as an on-chain commitment transaction
|
|
$\langle$TX\_IN\_EX2\_HASH$\rangle$ of the channel between Carol and Mallory.
|
|
However, Mallory tried to cheat and posted a commitment transaction on-chain
|
|
representing an old state where he has a lot more money than in the most recent
|
|
state. Since old states are revoked, you know the revocation secret
|
|
$\langle$PUNISH\_SECRET$\rangle$. You need to create a punishment transaction
|
|
taking the balance that belongs to Mallory (which is the output with index 0 of
|
|
the commitment transaction), giving it to Carol and post it on the testnet.
|
|
\textbf{This exercise is considered solved if your UTXO for exercise B is spent
|
|
in a transaction with one output, which gives Carol 2000 satoshis as P2PKH.}
|
|
|
|
\paragraph{Bonus question:} To have multi-hop payments in a Payment Channel
|
|
Network (PCN), payment channels can be used to route HTLC-based (Hash Time-Lock
|
|
Contract) payments. These HTLCs are additional outputs in a channel, that need
|
|
to be punished. Following the example above, assume that Mallory has posted an
|
|
old state that holds one (or more) HTLCs. Now Carol needs to punish the output
|
|
holding Mallory's balance plus each output holding an HTLC. How can she make
|
|
this punishment more efficient? Is there a way to decrease the amount of
|
|
\textit{things} you need to put on-chain?
|
|
|
|
% Fill here your answers for exercise B
|
|
|
|
\section{Exploit faulty script}
|
|
|
|
Dave $\langle$DAVE\_SK$\rangle$ and Mallory have locked some funds in an output,
|
|
that looks similar to a commitment transaction
|
|
$\langle$TX\_IN\_EX3\_HASH$\rangle$. However, we placed some ``bugs'' in this
|
|
script. This allows you to spend the money locked in this contract to Dave's
|
|
address even though the timelock is way in the future. \textbf{This exercise is
|
|
considered solved if your UTXO for exercise C is spent in a transaction with one
|
|
output, which gives Dave 4000 satoshis as P2PKH.}
|
|
|
|
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos]{text}
|
|
OP_DUP OP_HASH160
|
|
OP_PUSHBYTES_20 <dave_pk_hash>
|
|
OP_EQUALVERIFY OP_CHECKSIGVERIFY
|
|
OP_IF
|
|
OP_PUSHBYTES_3 fbd42f OP_CLTV
|
|
OP_DROP OP_DUP OP_HASH160
|
|
OP_PUSHBYTES_20 <dave_pk_hash>
|
|
OP_ELSE
|
|
OP_SHA256
|
|
OP_PUSHBYTES_32 <hash_lock>
|
|
OP_EQUAL OP_2DUP OP_HASH160
|
|
OP_PUSHBYTES_20 <irrelevant_hash>
|
|
OP_2ROT OP_DUP OP_DUP
|
|
OP_ENDIF
|
|
OP_EQUALVERIFY OP_CHECKSIGVERIFY
|
|
OP_2DROP OP_DROP OP_NOT
|
|
\end{minted}
|
|
The script provided to us contains a bug where the \texttt{OP\_EQUAL} opcode is
|
|
used but the return value is never checked (line 11). Unlocking the script
|
|
before the locktime has expired is thus possible without knowing the preimage of
|
|
the hash in line 10. The value on the stack is hashed with \texttt{SHA256} and
|
|
compared with the hash lock. Execution of the script continues regardless of the
|
|
outcome of this comparison. If the \texttt{OP\_EQUAL} opcode is replaced with
|
|
\texttt{OP\_EQUALVERIFY}, the script will halt if the comparison fails,
|
|
restoring intended behavior.
|
|
|
|
The following unlocking script allows successful spending of the output:
|
|
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos]{text}
|
|
<sig_dave>
|
|
<id_dave.pk.to_hex()>
|
|
OP_0
|
|
OP_0
|
|
<sig_dave>
|
|
<id_dave.pk.to_hex()>
|
|
\end{minted}
|
|
|
|
\section*{Work distribution}
|
|
%Fill in here an overview on which group member participated in which task and
|
|
%to which extent
|
|
|
|
\end{document}
|