So I just read the LN white paper...

[Predatron]

... 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 Network’s 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?

[achow101]

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

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

However,  Lightning Network’s 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.

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.

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.

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.

[Predatron]

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

Perfect thanks for clarifying that!

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.

Right, but in the example they were talking about block sizes over 1MB, which as I understand it is a hard limit.

Also, is there anything to stop everyone from connecting to just one "master-node" on the network, thus making all transactions just one hop to anyone else? I presume this master-node would need enough BTC to handle the liquidity of everyone, but that is theoretically possible.

[nullius]

... 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 Network’s 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

<snip>

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 don’t 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.

Edit—self-correction:  As noted from achow101’s post, I somehow zoned out on the checksequenceverify (CSV) softfork (BIPs 68, 112, 113).  That was activated on the network on 4 July 2016.

[BenOnceAgain]

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

Do you know if there's a more recent version of the Lightning Network white paper?  The latest I've found is version 0.5.9.2 dated January 14, 2016.

Thanks,
Ben

[achow101]

Right, but in the example they were talking about block sizes over 1MB, which as I understand it is a hard limit.

The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through.

Also, is there anything to stop everyone from connecting to just one "master-node" on the network, thus making all transactions just one hop to anyone else? I presume this master-node would need enough BTC to handle the liquidity of everyone, but that is theoretically possible.

No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with.

Do you know if there's a more recent version of the Lightning Network white paper?  The latest I've found is version 0.5.9.2 dated January 14, 2016.

There are not versions of the paper itself, but there is a much more detailed specification of the lightning network available here: https://github.com/lightningnetwork/lightning-rfc/.That specification is what implementors are using to actually implement software for the Lightning Network.

[Predatron]

According to my calendar, 2017 has already passed.

Gee thanks, hadn't noticed.

The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through.

Ah ok I see, thanks.

No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with.

Except for the cost of opening a new channel (which shouldn't be more than a couple dollars I think). Right? Just saying it seems like even a small fee would deter people from opening many p2p connections when you can just have one open that serves all your needs with minimal fees. Obviously LN is going to need one more layer on top as an end-user GUI/app that makes this simple so grandma can use it, just trying to visualize that.

Do you know if there's a more recent version of the Lightning Network white paper?  The latest I've found is version 0.5.9.2 dated January 14, 2016.

Thanks for asking that, was going to myself as well. Here is the link that works to the latest protocol from achow101: https://github.com/lightningnetwork/lightning-rfc/

-----

Edit: quote attribution

[nullius]

According to my calendar, 2017 has already passed.

Gee thanks, hadn't noticed.

Sorry, I think I overreacted here.  From your further posts, it seems your questions have been sincere.  I should explain.

There is a steady stream of posts, often from new accounts, which desperately try to find something, anything wrong with Lightning.  I sometimes see excellent posters waste hours and an ocean of virtual ink trying to keep up with frivolous arguments.  And while there’s nothing wrong with a new account, insofar as all start that way, that gives no post history for me to check and see if you be that type.

Thus you may understand my reflexive irritation at apparent fear, uncertainty, and doubt expressed over the urgent need for softforks which were already done.  The task of pulling up the page numbers so that other readers could find context for a mish-mash of disparate quotes did not help matters.

There is a very competitive market, with a hefty dose of politics involved.  There are many people with an axe to grind against Bitcoin.  Lightning Network is a brilliant new system with a promising future—Bitcoin’s future.  I think you can see where many of us who simply want to enjoy this new technology may oft be a bit on the defensive.

No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with.

Except for the cost of opening a new channel (which shouldn't be more than a couple dollars I think). Right? Just saying it seems like even a small fee would deter people from opening many p2p connections when you can just have one open that serves all your needs with minimal fees.

I myself tend to expect that the connectedness of nodes will roughly follow something like a Gaussian (bell-shaped) distribution.  Those connected to only one node would be at one extreme; nodes connected to a very large number of others would be at the other; and most would lie somewhere in the middle.  But that, as all else said on this topic, is a matter of more or less well-informed speculation.  I think we will really need to wait and see how the network grows.

Obviously LN is going to need one more layer on top as an end-user GUI/app that makes this simple so grandma can use it, just trying to visualize that.

It’s not a matter of layers.  From what I understand, there are existing userfriendly implementations which seem not so different than userfriendly GUI Bitcoin wallets; though I am not familiar with them as I should be.  Anyway, I’ve seen screenshots which looked simple and slick.  Time for me to catch up with what’s happening there!

[Anti-Cen]

The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through.

This is a major problem for Bitcoin because like i keep saying the development team are working
for the wrong masters and by allowing the miners to ramp fees up to $55 and doing nothing it may
have been a fatal wound to Bitcoin and the price has been going down ever since.

We have 20,000 miner so the ones that don't like the changes can leave and allow the remaining
miners to share around whats left and earn a honest wage.

[nullius]

Thus you may understand my reflexive irritation at apparent fear, uncertainty, and doubt...

There are many people with an axe to grind against Bitcoin.

With apologies for the ridiculous noise, I believe this incidentally demonstrates my point:

This is a major problem for Bitcoin because like i keep saying the development team are working
for the wrong masters and by allowing the miners to ramp fees up to $55 and doing nothing it may
have been a fatal wound to Bitcoin and the price has been going down ever since.

We have 20,000 miner so the ones that don't like the changes can leave and allow the remaining
miners to share around whats left and earn a honest wage.

To avoid derailing the thread over a known troll, I will avoid taking that any further.

[racebum]

According to my calendar, 2017 has already passed.

Gee thanks, hadn't noticed.

Sorry, I think I overreacted here.  From your further posts, it seems your questions have been sincere.  I should explain.

There is a steady stream of posts, often from new accounts, which desperately try to find something, anything wrong with Lightning.  I sometimes see excellent posters waste hours and an ocean of virtual ink trying to keep up with frivolous arguments.  And while there’s nothing wrong with a new account, insofar as all start that way, that gives no post history for me to check and see if you be that type.

i'm reasonably new to crypto but a seasoned securities trader. it took me roughly two weeks to realize this. seems like there is a LOT of hype/marketing from sockpuppet accounts, fake articles, just a hype train often in the name of market manipulation. team evil with bcash is one that definitely comes to mind

has it always been like this or is it a fairly recent development with all the alt coins we now have, many with pumpNdump strats in place?

[nullius]

i'm reasonably new to crypto but a seasoned securities trader. it took me roughly two weeks to realize this. seems like there is a LOT of hype/marketing from sockpuppet accounts, fake articles, just a hype train often in the name of market manipulation. team evil with bcash is one that definitely comes to mind

has it always been like this or is it a fairly recent development with all the alt coins we now have, many with pumpNdump strats in place?

Good question; but it’s off-topic in this thread and in this forum, so I transplanted my answer here:  Fork wars are déjà vu.  Please direct all further discussion of this question to that thread.