# Evaluating Methods for the Identification of Off-Chain Transactions in the Lightning Network
## 2 Background
### Payment Channels in the Lightning Network
[PERSON] signs one and sends it to [PERSON], and [PERSON] signs one and sends it to [PERSON]. This means both sides end up with a half-signed transaction which only needs their own signature before it is valid and can be published to the blockchain. The multi-signature requirement means that each of them can only publish the one they received from the other party (the one already signed by the other participant). If [PERSON] is the one who published a commitment transaction we can find out because he must publish one of those he received from [PERSON] containing her signature. As each side receives their version of the commitment transactions from the opposing party, the opposing party can create an insurance clause on the output to the party receiving the commitment. This means that when [PERSON] signs a commitment transaction for sending to [PERSON], he can place an insurance clause on the output for [PERSON], punishing her if the commitment is published when it is outdated. This means that the commitment transactions for the two parties are not exactly the same, because they will contain this insurance mechanism, but the transaction pair will still have the same balance, spending the same outputs and have the same outputs. The need to wait for confirmations to spend the output is enforced on every set of created commitment transactions. It provides time to enforce a punishment, that is, it allows the other party to spend the output before the timelock expires. However, the punishment only applies to old commitment transactions, so the punishment is only made possible when a commitment transaction pair is invalidated by creating a new one. The invalidation or revocation of old commitment transactions is done by creating a Breach Remedy transaction which spends the same output as the timelocked/RSMC output. Each of the parties sign this transaction spending the timelocked/RSMC output of their own commitment transaction, and then gives it to the other party to revoke it. This enables both of the parties to spend the timelocked output belonging to the other party if they should publish a revoked commitment transaction--e.g., [PERSON] creates a Breach Remedy transaction spending her output in the old commitment transaction and sends it to [PERSON], and he does the same; if either of the two parties now publishes an old commitment transaction, they cannot spend their output immediately because of the RSMC/timelock, but the other party can publish the Breach Remedy transaction, and spend their own output and thus get all funds in the channel. However, spending the timelocked output should be done before the timelock expires as the party which published the old commitment can now also spend that output. Both parties should, therefore, observe the blockchain so they can see if an old commitment transaction is published, allowing them to use the Breach Remedy transaction before the timelock expires. The channel can also be cooperatively closed if both parties agree to do so. The parties must simply create a new transaction spending the funding transaction with the outputs reflecting the balance in the latest commitment. They exchange signatures and it can be published on the blockchain. The outputs of this transaction will not have any time-locks, so each party will be able to claim their funds when they wish. This is because they both must agree to close a channel this way, if they cannot agree, one party can simply publish their newest commitment transaction and close the channel that way, but they will need to wait for the timelock to release the funds. Closing a channel cooperatively means that the total number of transactions published to the blockchain will be exactly 2: one funding and one closing transaction. This is the simplest and the most common case. Otherwise, the extra timelocked (or potential Breach Remedy) transactions will be recorded in the blockchain.