... and I'm a little concerned. Of course I could be misunderstanding things,
but there are several references to soft forks being needed:
You appear to be referencing
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments by Joseph Poon and Thaddeus Dryja, which you did neither linked to nor precisely identified.
First, observe that the date on the first page is
January 14, 2016. When it speaks of required softforks, it speaks of the Segwit upgrade which occurred in the year 2017. According to my calendar, 2017 has already passed.
You also mashed together disparate pieces of text, without identifying which parts of the document you were copying. This makes it very hard to follow. I will provide pinpoint section and page references for readers.
Now, to address your specific questions:
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.
That is from Section 3, on page 7.
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.
That is from Section 3.1.2, on page 8.
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]
That is from Section 3.3, on page 13.
With systemic and potentially fatal errors if they are not implemented:
9.6 Inability to Make Necessary Soft-Forks
Your refer to the text starting at page 52.
The malleability fix was deployed as part of the Segwit upgrade. It has been active on the Bitcoin network since
24 August 2017. There cannot be an inability to make the necessary soft-fork, when the soft-fork is already done.
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?
You quote from Section 10, on page 53.
Zeroth of all, there is no longer a 1MB block size limit; indeed, there is no longer a block size limit at all. Since 24 August 2017, Bitcoin has instead had a
block weight limit of 4000000 bytes (4MB). It is expected that over time, average blocksizes will work out to a bit over 2MB.
First of all, you will observe that the text speaks of long-term planning. There is ongoing
Bitcoin hardfork research into how to safely fork the network if such a thing becomes required.
The text itself answers your specific question: Miners can refuse to build on consensus-valid blocks. It would be financially suicidal for any individual miner or pool to attempt enforcing such a policy: They would quickly wind up building their own minority chain, which would be rejected by nodes in favour of the chain with higher total POW. But if
all miners were to agree to build only on blocks smaller than the consensus hard limit, then they could do that.
N.b. that non-mining nodes dont produce new blocks, and the smaller blocks would be consensus-valid.
And, what is the status of these required soft forks?
As aforesaid, the required soft fork was done half a year ago. It is called
Segwit.
Editself-correction: As noted from achow101s post, I somehow zoned out on the checksequenceverify (CSV) softfork (BIPs 68, 112, 113). That was activated on the network on
4 July 2016.