# Evaluating Methods for the Identification of Off-Chain Transactions in the Lightning Network
## 2 Background
### Segregated Witness  
Segregated Witness (segwit) is a change introduced to the Bitcoin consensus layer defined in Bitcoin Improvement Proposals (BIPs), BIP141 and BIP143 [10; 11]. Segwit changes the structure of the validating data used to verify transactions and where this data is stored. Transactions outputs have a locking script and an unlocking script; the witness is the unlocking script, which enables us to check the validity of the output spent by using it with the locking script. Segwit places the witness or unlocking script in a witness data structure which is no longer stored inside the transaction. One of the main reasons this is done is to fix transaction malleability, which is the ability to change the transaction id of a transaction. This id is a hash of all the properties of a transaction including the unlocking script/witness. The only malleable part of a transaction is the unlocking script because a transaction is unique, and outputs can only be spent once--i.e., if the choice of inputs, choice of outputs, or the value changes, it is no longer the same transaction. Therefore, when the transaction has been created most of it is non-malleable. However, the unlocking script can be modified in different ways without invalidating the transaction core elements. Adding operations to the unlocking scripts or zero padding the numbers used can achieve this effect, and thus change the id, while the transaction is for all intents and purposes the same [12]. With segwit, the transaction hash will be calculated without the witness data, and therefore this removes possibilities for malleability. As the witness data is only used to validate the transaction itself, it is not necessary to determine the state of the blockchain and can, therefore, become optional for lightweight nodes wishing to save bandwidth.  
A segwit transaction output is constructed such that a non-segwit enabled node will interpret the output as being spendable by everyone--i.e., redeemable by an empty signature; this means a non-segwit node cannot correctly validate a segwit transaction but will not consider it invalid [8].  
Segwit has two standard transaction types that mirror the functionality of the existing ones: pay to witness public key hash (P2 WPKH), and pay to witness script hash (P2 WSH). The main change is how the locking scripts in the outputs are structured; instead of including the script in the output, there is only a version byte with the value 0 to 16 followed by 20 bytes containing a public key hash, or 32 bytes containing a script hash. The amount of bytes fund after the version byte allows us to determine if the output is a P2 WPKH or P2 WSH. Currently, only version 0 is used, with the rest reserved for future versions [10]. An example of a P2 WPKH locking script is:  
0 <20 byte public key hash>The unlocking script is found in the witness structure which is a stack containing the required data to validate the transaction. In the case of the P2 WPKH the witness stack will contain two elements: the <signature> and the <public key> which is required to validate the transaction. The mechanism is exactly the same as in the old P2 PKH transaction type. In the case of the P2 WSH type, the witness stack can contain a varying number of items depending on the requirements of the redeem script. If the redeem script is a multisig script the stack will contain the required amount of signatures, with the last item of the stack always being the redeem script itself.