ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-07 📝 Original message: Good morning list, This ...
📅 Original date posted:2018-11-07
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181107/f0969ef5/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181107/f0969ef5/attachment.html>;