Good morning list,
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.
Currently, every Lightning implementation has to have its own onchain wallet
implementation. This is because, the channel opening protocol requires a
specific order in which transactions are signed and broadcast. Specifically,
the funding transaction must be signed and broadcast *after* the first
commitment transaction pair is signed and exchanged.
However, SIGHASH_NOINPUT would allow Lightning implementations to be
"walletless". 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. Then when the transaction paying the funding
transaction output has been broadcast, succeeding commitment transactions may
be created without SIGHASH_NOINPUT.
I have discussed this before on bitcoin-dev:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.html
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. For instance, the onchain wallet
may have privacy features (integrated CoinSwap and CoinJoin, distinction
between traceable/cleaned coins, etc.). 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) specific
transaction outputs, not scan the blockchain for specific `scriptPubKey`.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
