One of the biggest risks of the lightning network is that core nodes and merchants must leave the private keys for their channels on online devices, they can airgap private keys for blockchain funds separately but it'd be difficult to do this with the lightning network.
Editor note: it's also not possible to partioally close a channel as far as I can tell meaning the user may have to trust a third party to try to transfer their funds out of a channel.
Timelock issues:
The initial party wanting to send funds must set a timelock themselves, if the timelock is too short they will be able to access their fudns before the transaction is complete meaning that the other party used in transferring the funds may have their funds stolen. This means speical attention must be given when writing the software to ensure noncompliant nodes don't meddle with other users funds and that the most recent state is able to be broadcast and accepted by the blockchain.
Forced expiration spam:
• This would occur by spamming the mempool with transactions higher in fee than the HTLC transaction in order to make it become invalid and allow the spammer to steal back their funds once a certain time has passed.
To mitigate thie risk it would be possible to use sequence number whereby a penalty must be published with an even sequence number and commitment transactions with an odd number. If the commitment transaction published has an odd number then the even numbered transactions would be easy to spot in the mempool.
Editor's note: this doesn't seem to suggest anything over mitigating the issue of sharing private keys after each commitment transaction as surely a user can just sign an odd commitment transaction (old one) and a new commitment transaction with a higher (and even) sequence number.... (but maybe I have this wrong). This would, however, work with only a slight tweek to the mempool validation since the next transaction could be compared to the first and if it credits the user that didn't publish the first one and they've already signed that commitment transaction in the past to acclaim it's their address then they could receive a reimbursement of their funds and the penalty.
• A recommended solution to reduce the amount of risk involved in this process is to send large amounts in multiple transactions since lightning network fees are pretty low. This would mean that each HTLC would have to be closed cooperatively or the user can only take a tiny amount of funds each time.
• If a spam attack happens on the blockchain, there is also a chance that the blocks can resize dynamically in order to fit certain lightning transactions from uncooperative channels.
Hacker theft:
• It is better that a node leave it's channels with little funds in them and the extra funds needed can be outsourced to other nodes or handled by people with more secure nodes.
• Nodes with a higher level of security (less prone to hacking or accidentally publishing keys somehow
) should be able to have more funds online and be able to partake in more transactions and potentially charge higher fess.
• There seems to be a mention of an idea to allow for a way to send outputs from a commitment transaction so a user is able to push their funds back onto the blockchain and storing them with airgapped keys (presumably the other party credits themselves in the commitment transaction and pushes funds out to the other person after that - or the channel is forclosed and instantly reopened after the hour for 6 confirmations).
Data loss:
This would mean a user would not be able to publish their most recent commitment transaction and dispute one if it gets published which can be resolved by having a third party store the channel data in an encrypted format they can't access (the user would still have to hold onto their seed nmemonic in order to regain access to their funds and claim the other party published an invalid/outdated Commitment).
Late broadcasts
A third party can charge a fee either before or after the service is provided whereby they will oversee the users' channels and check no outdated commitment transactions are being published. However, OP_CHECKSEQUENCEVERIFY may come in handy for this too to make it take a long enough time for the user to not notice before they lose their funds.
Miner collusion:
It is possible miners could be paid to not broadcast or mine a transaction.
For this not to occur it should be made harder for miner blocks to be identified as to where they have come from.
There is also a chance a miner could take a fee, identify all of their blocks as not mining the thief's coin and then mine a block that has a coinbase funding a different one of their addresses that they just don't prove belongs to them, meaning the thief has lost all of their funds and the fees paid to the miners and this may be enough of an inccentive for theives to not want to do this type of attack (as well as it being hard to arrange and successfully carry out).