Quote from: Predatron on February 03, 2018, 11:59:43 PM

... and I'm a little concerned. Of course I could be misunderstanding things,
but there are several references to soft forks being needed:

A lot has changed with LN's design since the paper was published.

Quote from: Predatron on February 03, 2018, 11:59:43 PM

And, what is the status of these required soft forks?

Quote from: Predatron on February 03, 2018, 11:59:43 PM

However, Lightning Networks bidirectional micropayment channel requires
the malleability soft-fork described in Appendix A to enable near-infinite scalability
while mitigating risks of intermediate node default.

The Lightning Network uses a SIGHASH_NOINPUT transaction to
spend from this 2-of-2 Funding Transaction output, as it is necessary to
spend from a transaction for which the signatures are not yet exchanged.
SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions
can be spent from before it is signed by all parties, as transactions would
need to be signed to get a transaction ID without new sighash flags.

Transaction malleability has been resolved with segwit which has activated on Bitcoin.

Quote from: Predatron on February 03, 2018, 11:59:43 PM

Mark Freidenbach has proposed that Sequence Numbers can be en-
forcible via a relative block maturity of the parent transaction via a
soft-fork[12]. This would allow some basic ability to ensure some form
of relative block confirmation time lock on the spending script.[/i][/b]

Relative lock times have been soft forked into Bitcoin with OP_CHECKSEQUENCEVERIFY.

These are the only two soft forks that are necessary for LN to work on Bitcoin, and both have activated.

Quote from: Predatron on February 03, 2018, 11:59:43 PM

And then it goes on to say that the block size will need to be increased anyway!

It will, or perhaps there will be more improvements which shrink the size of transactions. LN is not the end all be all solution for Bitcoin transaction capacity, but it certainly will provide a huge boost.

Quote from: Predatron on February 03, 2018, 11:59:43 PM

And the solution to this makes no sense to me:

To mitigate timelock spam vulnerabilities, non-miner and miners con-
sensus rules may also differ if the miners consensus rules are more restrictive.
Non-miners may accept blocks over 1MB, while miners may have different
soft-caps on block sizes. If a block size is above that cap, then that is viewed
as an invalid block by other miners, but not by non-miners. The miners will
only build the chain on blocks which are valid according to the agreed-upon
soft-cap. This permits miners to agree on raising the block size limit with-
out requiring frequent hard-forks from clients, so long as the amount raised
by miners does not go over the clients hard limit. This mitigates the risk
of mass expiry of transactions at once. All transactions which are not re-
deemed via Exercise Settlement (ES) may have a very high fee attached, and
miners may use a consensus rule whereby those transactions are exempted
from the soft-cap, making it very likely the correct transactions will enter
the blockchain.

So my question is, how can you accept blocks that are not accepted by the miners?

What they are describing is the soft limit on block sizes. It is not invalid to create a block that is less than say, 500 kB. However the miners may collude and decide that they won't mine any blocks larger than 500 kB. This does not break consensus rules and all non-mining full node will still accept blocks larger than 500 kB. Just the miners won't produce a block larger than 500 kB and if they see one, they will reject it thus it won't go into the blockchain. This is effectively a miner enforced soft fork.