Walletless channel opens [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2018-11-12T00:39:56+00:00


Summary:

In an email exchange between David A. Harding and ZmnSCPxj on November 7, 2018, they discussed the idea of Lightning implementations being "walletless". ZmnSCPxj suggested that using SIGHASH_NOINPUT could enable this, but David A. Harding pointed out that without a wallet, committing to transaction fees for delayed-broadcast transactions would be necessary. This is because additional fees cannot be added through RBF (Replace By Fee) without a wallet. They both agreed that better integration of onchain wallets with protocols that delay between signing and broadcast should be considered instead.On the Lightning-dev mailing list, a user brought up the idea of SIGHASH_NOINPUT allowing for walletless Lightning implementations. However, another user highlighted the issue of having to commit to transaction fees for delayed-broadcast transactions like the Eltoo trigger transaction. Without a wallet, it would not be possible to add additional inputs through RBF, potentially leading to high fees for channels that may be open for extended periods but need to be closed quickly to prevent fraud.Although the Lightning Development Summit 2018 will not be discussing SIGHASH_NOINPUT as it falls outside the scope of the event, it remains an interesting topic for future consideration. Currently, each Lightning implementation requires its own onchain wallet implementation due to the specific order in which transactions are signed and broadcast during the channel opening protocol. However, by utilizing SIGHASH_NOINPUT, Lightning implementations could become "walletless". The first pair of commitment transactions would be signed with SIGHASH_NOINPUT, while the funding transaction could be created using a normal wallet. This approach would reduce the number of transactions required, especially for users who prefer to use a specific wallet implementation with features unavailable to the Lightning implementation. Additionally, it would simplify the implementation process for Lightning implementations.


Updated on: 2023-07-31T20:39:55.102647+00:00