Feb 13 - Feb 13, 2024
This presents a notable shift in strategy and introduces several complexities. One significant challenge with the proposed method is the inability of the wallet to operate in the background without active monitoring by the user. This limitation is critical as most payments typically occur when the app is not actively open but is instead activated in the background by the LSP. This functionality is essential for seamless operation and user experience.
Another complexity arises from the need for the hardware device to be stateful and capable of implementing complex policies akin to those used by VLS. After a payment is authorized by the user, numerous signing operations may be necessary for the completion of that payment. It is crucial for the hardware device to ensure that these operations do not allow a malicious application to exfiltrate funds. Additionally, the device must handle various background operations that require signatures, such as on-the-fly splicing and commitment fee updates, without direct user input.
To address these requirements effectively, it would be necessary to incorporate a substantial portion of the lightning channel state machine logic directly into the hardware device. This would allow the device to analyze and authorize transactions autonomously. However, this endeavor could equate to developing an entire lightning network implementation within the hardware wallet, representing a considerable and complex task. While pursuing this approach through prototyping might be valuable, the scale and complexity of the project should not be underestimated, as it represents a significant undertaking.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback