Published on: 2016-08-28T23:14:03+00:00
The discussion surrounding hardware wallets and their integration into Bitcoin Core revolves around several key points. One concern is the possibility of a "cosmic ray" flipping a bit during address generation, leading to lost funds. To mitigate this risk, some users generate addresses on two independent machines using different software. However, a proposed solution suggests that both a detached signer and a normal wallet should verify the correctness of generated addresses before coins are sent there. This would offer protection against losing money due to a defective hardware wallet.There is also a debate about the usefulness of a signing protocol, with some arguing that it is only valuable for hardware wallets. However, others believe that any website wanting to request public keys/signatures from users would find this protocol beneficial. The focus should not only be on servicing hardware but also on allowing users to choose their own ECDSA implementation, whether it be hardware or software.One participant in the discussion expresses concerns about defining rigid standards for hardware wallet development and integration. They argue that the TREZOR concept of a device as a server and primary source of workflow management goes against the proposal of wallet software as a workflow manager. Another member of the discussion agrees with this sentiment, stating that driving any hardware wallet from the wallet itself or from a third-party daemon implementing a URL scheme would provide better device interoperability and easier maintenance and update paths for wallets.The concept of building a standard on top of the URI protocol is seen as a limitation by some. Instead, it is suggested that high-level APIs be used to implement hardware-specific protocols and transports as plugins. This approach would make life easier for app developers without defining artificial "standards." Additionally, there are discussions about the use of smartcards in hardware wallets and the potential risks associated with blindly signing transactions. Suggestions are made to use hardware security modules (HSMs) instead of smartcards and to utilize out-of-band communication channels for validating business logic.Other topics of discussion include the use of the stdio/pipe approach versus the URI scheme for hardware wallets, the need for a clear interface between wallet and signing device, and the possibility of defining a standard on the hardware interaction layer. Finally, there is debate about the feasibility of ECC-enabled smart-cards signing Bitcoin transactions and the suggestion to add custom logic for validation to these cards.Overall, the discussions highlight the importance of security, interoperability, and ease of use when it comes to integrating hardware wallets into Bitcoin Core. The proposals and debates aim to provide improved security measures and a better user experience for Bitcoin Core users.In a Bitcoin development discussion, Thomas proposes a protocol for offline signing of transactions initiated on merchant websites. He suggests that the procedure is similar to multi-signature addresses but emphasizes the need for requesting an xpub/public key. He also mentions the importance of redeemScript and witnessScript for full validation and signing of transaction inputs. Thomas believes that his proposal allows users to provide their own xpub and leverage services provided by GreenAddress without relying on their signing code.Jochen responds to Jonas' draft and suggests that a wallet needs to connect with a hardware wallet to learn the xpubs controlled by the hardware. He highlights missing points in the specification, including the amount spent by each input and checks required for multisig change addresses. Jochen also finds the specification ambiguous for P2SH transactions and proposes a solution to clarify the inputscript.A user asks why a normal smart-card with ECC encryption cannot be used for the hardware signing component of a wallet app. Peter Todd responds, stating that ECC-enabled smart cards cannot sign the specific curve used by Bitcoin and generally only support higher-level protocols. He also mentions the security risks and blind signing associated with smart cards.Bitcoin developers discuss standardizing the hardware protocol to improve user experience. Some hardware wallets have already implemented Trezor's interface. The existing URI scheme allows disambiguation by manufacturer but lacks a way to enumerate available manufacturers or enabled wallets. The specification could have two layers - raw messages and transport mechanism. Luke-Jr argues for standardization to eliminate the need for plugin installation.Jonas receives feedback from Jochen on the draft for detached signing. Jochen suggests connecting with a hardware wallet to learn xpubs and provides additional points missing from the specification. He also proposes a solution for ambiguous inputscript in P2SH transactions.Jonas and Pavol Rusnak discuss the need for a better way to validate input amounts in Bitcoin transactions. They agree on creating a standard for new forms of transactions like SegWit and Lightning. The lack of a standard for hardware wallet interfaces has led to proprietary code additions by wallet vendors.Pavol Rusnak expresses his opinion that standardizing extended validation of inputs for current Bitcoin transactions is not sensible due to complexity. However, he suggests considering it for SegWit and Lightning transactions.
Updated on: 2023-08-01T18:55:11.739631+00:00