There are two major issues when it comes to the adoption of payment channels in Bitcoin. Firstly, we have an interoperability issue, where the implementation of payment channels in one wallet may not necessarily be compatible with the implementation of payment channels in another wallet. Even if interoperability is resolved, there is still an issue with security, how do we safely communicate the parameters required to setup the payment channels between two independent wallets in a trust-less manner?
Secondly, a Jeremy Spillman style payment channel involving one consumer and one producer is still vulnerable to transaction malleability depending on how patient our hypothetical wallet user is. If the usual 6 block confirmation recommendation is adopted, there is a low chance that transaction malleability may affect the service provider of the payment channel. However, if the service provider starts providing services by accepting an unconfirmed commitment transaction to fund the payment channel, the transaction malleability exploit can be used to invalidate all subsequent payment transactions as the consumer of the service can simply mutate her sigScript for the commitment transaction, resulting in a different transaction hash. However, this is only achievable when there’s a fork in the blockchain and the mutated transaction has been committed in the winning chain or when the commitment transaction is unconfirmed and the mutated transaction was committed instead of the original transaction.