... and I'm a little concerned. Of course I could be misunderstanding things,
but there are several references to soft forks being needed:
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.
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.
With systemic and potentially fatal errors if they are not implemented:
9.6 Inability to Make Necessary Soft-Forks
Changes are necessary to bitcoin, such as the malleability soft-fork. Addi-
tionally, if this system becomes popular, it will be necessary for the system
to securely transact with many users and some kind of structure like a
blockheight timestop will be desirable. This system assumes such changes
to enable Lightning Network to exist entirely, as well as soft-forks ensuring
the security is robust against attackers will occur. While the system may
continue to operate with only some time lock and malleability soft-forks,
there will be necessary soft-forks regarding systemic risks. Without proper
community foresight, an inability to establish a timestop or similar func-
tion will allow systemic attacks to take place and may not be recognized as
imperative until an attack actually occurs.
And then it goes on to say that the block size will need to be increased anyway!
10 Block Size Increases and Consensus
If we presume that a decentralized payment network exists and one user will
make 3 blockchain transactions per year on average, Bitcoin will be able
52
to support over 35 million users with 1MB blocks in ideal circumstances
(assuming 2000 transactions/MB, or 500 bytes/Tx). This is quite limited,
and an increase of the block size may be necessary to support everyone in
the world using Bitcoin. A simple increase of the block size would be a hard
fork, meaning all nodes will need to update their wallets if they wish to
participate in the network with the larger blocks.
While it may appear as though this system will mitigate the block size
increases in the short term, if it achieves global scale, it will necessitate a
block size increase in the long term. Creating a credible tool to help prevent
blockchain spam designed to encourage transactions to timeout becomes
imperative.
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?
And, what is the status of these required soft forks?