Remove comments

2022-02-08 10:12:02 +01:00 · 2022-02-08 10:12:02 +01:00 · 631d7eb218
commit 631d7eb218
parent 210af34726
2 changed files with 60 additions and 37 deletions
--- a/project3/report3.pdf
+++ b/project3/report3.pdf
--- a/project3/report3.tex
+++ b/project3/report3.tex
@ -63,57 +63,80 @@ Our group consists of the following members:
 \matriculation
 \end{center}
 \section*{Project overview}
 The aim of this project is to write and interact with applications/smart contracts built on Bitcoin, using Bitcoin script. You will interact with the Bitcoin testnet, an alternative Bitcoin blockchain, where the coins have no value, used mainly for testing. In a separate email you will receive some private keys, pre-images and some unspent transaction outputs (UTXOs) and have to solve the tasks below. The following values are included in the email:
 \begin{itemize}
    \item $\langle$ALICE\_SK$\rangle$: secret key for Alice (Exercise A)
    \item $\langle$BOB\_SK$\rangle$: secret key for Bob (Exercise A)
    \item $\langle$CAROL\_SK$\rangle$: secret key for Carol (Exercise B)
    \item $\langle$DAVE\_SK$\rangle$: secret key for Dave (Exercise C)
    \item $\langle$PUNISH\_SECRET$\rangle$: pre-image of a SHA256 hash used for punishing the old payment channel state in Exercise B
    \item $\langle$UNKNOWN\_HASH$\rangle$: SHA256 hash of an unkown pre-image (Exercise C)
    \item $\langle$TX\_IN\_EX1\_HASH$\rangle$: The transaction holding one UTXO, which is for your Exercise A
    \item $\langle$TX\_IN\_EX2\_HASH$\rangle$: The transaction holding one UTXO, which is for your Exercise B
    \item $\langle$TX\_IN\_EX3\_HASH$\rangle$: The transaction holding one UTXO, which is for your Exercise C
 \end{itemize}
 Every person has received their own set of these values (make sure that you did, otherwise contact us). Similar to the second project, you can solve this project as a group and write the report together (including the work distribution), but everyone needs to deploy the solution for their given UTXOs individually. On TUWEL, we provide you with a Python solution skeleton using the bitcoin-utils library including interaction with the testnet. You are free to use any other programming language/library, but note that if you do, we do not offer support. You can investigate \texttt{scripts.py} to view the scripts of each of the given exercise you need to spend along with how scripts are constructed using bitcoin-utils in Python. Be sure to check \url{https://en.bitcoin.it/wiki/Script} for the exact behavior of the op-codes. In your solution you need to construct a scriptSig that is able to spend the scriptPubKey of the given UTXO (see \url{https://en.bitcoin.it/wiki/Transaction#Verification}). If you use the solution skeleton, the main code you want to modfiy and execute is in \texttt{students.py}, the other files are mainly helpers.
 To investigate the transactions and track your progress, we recommend that you use a blockchain explorer for the testnet, for example you could use  \url{https://live.blockcypher.com/btc-testnet/} or  \url{https://blockstream.info/testnet/}, which allows you to view details of transactions, scripts, addresses, etc., and also lets you post raw transactions to the testnet manually, should you wish. Each of your UTXOs holds 5000 satoshis, which should be more than enough to pay for fees if you use the values indicated in the exercises. Finally, we consider an exercise solved if you have (i) spent the UTXO corresponding to that exercise and (ii) if you have given this money to the addresses as indicated in the exercise description. Again, you can check this yourself on the testnet explorer. Write and submit a report where you explain how you solved the exercises (you can use this template and delete the exercise descriptions).
 \section{Payment Channel: honest closure}
-%\emph{Alice wants to buy some goods from Bob. They want to save fees, and Alice heard that using payment channels reduce the on-chain load. They know that you have completed the cryptocurrencies lecture at TU Wien and, naturally, ask for your help. She therefore goes ahead and opens a channel with Bob by posting a funding transaction on-chain. All the money from the funding comes from Alice, so in the beginning she owns all the coins. They proceed to perform off-chain payments until, finally, Bob owns all the money in the channel. In this scenario, Bob has no intention in paying money to Alice, so he decides to unilaterally close the channel.}
+\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.
-%\noindent\rule[0.5ex]{\linewidth}{1pt}
+\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{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. 
+\paragraph{Bonus question:} As described, this final state differs from a
-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.  
+regular state, as it has no revocation mechanism, timelock and is not
-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.
+duplicated. Why do we need these things in a regular state and how does the
 duplication work?
-\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.
+% Fill here your answers for exercise A
 \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}
-%\emph{Your reputation as an off-chain expert is growing. Thus, you are contacted by Carol, who requires your assistence. She says: ``I recently opened a channel with Mallory which we have been using a lot. I just noticed that Mallory has posted an old state of the channel. Please help me, I don't want to lose any money.'' After sharing the relevant information with you, you take a look. Indeed, it seems that Mallory has posted an older state of the channel, where he has almost all of the balance of the channel. You notice that there is also an HTLC in the channel, apparently they used this channel to route other payments as well. ``Why are these people not using a Lightning Network node? And why do they keep sharing their private keys with me?'' you wonder as you pour a cup of coffee and start to punish Mallory and giving the full channel capacity to Carol.}
+\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.}
-%\noindent\rule[0.5ex]{\linewidth}{1pt}
+\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?
-\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.}
+% Fill here your answers for exercise B
 \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?
 \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.}
+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.}
 \section*{Work distribution}
-%Fill in here an overview on which group member participated in which task and to which extent
+%Fill in here an overview on which group member participated in which task and
 %to which extent
 \end{document}