Re: [bitcoin-dev] BIP Proposal: Wallet Interface

[Aymeric Vitte <aymeric@peersm.com>]

[-- Attachment #1: Type: text/plain, Size: 12629 bytes --]

Resending to the list since I am using a different email

Complement: if anonymity is required from the browser (or elsewhere) you
might consider looking at https://github.com/Ayms/node-Tor too


Le 24/12/2020 à 20:40, Aymeric Vitte a écrit :
>
> You might want to take a look at: https://peersm.com/wallet
>
> And https://github.com/Ayms/bitcoin-transactions
>
> "wallet" is not the very correct word, it's more bitcoin cli outside
> of bitcoin core but for now not linked to an explorer/tx system which
> makes it probably still not so easy to use for the transactions part
> (which can be extended to lightning, etc)
>
> The idea is to propose to people most of the tools they need to manage
> their coins by themselves, or at least understand better what they are
> doing
>
> "People should not be encouraged to write or use web browsers for
> their wallet." --> yes and no, please crack the standalone webapp
> above, so it's finally a no when things are done correctly, of course
> there is no story of keys storage inside browsers or online stuff with
> keys
>
> Maybe this can be turned one day into a w3c api like webcrypto
> (window.bitcoin as you sketch)
>
> Le 23/12/2020 à 08:29, monokh via bitcoin-dev a écrit :
>> Thanks for the input Luke.
>>
>> > 1) People should not be encouraged to write or use web browsers for
>> their wallet.
>>
>> Indeed. Holding keys in the browser can be very insecure, however the
>> spec is not limited to this. I will amend to make this clear. The
>> same interface can be used to communicate from a web context or even
>> desktop application with hardware wallets where keys are segregated
>> safely. The prominent hardware wallets already have such an
>> interface. Unfortunately as there has been no standardisation, an
>> application must specifically provide an implementation for each
>> wallet to be compatible.
>>
>> > 2) You may want to look over earlier work in this area.
>>
>> Please share if you have specifics in mind. What has been considered
>> were mainly hardware wallet apis. The requests have been defined such
>> that they would be compatible. I will make references to such
>> considerations in the text. I welcome any feedback on what may be
>> missing or problematic for these providers - something I will also
>> pursue outwith the thread.
>>
>> -monokh 
>>
>> On Wed, Dec 23, 2020 at 2:15 AM Luke Dashjr <luke@dashjr.org
>> <mailto:luke@dashjr.org>> wrote:
>>
>>     1) People should not be encouraged to write or use web browsers
>>     for their
>>     wallet.
>>     2) You may want to look over earlier work in this area.
>>
>>     On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:
>>     > Hi
>>     >
>>     > This is a first draft of a BIP we intend to submit. The main
>>     intention is
>>     > to define a simple interface that wallets and applications can
>>     agree on
>>     > that would cover the vast majority of use cases. This can
>>     enable writing
>>     > bitcoin applications (e.g. time lock, multi sig) on the web
>>     that can be
>>     > seamlessly used with any compatible wallets. We have
>>     implementations of
>>     > such examples but I don't want to turn this thread into a
>>     promotion and
>>     > rather focus on the spec.
>>     >
>>     > Appreciate input from the list. Please share if there are
>>     existing efforts,
>>     > relevant specs or use cases.
>>     >
>>     > ------------------------------
>>     >
>>     > A wallet interface specification for bitcoin applications
>>     >
>>     > ## Abstract
>>     >
>>     > This BIP describes an API for Bitcoin wallets and applications as a
>>     > standard.
>>     >
>>     > ## Summary
>>     >
>>     > Bitcoin wallets should expose their address derivation and signing
>>     > functions to external applications. The interface would be
>>     expressed as
>>     > follows in javascript:
>>     >
>>     > ```
>>     > {
>>     > // Wallet Metadata
>>     > wallet: {
>>     > name: 'Bitcoin Core'
>>     > },
>>     >
>>     > // Request access to the wallet for the current host
>>     > async enable: (),
>>     >
>>     > // Request addresses and signatures from wallet
>>     > async request ({ method, params })
>>     > }
>>     > ```
>>     >
>>     > In the web context the interface could be exposed at the top
>>     level of a
>>     > webpage, for example under `window.bitcoin`. However this spec
>>     does not
>>     > intend to define any standards for how and where the interfaces
>>     should be
>>     > exposed.
>>     >
>>     > ## Motivation
>>     >
>>     > Due to the seldom available APIs exposed by wallets,
>>     applications (web or
>>     > otherwise) are limited in how they are able to interact.
>>     Generally only
>>     > simple sends have been available. A more robust API that
>>     introduces other
>>     > requests will promote richer Bitcoin applications.
>>     >
>>     > Additionally, wallet APIs have frequently included
>>     inconsistencies in their
>>     > interfaces and behaviour. This has required applications to
>>     build and
>>     > maintain a separate client for each wallet, increasing the risk
>>     of bugs and
>>     > unintended behaviour as well as being a limiting factor for the
>>     adoption of
>>     > usable bitcoin applications.
>>     >
>>     > With a standardised wallet API:
>>     >
>>     > - Wallets have a clear API to implement
>>     > - Applications have a clear expectation of wallet interface and
>>     behaviour
>>     > - 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. This
>>     > creates a positive feedback loop.
>>     >
>>     > ## Specification
>>     >
>>     > For simplicity, the interface 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.
>>     >
>>     > ### General Rules
>>     >
>>     > - For sensitive functions (e.g. signing), wallet software
>>     should always
>>     > prompt the user for confirmation
>>     >
>>     > ### Types
>>     >
>>     > **UserDeniedError**
>>     > An error type indicating that the application's request has
>>     been denied by
>>     > the user
>>     > Type: Error
>>     >
>>     > **Hex**
>>     > Type: String
>>     > Example:
>>     >
>>     `"0000000000000000000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
>>     >
>>     > **Address**
>>     > Address details
>>     > Type: Object
>>     > Example:
>>     >
>>     > ```
>>     > {
>>     > "address": "bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs",
>>     > "publicKey":
>>     >
>>     "02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e5a",
>>     > "derivationPath": "84'/1'/0'/0/0"
>>     > }
>>     > ```
>>     >
>>     > ### API
>>     >
>>     > The wallet must implement the following methods.
>>     >
>>     > **enable**
>>     >
>>     > The enable call prompts the user for access to the wallet.
>>     >
>>     > If successful, it resolves to an address (`**Address**` type)
>>     of the
>>     > wallet. Typically the first external address to be used as an
>>     identity.
>>     >
>>     > **`UserDeniedError`** will be thrown if the request is rejected.
>>     >
>>     > **request**
>>     >
>>     > The request method must take one parameter in the following format:
>>     >
>>     > ```
>>     > {
>>     > "method": "wallet_methodName",
>>     > "params": ["foo", "bar", "baz"]
>>     > }
>>     > ```
>>     >
>>     > For a list of mandatory methods see Table
>>     >
>>     > 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.
>>     >
>>     > **`UserDeniedError`** will be thrown if the request is rejected.
>>     >
>>     > **Mandatory methods**
>>     >
>>     > method: `wallet_getAddresses` params: [`index = 0, numAddresses
>>     = 1, change
>>     > = false`]
>>     > return: `[ Address ]`
>>     > error: UserDeniedError
>>     >
>>     > method: `wallet_signMessage` params: `[ message, address ]`
>>     > return: Signature `Hex`
>>     > error: UserDeniedError
>>     >
>>     > method: `wallet_signPSBT` params: `[ [psbtBase64, inputIndex,
>>     address] ]`
>>     > return: `psbtBase64`
>>     > error: UserDeniedError
>>     >
>>     > method: `wallet_getConnectedNetwork` params: `[]`
>>     > return: Network object `mainnet` | `testnet` | `regetst`
>>     > error: UserDeniedError
>>     >
>>     > ## Rationale
>>     >
>>     > 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.
>>     >
>>     > **Why is there a singular request call instead of named methods?**
>>     > The transport layer for the requests cannot be assumed,
>>     therefore it is
>>     > much more flexible to instead define an abstract format.
>>     >
>>     > **Why are the mandatory methods so primitive? Where is getBalance,
>>     > getUtxos, ... ?**
>>     > 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. It is the role of a library rather than the wallet.
>>     >
>>     > ## Security Implications
>>     >
>>     > Great care should be taken when exposing wallet functionality
>>     externally as
>>     > the security and privacy of the user is at risk.
>>     >
>>     > ### Signing
>>     >
>>     > 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. In the example of a PSBT signature request, the
>>     outputs, the
>>     > inputs and which key is being used should be clearly marked.
>>     >
>>     > ### Privacy
>>     >
>>     > 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. Commonly the wallet just
>>     needs to give
>>     > the origin access to all of its public keys, however it could
>>     also allow
>>     > the option to expose only selected derivation paths.
>>     >
>>     > -monokh
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> -- 
> Sophia-Antipolis, France
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms

-- 
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


[-- Attachment #2: Type: text/html, Size: 19972 bytes --]