<p>So far I found two further differences between the <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">Whitepaper</a> and the <a href="https://github.com/lightningnetwork/lightning-rfc" rel="nofollow noreferrer">BOLT specifications</a>:</p>

<h2>Funding</h2>

<p><strong>Whitepaper</strong>: One or both participants have to fund the channel (page 7)</p>

<p><strong>BOLT</strong>: Only one participant can fund the channel (<a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#channel-establishment" rel="nofollow noreferrer">BOLT #2 - Channel Establishment</a>)</p>

<h2>Penalty handling</h2>

<p>For a particular channel state, each participant has their own Commitment Transaction version which has two outputs: One for Alice and one for Bob. The output that is intended for oneself can only be spent after a delay. But the output for the other party can be spent immediately. For the sake of simplicity the following description considers just the view of one party who is Alice.</p>

<h3>Whitepaper</h3>

<p>Alice has her versions of the Commitment Transaction and Revocable Delivery Transaction. The output in the Commitment Transaction that is intended for Alice requires signatures from both parties and is referenced in the input of the Revocable Delivery Transaction. This input can only be spent after a delay which is specified by the sequence number (relative timelock via <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP 68</a>)</p>

<p><strong>Commitment TX 1 {Alice's version)</strong></p>

<pre><code> Out 0: 2-of-2 multisig (Pubkey_Alice_1, Pubkey_Bob_1)
 Out 1: Pubkey_Bob_2
</code></pre>

<p><strong>Revocable Delivery TX 1 (Alice's version)</strong></p>

<pre><code> In: sig_Alice_1, sig_Bob_1   // timelocked via BIP 68 (nSequence &lt; MAX_INT)
 Out: &lt;Pubkey_Alice_2&gt;
</code></pre>

<p>So Alice can (unilaterally) close the channel at anytime by broadcasting both of the above transactions. However, if she'd do that she'd have to wait for some time until she can actually spend the money from the Revocable Delivery Transaction.</p>

<p>Now, if both parties would like to update the channel state, they have to revoke their current commitment transactions. Alice revokes her Commitment Transaction by sending Bob her private key of her Commitment Transaction output. Now, if Alice tries to cheat by broadcasting her old Commitment Transaction and Revocable Delivery Transaction, she has to wait because she can only spend her money through her Revocable Delivery Transaction which is timelocked. However, as Bob now has both private keys for Alice's output of Commitment Transaction 1, he can immediately spend this output (and thereby invalidate Alice's Revocable Delivery Transaction) with the following transaction:</p>

<p><strong>Breach Remedy TX</strong></p>

<pre><code> In: sig_Alice_1, sig_Bob_1     
 Out: Pubkey_Bob_3
</code></pre>

<p>In short: Alice revokes her Commitment Transaction by giving Bob her private key. Also the time delay for Alice is implemented in a separate transaction via a BIP 68 timelock.</p>

<h3>BOLT</h3>

<p>Alice has only a Commitment Transaction. The output that is intended for Alice has two possible redemption paths. The first path requires the revocation private key and the second path requires Alice's private key and is delayed with a relative timelock using OP_CHECKSEQUENCEVERIFY (<a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow noreferrer">BIP 112</a>).</p>

<p><strong>Commitment TX 1 (Alice's version)</strong></p>

<pre><code> Out 0: IF
           &lt;Revocation_Pubkey&gt;   // first path
        ELSE
           &lt;time_delay&gt;          // second path
           &lt;Pubkey_Alice&gt;

 Out 1: &lt;Pubkey_Bob&gt;
</code></pre>

<p>When both parties proceed to the next channel state, they revoke their commitment transactions. Alice revokes her Commitment Transaction by sending her half of the revocation private key to Bob. So if Alice tries to cheat by broadcasting the old Commitment Transaction, Bob can broadcast a transaction that spends Alice's money through the first path as he now has the full revocation private key:</p>

<p><strong>Breach Remedy TX 1</strong></p>

<pre><code> In: &lt;Revocation_Privkey&gt;  
 Out: &lt;Pubkey_Bob&gt;
</code></pre>

CC BY-SA 4.0
2018-09-07T12:57:12.143Z
2018-09-07T12:57:12.143Z
Thomas Braunberger
<p>I'm reading the Lightning Network WP and came across <code>SIGHASH_NOINPUT</code>, then came across this: <a href="https://bitcoin.stackexchange.com/questions/63078/lightning-network-how-was-malleability-actually-fixed">Lightning network: how was malleability actually fixed?</a> </p>

<p>Are there any other design considerations in the White Paper that have changed in the actual implementation?</p>

CC BY-SA 4.0
2018-08-12T09:46:14.747Z
I guess the lightning rfc should be read if you are interested in implementation details in stead of the whitepaper. c.f: https://github.com/lightningnetwork/lightning-rfc
Rene Pickhardt
<segregated-witness><lightning-network>
What differences exist between the Lightning Network implementation versus the white paper?
kvnn
# What differences exist between the Lightning Network implementation versus the white paper?

(Asked by: username_0 on 2018-01-24)

I'm reading the Lightning Network WP and came across `SIGHASH_NOINPUT`, then came across this: [Lightning network: how was malleability actually fixed?](https://bitcoin.stackexchange.com/questions/63078/lightning-network-how-was-malleability-actually-fixed)

Are there any other design considerations in the White Paper that have changed in the actual implementation?

**Tags:** segregated-witness, lightning-network

> **Comments:**
> **username_1**: I guess the lightning rfc should be read if you are interested in implementation details in stead of the whitepaper. c.f: https://github.com/lightningnetwork/lightning-rfc  

---

## 1 answers

### Answer by username_2 on 2018-09-07. Score: 3

So far I found two further differences between the [Whitepaper](https://lightning.network/lightning-network-paper.pdf) and the [BOLT specifications](https://github.com/lightningnetwork/lightning-rfc):

## Funding

**Whitepaper**: One or both participants have to fund the channel (page 7)

**BOLT**: Only one participant can fund the channel ([BOLT #2 - Channel Establishment](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#channel-establishment))

## Penalty handling

For a particular channel state, each participant has their own Commitment Transaction version which has two outputs: One for Alice and one for Bob. The output that is intended for oneself can only be spent after a delay. But the output for the other party can be spent immediately. For the sake of simplicity the following description considers just the view of one party who is Alice.

### Whitepaper

Alice has her versions of the Commitment Transaction and Revocable Delivery Transaction. The output in the Commitment Transaction that is intended for Alice requires signatures from both parties and is referenced in the input of the Revocable Delivery Transaction. This input can only be spent after a delay which is specified by the sequence number (relative timelock via [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki))

**Commitment TX 1 {Alice's version)**

```
 Out 0: 2-of-2 multisig (Pubkey_Alice_1, Pubkey_Bob_1)
 Out 1: Pubkey_Bob_2

```

**Revocable Delivery TX 1 (Alice's version)**

```
 In: sig_Alice_1, sig_Bob_1   // timelocked via BIP 68 (nSequence < MAX_INT)
 Out: <Pubkey_Alice_2>

```

So Alice can (unilaterally) close the channel at anytime by broadcasting both of the above transactions. However, if she'd do that she'd have to wait for some time until she can actually spend the money from the Revocable Delivery Transaction.

Now, if both parties would like to update the channel state, they have to revoke their current commitment transactions. Alice revokes her Commitment Transaction by sending Bob her private key of her Commitment Transaction output. Now, if Alice tries to cheat by broadcasting her old Commitment Transaction and Revocable Delivery Transaction, she has to wait because she can only spend her money through her Revocable Delivery Transaction which is timelocked. However, as Bob now has both private keys for Alice's output of Commitment Transaction 1, he can immediately spend this output (and thereby invalidate Alice's Revocable Delivery Transaction) with the following transaction:

**Breach Remedy TX**

```
 In: sig_Alice_1, sig_Bob_1     
 Out: Pubkey_Bob_3

```

In short: Alice revokes her Commitment Transaction by giving Bob her private key. Also the time delay for Alice is implemented in a separate transaction via a BIP 68 timelock.

### BOLT

Alice has only a Commitment Transaction. The output that is intended for Alice has two possible redemption paths. The first path requires the revocation private key and the second path requires Alice's private key and is delayed with a relative timelock using OP\_CHECKSEQUENCEVERIFY ([BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)).

**Commitment TX 1 (Alice's version)**

```
 Out 0: IF
           <Revocation_Pubkey>   // first path
        ELSE
           <time_delay>          // second path
           <Pubkey_Alice>

 Out 1: <Pubkey_Bob>

```

When both parties proceed to the next channel state, they revoke their commitment transactions. Alice revokes her Commitment Transaction by sending her half of the revocation private key to Bob. So if Alice tries to cheat by broadcasting the old Commitment Transaction, Bob can broadcast a transaction that spends Alice's money through the first path as he now has the full revocation private key:

**Breach Remedy TX 1**

```
 In: <Revocation_Privkey>  
 Out: <Pubkey_Bob>

```


---

