# Evaluating Methods for the Identification of Off-Chain Transactions in the Lightning Network
## 4 Methodology and Implementation
### Blockchain Analysis
#### 4.1.1 Using 2 of2 Multisig for Identification  
Channel graphs created with the use of our method contain the funding and closing transactions as shown in Figure 4. This is important for all types of channel graphs, as these transactions (funding and closing) are the key data points that can be extracted from the blockchain proper, and relate to LN channels. To create the channel graphs when parsing the blockchain, we must be able to differentiate between on-chain LN transactions and other Bitcoin transactions that are not LN-related. Therefore, we must find some characteristics needed or only found in on-chain LN transactions. In Figure 4 we can see some characteristics of the funding and closing transactions. The output in the funding transaction used for the channel must be P2 WSH, and the closing transaction will always have one input which will be the 2 of2 multisig redeem script as explained in Section 2.4. The different characteristics have different levels of uniqueness, but using more unique characteristics will often impact the number of channels that can be identified. There is a trade-off between precision and sensitivity. An example of this is the P2 WSH output type, which is not unique, so it provides false positives, but it improves sensitivity (all LN funding transaction use P2 WSH). It allows the detection of both closed and open channels. The 2 of2 redeem script is more unique, as it is a specific redeem script and must therefore also belong to a P2 WSH output-input pair. In the funding transaction we will only be able to check if it has any P2 WSH outputs, while the closing transaction allows us to check for the 2 of2 multisig characteristic, which the presence of also entails the P2 WSH. Using closing transactions limits us to closed channels, but the transactions matching our characteristics are more likely to be LN-related. While the 2 of2 multisig redeem script is present in all closing transactions for LN channels, they can also be used for other purposes. We, therefore, cannot use this to determine with full certainty if a transaction is a closing transaction or not, but it will rule out all transactions without this characteristic. By locating all transactions that have inputs with such redeem scripts, we have all potential closing transactions, and by following the input-output connection we can also locate the funding transaction, providing us with a channel graph with the transactions as shown in Figure 4.  
Creating the channel graphs as explained above, enables us to identify the transactions in the channel graph in the reverse-order in relation to their creation, i.e., we identify the closing transaction first, and use it to find the funding transaction. All the transactions form a DAG, meaning they are located chronologically in the blockchain, with the newer transaction being found towards the tip of the chain. For the transactions in our channel graphs, this means that the closing transactions will be found before the funding transaction, as the closing uses the output of the funding. We must, therefore, parse the blockchain in reverse, beginning with the most recent block, and working towards the genesis (first) block. Figure 4: Channel graph with funding and closing transactions. Our software parses the blockchain and identifies relevant transactions, using both the multisig and timelocked identification methods. We use the btcd[19] Bitcoin implementation which is written in Golang, to synchronize and store the blockchain data. Our software, which is also written in Go, uses libraries from btcd to read this data from disk and make it available to us as a convenient data structure. At a high level our software finds the latest block from the blockchain stored on disk and uses it as a starting point; it then iterates over the transactions in the block, and checks if they are relevant, i.e., they are part of a channel graph. If that is the case the transactions are stored in a data structure representing a channel graph.