# 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  
The main method for identifying LN channels based on Blockchain data relies on timelocked redeem scripts. While more unique than the 2 of2 multisig redeem scripts, it only exists on channels that are unilaterally closed--i.e., the channel is closed by one of the parties, and not cooperatively. In Figure 6 we can see how a channel graph is structured when this method is used. We still have the funding and closing transactions, but the closing transaction is also a commitment transaction, as it was used to close the channel. When a commitment transaction is published, the output to the entity closing the channel will be timelocked, as we explained in Section 2.4. This is to enable the other party to spend the output using the revocation key, in the case of the commitment being revoked--i.e., any commitment other the most recent. This is implemented using a P2 WSH output, which has a redeem script containing a timelock, and a clause for the revocation key. As redeem scripts are only available in the input of the transaction spending the P2 WSH output, similarly as with the 2 of2 multisig redeem script, we find this script in the transaction spending the timelocked output. We refer to this transaction as the timelocked transaction, which can be seen on the right in Figure 6.  
While the timelocked transaction containing the redeem script is not present in channels closed cooperatively, the uniqueness of the script ensures the transactions that are identified using this characteristic are likely to be actual timelocked transactions from the LN. When a timelocked transaction is identified, we can use its input where we found the redeem script to get the hash of the closing/commitment transaction. We can, subsequently, use the input of the closing/commitment transaction to get the funding transaction. This way we can get all transactions in the channel graph. We can also use the fact that the closing/commitment transaction has the 2 of2 multisig redeem script. By checking that the closing/commitment transaction has this script in its input, same as we did in the multisig method, we are further ensuring that we have found a LN channel. Even with the timelocked scripts being unique, because of its specific use case, users are free to create the scripts they wish, so the presence of such a script will not guarantee that we have found a LN timelocked transaction. While also LN-related, we see in Section 4.1.3 how scripts with the same purpose are used in different transactions. By checking that the closing transaction has the characteristics we expect, we can avoid mistaking instances where a timelocked script is used in other scenarios, rather than in the LN context. This whole process can be seen in Figure 7, which is similar to the one in Figure 5 (but more complex). The timelocked redeem script defined in [13], is the redeem script used to identify the timelocked transactions, and can be seen below:  
OP_IF  # Penalty transaction  <revocationpubkey> OP_ELSE  'to_self_delay'  
Figure 6: Channel graph of unilaterally closed channel. Figure 7: Algorithm for parsing blockchain and creating channel graphs using the timelocked method. OP_CSV  
OP_DROP  <local_delayedpubkey>  
OP_ENDIF OP_CHECKSIG  
The script contains an if-else clause, with the TRUE clause being the one which allows the opposing party to spend the output in the case of the commitment transaction being revoked. By supplying <revocation_sig> 1 with a valid signature, the script will evaluate to true. The constant 1 will make the script evaluate the first clause, and then the signature will be matched to the <revocationpubkey> using OP_CHECKSIG. The else clause is the timelocked part of the script. It will contain the timelock, enforced by the CHECKSEQUENCEVERIFY operation defined in [20], which will terminate the script if the specified delay has not passed. The delay is then removed from the stack with OP_DROP such that a signature and public key are the only two items on the stack.