\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}