What differences exist between the Lightning Network implementation versus the white paper?

Question

I'm reading the Lightning Network WP and came across SIGHASH_NOINPUT, then came across this: Lightning network: how was malleability actually fixed?

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

Answer 1

So far I found two further differences between the Whitepaper and the BOLT specifications:

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)

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)

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).

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>