This document is really what you need to read. It explains in details the proposal and how it does work. I will quote below some sentences from the above document. As far as I know, the balances are updated between cooperating parties (lets say Alice and Bob) in the channel. To broadcast, the channel can use a timelock. Also, when parties disagree, the last agreed transaction is broadcasted. Close a channel means broadcast the channel balance/last transaction. I suggest you to read the paper though...

"Instead, both parties can commit to signing a transaction and not broadcasting this transaction. So if Alice and Bob commit funds into a 2-of-2 multisignature address (where it requires consent from both parties to create spends), they can agree on the current balance state [...] This refund is not broadcast on the blockchain." page 5

"In the case of micropayment channels, only two states are required: the current correct balance, and any old deprecated balances." page 5

"This invalidation process can exist through a process of channel consensus where if both parties agree on current ledger states (and building new states), then the real balance gets updated. The balance is reflected on the blockchain only when a single party disagrees." page 6

"By encumbering the Bitcoin transaction outputs with a hashlock and timelock, the channel counterparty will be unable to outright steal funds and Bitcoins can be exchanged without outright counterparty theft. Further, by using staggered timeouts, it’s possible to send funds via multiple intermediaries in a network without the risk of intermediary theft of funds." page 6

"Both parties can update the balance inside the channel with whatever output balances they wish, so long as it’s equal or less than the total funds committed inside the Funding Transaction; balances can move in both directions." page 29

Maybe there would be a reason to keep invalid transactions to prove they took place? If a pair of commercial partners has a dispute over whether or not a payment took place, records may be desirable in order to prove what happened (I guess this is highlighting a weakness of Lightning; no such problem can be exploited when transacting on-chain).

The current state proves it all. It takes both parties to agree on it. If you agree that the balance between the two is as said in the current state, then other older transactions aren't important.

The "books" would be the commitment transactions and their corresponding revoke_and_ack messages. The commitment transactions are signed by both parties, so you can prove that the balance for each transaction was agreed upon by both parties. The "books" cannot add transactions, only omit them. To prove that no transactions presented were omitted, you can use the per-commitment secrets and next per-commitment points in the revoke_and_ack messages to show which message corresponds to which transaction. If there is a revoke_and_ack message that has a next per-commitment point that is not used in any of the commitment transactions, then you know that at least one transaction was omitted.

so ok, and if you wanted to post this book, for all to see, then you could and have some sort of explorer to pull out information. So say a highly connected and liquid channel may choose to publish its book and so provide a means to inspect records much like full node. Also thanks for the info.

Interesting point. It seems like you would indeed need to find a way to regularly backup your channel state. However your counterparty doesn't know that you're not able to react to them broadcasting an older transaction, so the attack remains risky. Additionally, pretending to have lost the channel state (in whichever way you would go on about that) could actually be a profitable way to trick would-be attackers.

You might not want to know this information, but the regulating authorities might differ from you. The way Bitcoin is currently regulated in most countries, third party service providers has to adhere to KYC/AML regulations to track all transactions linked to individuals. If the LN can be used to hide micro transactions, it would not adhere to these regulations and you will find that governments will push for the Ban of these technologies, based on anonymity issues.

They tolerate Bitcoin users now, because they still adhere to the KYC/AML regulations, when they use these services.

I predict huge numbers of Lightning channels opening in countries with good-enough internet infrastructure and low adherence to KYC/AML