# Evaluating Methods for the Identification of Off-Chain Transactions in the Lightning Network
## 2 Background
### Transaction Scripts  
Bitcoin transactions use a stateless, stack-based, non-Turing complete language called simply script[8]. The outputs of transactions are locked using scripts that place requirements for spending the outputs; inputs contain scripts that meet the requirements placed by their respective output scripts. The language has a predefined set of operations that can be done, called opcodes, which limits the possibilities of scripts. An example of a common locking script placed in outputs are:  
OP_DUP OP_HASH160 <receivers public key hash> OP_EQUALVERIFY OP_CHECKSIG  
This script is an example of Pay to Public Key Hash (P2 PKH) script. The sender can use this script to lock the output to the receiver public key hash. The receiver can spend this output by supplying their \(<signature><\)_publickey_\(>\) in the input, which will meet the requirements placed by the output script and unlock the funds. The unlocking script will be combined with the locking script and executed to ensure that it is valid. <receivers signature> <receivers public key> OP_DUP OP_HASH160  <receivers public key hash> OP_EQUALVERIFY OP_CHECKSIG  
The goal of this script is to check if the <public key> in the unlocking part hashes to the <public key hash> of the locking part, and then if the <signature> in the unlocking part matches the public key. When the script executes, the execution pointer will move left to right pushing data to the stack and do the operations specified. In the case of P2 PKH scripts, the <signature> will be moved to the stack followed by the <public key>, OP_DUP duplicates the top item on the stack, in this case the <public key>. Then the OP_HASH160 will hash the top item on the stack, which is the top <public key>. The <public key hash> given in the locking part of the script will then be pushed to the stack and OP_EQUALVERIFY will compare the two top items, which now are the <public key hash> and the hash of the <public key> created by the OP_HASH operation previously, if they are equal they are both removed from the stack. The final operation OP_CHECKSIG takes the two last items on the stack: <public key> and <signature> and checks if the signature matches the public key, which means it was created with the corresponding private key. There are two standard transaction types commonly used presently: one is the pay to public key hash (P2 PKH) already described, and the other is pay to script hash (P2 SH) [9]. While users are free to create any locking script they wish within the limits of the language, these types are recognized by most wallet software and allow for senders to transfer value by locking it in known ways. With P2 PKH the receiver can just send a hash of their public key, and the sender can create the locking script as outlined above and just insert the hash. P2 SH transactions allow for the same process but using the hash of a script instead of the hash of a public key. This allows for complex scripts to be created and hashed by the recipient. The hash value is then used for creating the locking script, resulting in:  
HASH160 <script hash> EQUAL  
The unlocking script will contain the script that was used to create the hash as one stack item only. When this is executed the entire original script, known as the redeem script, will be pushed to the stack, and then hashed using OP_HASH. Then the script hash from the unlocking script is pushed to the stack, and finally the two hashes are compared. The unlocking and locking script for this is shown below:  
<redeem script> HASH160 <script hash> EQUAL  
This hashing and comparing of hashes will ensure that the script supplied is the original one. After it is confirmed in the manner explained above, the redeem script itself is executed to check if it evaluates to true. The conditions for the redeem script must also be satisfied meaning that potential signatures or other data must also be supplied in the input unlocking an output.