Author: monokh 2020-12-23 07:29:23
Published on: 2020-12-23T07:29:23+00:00
This is a conversation between two individuals, Luke and Monokh, discussing a first draft of a Bitcoin Improvement Proposal (BIP) that defines a simple interface for Bitcoin wallets and applications to agree on. The aim is to cover the majority of use cases and enable writing Bitcoin applications (e.g., time lock, multi-sig) on the web that can be seamlessly used with any compatible wallets. They welcome input from the list and ask for feedback on existing efforts, relevant specs, or use cases.The proposed BIP describes an API for Bitcoin wallets and applications as a standard. Bitcoin wallets should expose their address derivation and signing functions to external applications. The interface would be expressed in javascript and could be exposed at the top level of a webpage, for example under `window.bitcoin`. However, the spec does not intend to define any standards for how and where the interfaces should be exposed.Due to the seldom available APIs exposed by wallets, applications (web or otherwise) are limited in how they can interact. A more robust API that introduces other requests will promote richer Bitcoin applications. Additionally, wallet APIs have frequently included inconsistencies in their interfaces and behavior, requiring applications to build and maintain a separate client for each wallet, increasing the risk of bugs and unintended behavior, and being a limiting factor for the adoption of usable Bitcoin applications.With a standardized wallet API, wallets have a clear API to implement, applications have a clear expectation of wallet interface and behavior, and applications become agnostic to the wallet specifics, increasing choice for users. If more wallets implement the specification, applications will be developed more confidently by benefiting from the wallet interoperability. The proposed API is defined in the context of web applications running in the browser (JS); however, they are simple enough to be easily implemented in other contexts. For sensitive functions (e.g., signing), wallet software should always prompt the user for confirmation. Great care should be taken when exposing wallet functionality externally as the security and privacy of the user are at risk.The purpose of the API is to expose a set of commonly used wallet operations. In addition, it should be flexible enough to serve for other requests such as node RPC calls. The transport layer for the requests cannot be assumed; therefore, it is much more flexible to instead define an abstract format. A wallet need not worry about providing every possible scenario for usage. The primitives of keys and signing can expose enough to applications to do the rest. Applications should have flexibility in how they implement these functions. The proposed BIP includes mandatory methods: `wallet_getAddresses`, `wallet_signMessage`, `wallet_signPSBT`, and `wallet_getConnectedNetwork`. The wallet should reject request calls unless `enable` has been resolved. Sensitive requests that involve signing should always prompt the user for confirmation. On success, the request should resolve to the response as defined in the method table.Finally, the proposed BIP discusses the security implications of exposing wallet functionality externally, specifically regarding signing and privacy. Operations that trigger signing using private keys should be guarded behind confirmation screens where the user is fully aware of the nature of the transaction. Some API methods expose metadata about the user, such as public keys. Depending on how privacy-focused the wallet intends to be, the wallet could protect these behind a confirmation.
Updated on: 2023-06-14T16:51:27.192027+00:00