In what way? The way that inputs and outputs work are still exactly the same.

Reference : https://bitcoincore.org/en/2016/01/26/segwit-benefits/

How so? An LN Node doesn't need to be a full Bitcoin node already. They can work fine as SPV wallets now and after Segwit. Segwit does not change that at all.

Reference: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
The Lightning Network: with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.

What requires a Lightning client to be a full node? As I understand it, it doesn't matter, and segwit does not change that.

Yo Dum Dum , same answer as above.  
Reference: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
The Lightning Network: with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.

I don't think you understand how LN works. LN does not issue IOUs. It creates very real, valid, and broadcastable Bitcoin transactions. There are no IOUs involved.

Do you not understand the Word OFFCHAIN , BTC is only Locked on the ONLINE BLOCKCHAIN, it is not and can not be moved onto LN's network,
So you are trading BTC IOUs when you use LN.

Not necessarily. LN is not for every type of transaction. It is really only good for small, repeated transactions like faucet payments.

LN will cost the Miners money , that is why less than 30% have been dumb enough to agree to it.

Now that is just FUD. How would LN only allow certain miners to confirm those transactions? That is just completely false.

One of the Concerns in the LN Network Whitepaper is that ,
Miners may Decline Certain LN transactions so their Locks timeout and the BTC can be Stolen.
If the above is possible, the reverse is also possible which makes what I said a Valid Theory.

---

You are demonstrating and extreme lack of knowledge on subjects you are arguing against. I highly suggest that you actually do some research before posting.

Please stop spreading FUD.

9    Risks
The primary risks relate to timelock expiration.  Additionally, for core nodes
and possibly some merchants to be able to route funds, the keys must be
held online for lower latency.  However, end-users and nodes are able to keep
their private keys  rewalled o  in cold storage.
9.1    Improper Timelocks
Participants must choose timelocks with suffcient amounts of time.
If insuffcient time is given, it is possible that timelocked transactions believed to
be invalid will become valid, enabling coin theft by the counterparty.
There is a trade-off  between longer timelocks and the time-value of money.
When writing wallet and Lightning Network application software, it is necessary
to ensure that suffcient time is given and users are able to have their trans-actions
enter into the blockchain when interacting with non-cooperative or malicious channel counterparties.

9.2    Forced Expiration Spam
Forced expiration of many transactions may be the greatest systemic risk when using the Lightning Network.  
If a malicious participant creates many channels and forces them all to expire at once, these may overwhelm block data capacity,
forcing expiration and broadcast to the blockchain.  The re-sult  would  be  mass  spam  on  the  bitcoin  network.  
The  spam  may  delay transactions to the point where other locktimed transactions become valid.
This may be mitigated by permitting one transaction replacement on
all  pending  transactions.   Anti-spam  can  be  used  by  permitting  only  one
transaction replacement of a higher sequence number by the inverse of an
even or odd number.  For example, if an odd sequence number was broad-
cast, permit a replacement to a higher even number only once.  Transactions
would use the sequence number in an orderly way to replace other trans-
actions.   This  mitigates  the  risk  assuming  honest  miners.
This attack  is extremely  high  risk,  as  incorrect  broadcast  of  Commitment  Transactions entail a full penalty of all funds in the channel.
Additionally,
one may attempt to steal HTLC transactions by forcing a timeout transaction to go through when it should not.
This can be easily mitigated by having each transfer inside the channel be lower than the total
transaction fees used.  Since transactions are extremely cheap and do not
hit the blockchain with cooperative channel counterparties, large transfers
of value can be split into many small transfers.  This attempt can only work
if  the  blocks  are  completely  full  for  a  long  time.   While  it  is  possible  to
mitigate it using a longer HTLC timeout duration, variable block sizes may
become common, which may need mitigations.
If this type of transaction becomes the dominant form of transactions which are included on the blockchain,
it may become necessary to increase the  block  size  and  run  a  variable  blocksize  structure  and  timestop   ags as described in the section below.
This can create suffcient penalties and
disincentives  to  be  highly  unpro table  and  unsuccessful  for  attackers,  as
attackers lose all their funds from broadcasting the wrong transaction,  to
the point where it will never occur.

9.4    Data Loss
When one party loses data, it is possible for the counterparty to steal funds.
This can be mitigated by having a third party data storage service where
encrypted data gets sent to this third party service which the party cannot
decrypt.   Additionally,  one  should  choose  channel  counterparties  who  are
responsible  and  willing  to  provide  the  current  state,  with  some  periodic
tests of honesty.
9.5    Forgetting to Broadcast the Transaction in Time
If one does not broadcast a transaction at the correct time, the counterparty may steal funds.
This can be mitigated by having a designated third party
to send funds.  An output fee can be added to create an incentive for this
third party to watch the network.  Further,  this can also be mitigated by
implementing OP CHECKSEQUENCEVERIFY