@ -52,10 +52,81 @@ The revocation secrete is necessary to economically disincentivice peers to publ
Addresses and revokation secretes change with every new pair of commitment transactions that are being negotiated.
The Lightning Network as a protocol defines the communication protocols that are necessary to achieve this.
### Security of a Payment channel
While the BOLTs introduce payment channels directly with the opening protocol we have decided to talk about the security model first.
The security of payment channels come through a penalty based revocation system which help two parties to split the capacity of the payment channel into a balance sheet without the necessity to trust each other.
In this chapter we start from an insecure approach of creating a payment channel and explain why it is insecure.
We will then explain how time locks are being used to create revokable sequence maturity contracts that create the penality based revokation system which economically incentivizes people maintain the most recent state.
After you understood these concepts we will quickly walk you through the technical details of opening and closing a channel.
Any known payment channel constuction uses a 2 - of - 2 multisgnature output as the basis of the payment channel.
We call the amount that is attached to this output the capacity of the channel.
In every case Both channel partners hold 1 secret key of the multisignature address which means that they can only collaboratively controll the funds.
#### An example for a highly insecure payment channel construction
Let us assume Alice does not know the details about the Lightning Network and tries to naivly open a payment channel in a way that leads to her most likely loosing her funds.
Alice has heard that Payment channel are 2 - of - 2 multisnature outputs.
As she wants to have a channel with Bob and since she knows a public key from Bob she decides to open a channel by sending money to a 2 - of - 2 multisignature address that comes from Bob's and her key.
We call the Transaction that Alices used a **funding transaction** as it is supposed to fund the payment channel.
However signing and broadcasting this funding transaction would be a huge mistake.
As we have discussed the Bitcoins from the resulting UTXO can only be spent if Alice and Bob work together and both provide a signature for a transaction spending thos coins.
If Bob would not respond to Alice in future Alice would have lost her Bitcoins forever.
That is because the coins would be stuck in the 2 - of - 2 multisignature address to which she has just sent them.
Luckily Alice has previously read Mastering Bitcoin and she knows all the properties of Bitcoin script and is aware of the risks that are involved to sending Bitcoins to a 2 - of - 2 multisignature address to which she does not controll both keys.
She is also aware of the "Don't trust. Verify" principle that Bitcoiners follow and doesn't want to trust Bob to help her moving or accessing her coins.
She would much more prefere to keep control over her coins even though they shall be stored in this 2 - of - 2 multisnature address.
While this seems like an impossible problem Alice has an idea:
What if she could already prepare a refund transaction (which we call commitment transaction in future) that sends all the bitcoin back to an address that she controlls?
Before broadcasting her funding transaction she already prepares and finnishes it so that she knows the transaction id.
She can now create the commitment transaction that spends the output of the funding transaction and ask Bob to provide a signature.
At that time Bob has nothing to loose by signing the commitment transaction.
He did not have Coins at the multisig address anyway.
Even if he did Alice intends to spend from an output which Bob never was involved in.
Thus at that point for Bob it is perfectly reasonable to sign the commitment transaction that spends the funding transaction.
On the other side you as a reader might think:
Why would Alice send money to a multisignature address just to prepare a transaction that sends the money back to her?
We really hope you have wondered about this because this is really the point where the innovation begins.
Just because in general people are expected to broadcast a transaction to the bitcoin network as soon as they have signed it noone forcses you to do that.
Instead of braodcasting the commitment transaction together with the funding transaction she will send out the funding transaction and keep the commitment transaction at a save place.
TODO: talk about segwit here?
[NOTE]
====
This entire process might be surprising (... comparison with HTTP server push and AJAX...)
====
So the main question is:
What can go wrong with the insecure payment channel?
As Alice would loose access of her Bitcoins once she sends it to a 2 - of - 2 multisignature output for which she only controlls one key she needs to make sure that she will be able to regain access of her coins in case Bob becomes unresponisive.
Thus before Alice publishes the funding transaction she will create another transaction that sends all the bitcoin from the 2 - of - 2 multisignature output back to an address which she controlls.
.The situation can be seen in the following picture
image:channel-construction-opening-1.png[]
Of course for the commitment transaction Alice would need to get a Signature from Bob
[NOTE]
====
Commitment transactions fulfill three purposes:
1. refund channel participants in case the other side becomes irresponsive
2. Splite the capacity of the channel into the current balance that peers have agreed upon.
3. Allow revocation of old state through the means of a penality via a revocable sequence maturity contract.
====
### Opening a payment channel
We call the process of creating a new payment channel "opening a payment channel".
Currently a payment channel can only exists between exactly two peers.
Therefor you might be surprised to learn that even though two users are owning and maintaining the channel the current construction requires only one user to open the channel.
Therefore you might be surprised to learn that even though two users are owning and maintaining the channel the current construction requires only one user to open the channel.
This does not mean that only one peer is needed to open a channel.
It does however mean that the user who opens the channel also has to provide the bitcoins to fund the channel.
@ -64,6 +135,7 @@ This means that Alice provides 100k satoshi.
Alice will do that by creating a so called funding transaction.
This transaction sends 100k satoshi from an address that she - or her lightning node software controlls - to a 2 - of - 2 multisig address for which she and Bob know 1 secret key each.
The amount of Bitcoin that is sent to the multisig output by Alice is called the capacity of the payment channel.
Thus for the reminder of the chapter in all examples we assume the payment channels that we use as examples already magically exist and the two peers Alice and Bob already have all the necessary data at hand.
[NOTE]
====
@ -77,20 +149,6 @@ Thus Bob can't steel the coins from Alice directly but he can threten Alice to h
This example shows that unfortunatelly opening a channel will be a little bit more complex than just sending Bitcoins to a multisignature address.
====
As Alice would loose access of her Bitcoins once she sends it to a 2 - of - 2 multisignature output for which she only controlls one key she needs to make sure that she will be able to regain access of her coins in case Bob becomes unresponisive.
Thus before Alice publishes the funding transaction she will create another transaction that sends all the bitcoin from the 2 - of - 2 multisignature output back to an address which she controlls.
.The situation can be seen in the following picture
image:channel-construction-opening-1.png[]
Of course for the commitment transaction Alice would need to get a Signature from Bob
[NOTE]
====
Commitment transactions fulfill three purposes:
1. refund channel participants in case the other side becomes irresponsive
2. Splite the capacity of the channel into the current balance that peers have agreed upon.
3. Allow revocation of old state through the means of a penality via a revocable sequence maturity contract.
Rene Pickhardt
4 years ago