<div>Good morning list,<br></div><div><br></div><div>This topic is out of scope for the Lightning Development Summit 2018 as it requires SIGHASH_NOINPUT, but I thought it might be something to bring up to consider if it would be useful in the future.<br></div><div><br></div><div>Currently, every Lightning implementation has to have its own onchain wallet implementation.&nbsp; This is because, the channel opening protocol requires a specific order in which transactions are signed and broadcast.&nbsp; Specifically, the funding transaction must be signed and broadcast *after* the first commitment transaction pair is signed and exchanged.<br></div><div><br></div><div>However, SIGHASH_NOINPUT would allow Lightning implementations to be "walletless".&nbsp; What happens is that the first pair of commitment transactions will have to be signed with SIGHASH_NOINPUT, then the funding transaction can be created using a normal wallet.&nbsp; Then when the transaction paying the funding transaction output has been broadcast, succeeding commitment transactions may be created without SIGHASH_NOINPUT.<br></div><div><br></div><div>I have discussed this before on bitcoin-dev: <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.html</a><br></div><div><br></div><div>The primary use case is to reduce the number of transactions needed when the user prefers to use a specific wallet implementation that may have features unavailable to the Lightning implementation.&nbsp; For instance, the onchain wallet may have privacy features (integrated CoinSwap and CoinJoin, distinction between traceable/cleaned coins, etc.).&nbsp; A secondary use case would be to reduce implementation complexity for Lightning implementations, as there would only be needed to trace status (unconfirmed/confirmed, spent/unspent)&nbsp; specific transaction outputs, not scan the blockchain for specific `scriptPubKey`.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>