# Evaluating Methods for the Identification of Off-Chain Transactions in the Lightning Network
## 4 Methodology and Implementation
### Blockchain Analysis
#### 4.1.2 Identification Using Timelocked Redeem Scripts
To make the script use the else clause with the timelock, and check the signature against the <local_delayedpubkey> the witness data should be: <local_delayedsig> 0. Similar to the revocation clause, we have a signature, and the constant 0 will make the script not use the if clause. Meaning the OP_CHECKSIG will be used to verify the <local_delayedsig> against the <local_delayedpubkey>, as long as the timelock has expired. This means we can easily check if a timelocked script was revoked. By checking the witness data provided to the script for 0 or 1, we can determine which clause was used, and, as it is included in the blockchain, the script has been evaluated and found to be valid. Below is the raw byte representation of a specific redeem script of the type shown above. We depict it because our implementation handles the byte version of the scripts when identifying them. The byte version has been formatted in the same manner as the clear-text version, to allow for easier comparison. 99  
33 3 251 83 243 198 231 109 204 252 217 94 44 221 0 255 185 86 106 105 161 141 254 96 16 77 48 16 57 146 128 4 80 103  
82
178  
117  
33 2 159 6 236 212 233 63 48 147 59 52 201 11 15 138 165 248 118 100 188 234 227 215 108 160  
135 22 57 37 117 250 172 130  
14  
172  
The first byte seen in the byte script above is 99 which is the opcode for the OP_IF operation. The next is 33, which indicates how many bytes to push. Same as explained earlier for the 2 of2 multisig script: this is the length of a compressed public key with a prefix. So, the next 33 bytes are the <revocationpubkey>. After the public key, we have the OP_ELSE with the opcode 103, followed by the 82 'to_self_delay' which is the delay used for the OP_CHECKSEQUENCEVERIFY (OP_CSV) operation, with opcode 178. Next byte is 117 which is the OP_DROP operation, and after that, we find the <local_delayedpubkey> in the same format as <revocationpubkey>; 33 indicating the number of bytes to push to the stack followed by the prefix and the rest of the key. After that, we have 104 which is the opcode for OP_ENDIF, and 172 for OP_CHECKSIG. To identify this type of redeem script in timelocked transactions we check if the opcodes can be found at the expected locations, e.g., index 0 of the byte array should be 99 for the OP_IF, and 103 for the OP_ELSE operation should be at index 35, allowing space for a public key between it and the OP_IF operation. Each opcode found in this script type is used for recognition, meaning all opcodes covered there must be present in the script for it to be identified as a timelocked redeem script, and they must also be found at their expected location relative to the others. Because transactions in a block can have any order, and both funding and closing transaction can be placed in the same block, we had to conduct two passes over transactions in a block, o iterate over the transactions in the block a Tsecond time if we found any LN-related transactions, to make sure we did not miss the preceding transaction earlier in the block. Even with parsing some blocks twice the software parsed blocks fairly quickly. We could achieve parsing rates of 100 million transactions in under 90 min. The memory consumption was also low, as our software only stored channel graphs and the hash lists for transactions we were currently looking for.