# Evaluating Methods for the Identification of Off-Chain Transactions in the Lightning Network
## 2 Background
### Payment Channels in the Lightning Network  
A payment channel allows for two people to connect and transfer funds between themselves. When many users create channels with each other, a network of channels is formed. Here we focus on how a channel allows for two people to transact in a trustless manner. The payment channels use Bitcoin transactions for both managing the channels and to send funds inside the channel. However, not all the transactions are broadcast to the Bitcoin network. All non-broadcasted transactions are therefore not included in the blockchain. At a high level, the channel is used by two participants to keep track of how funds are distributed between the stakeholders. This means that the channel has a balance showing how much funds each of the two participants has. The balance is updated as funds are sent between them. This is the basic premise of payment channels: when two people send funds between themselves, it should not be necessary to broadcast each transfer, instead only the final result, e.g., [PERSON] and [PERSON] have a channel with a value of one coin, with the initial distribution being 0.5 to each; [PERSON] sends [PERSON] 0.1 coins in three separate transactions, resulting in a final distribution of 0.2 to [PERSON] and 0.8 to [PERSON]; this result is broadcast while the three 0.1 transactions are not. Using the example above we can see that only publishing the result requires one transaction to be broadcast, in comparison to three transactions if all intermediary transactions were broadcast. The transactions that are broadcast are called on-chain transactions, since they will be included in the blockchain. Off-chain transactions are the intermediary transactions not broadcast, and therefore not found on the blockchain. While payment channels allow for multiple transactions to be done off-chain, they do require some on-chain transactions for managing the channels. One of these on-chain transactions is the funding transaction, which is used to create the channel and make a common starting point for the users in the channel. The funding transaction will contain an output locked using a multisig script, which we discussed earlier in Section 2.2. The multisig redeem script used for the output creating the channel has the form [13]:  
2 <public key 1> <public key 2> 2 OP_CHECKMULTISIG  
The multisig script requires multiple signatures from different keys to be spent. The script above is a 2 of2 multisig script when we denote it in the form of \(n\) of \(m\), where the number \(n\) is the required and \(m\) is the potential number of keys. Using 2 of2 multisig scripts for the payment channel output in the funding transaction means that both parties in the channel must sign the transaction to spend it. This collectively controlled output in the funding transaction located on the blockchain, is the starting point of their channel, enabling them to do off-chain transactions. However, to avoid the value of the channel being stuck in the funding transaction because one or both parties are uncooperative, as spending the output on-chain requires both signatures, a new transaction is created with both signatures, spending the output and refunding the value. This is done before the funding transaction is published, such that either party can close out the channel by publishing the refund transaction. The process of setting up a channel starts with the parties creating a funding transaction with a 2 of2 multisig output, but they will not exchange signatures for this transaction before they have created the refund transaction. The exchange of signatures is done in a specific order where first the refund transaction is signed by both sides, and only then are signatures exchanged for the funding transaction, and it is then published to the blockchain. The channel has now been established in a trustless manner,and it also allows for refunds initiated by either party by publishing the refund transaction and closing the channel.