MIME-Version: 1.0
References: <CAPvWj7H9hg8EMCvDzWiq=f59KojHEGCm_iAP+FBaB+25=CLt0A@mail.gmail.com>
 <202012230215.46394.luke@dashjr.org>
 <CAPvWj7E3S9HxZgpw0bdDmso+3sXc-h0u15_528r11EZ3LY-wYA@mail.gmail.com>
In-Reply-To: <CAPvWj7E3S9HxZgpw0bdDmso+3sXc-h0u15_528r11EZ3LY-wYA@mail.gmail.com>
From: Omar Shibli <omarshib@gmail.com>
Date: Wed, 23 Dec 2020 13:44:52 +0200
Message-ID: <CAE3EOfh4zh5WubMF-QzWA6g3mKvpz7TLtc45usfU92xbmpn-qw@mail.gmail.com>
To: monokh <mnokhb@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cda1e505b72038b7"
Subject: Re: [bitcoin-dev] BIP Proposal: Wallet Interface
Precedence: list

--000000000000cda1e505b72038b7
Content-Type: text/plain; charset="UTF-8"

That's a great idea, in traditional banking there are wide initiatives to
standardize components between different actors, most widely used is Open
Banking , i think regardless of the usage, it could be hardware or
software, there is a big value in standrizating communications between
different components.

Here is more info about Open Banking:
https://fin.plaid.com/articles/what-is-the-open-banking-standard/#:~:text=The%20Open%20Banking%20Standard%20relies,data%20through%20their%20bank%20accounts

On Wed, Dec 23, 2020 at 10:42 AM monokh via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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> 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
>

--000000000000cda1e505b72038b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That&#39;s a great idea, in traditional banking there are =
wide initiatives=C2=A0to standardize components between different actors, m=
ost widely used is Open Banking , i think regardless of the usage, it could=
 be hardware or software, there is a big value in standrizating communicati=
ons between different components.<div><br></div><div>Here is more info abou=
t Open Banking:</div><div><a href=3D"https://fin.plaid.com/articles/what-is=
-the-open-banking-standard/#:~:text=3DThe%20Open%20Banking%20Standard%20rel=
ies,data%20through%20their%20bank%20accounts">https://fin.plaid.com/article=
s/what-is-the-open-banking-standard/#:~:text=3DThe%20Open%20Banking%20Stand=
ard%20relies,data%20through%20their%20bank%20accounts</a></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec =
23, 2020 at 10:42 AM monokh via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">Thanks for the input Luke.<br><br>&gt; 1) People should not be enc=
ouraged to write or use web browsers for their wallet.<br><br>Indeed. Holdi=
ng keys in the browser can be very insecure, however the spec is not limite=
d 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 a=
lready have such an interface. Unfortunately as there has been no standardi=
sation, an application must specifically provide an implementation for each=
 wallet to be compatible.<br><br>&gt; 2) You may want to look over earlier =
work in this area.<br><br>Please share if you have specifics in mind. What =
has been considered were mainly hardware wallet apis. The requests have bee=
n defined such that they would be compatible. I will make references to suc=
h 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.<br><br>-monokh=C2=A0</div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 23, 2020 at 2:15 AM Luke Dashjr=
 &lt;<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1)=
 People should not be encouraged to write or use web browsers for their <br=
>
wallet.<br>
2) You may want to look over earlier work in this area.<br>
<br>
On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:<br>
&gt; Hi<br>
&gt;<br>
&gt; This is a first draft of a BIP we intend to submit. The main intention=
 is<br>
&gt; to define a simple interface that wallets and applications can agree o=
n<br>
&gt; that would cover the vast majority of use cases. This can enable writi=
ng<br>
&gt; bitcoin applications (e.g. time lock, multi sig) on the web that can b=
e<br>
&gt; seamlessly used with any compatible wallets. We have implementations o=
f<br>
&gt; such examples but I don&#39;t want to turn this thread into a promotio=
n and<br>
&gt; rather focus on the spec.<br>
&gt;<br>
&gt; Appreciate input from the list. Please share if there are existing eff=
orts,<br>
&gt; relevant specs or use cases.<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; A wallet interface specification for bitcoin applications<br>
&gt;<br>
&gt; ## Abstract<br>
&gt;<br>
&gt; This BIP describes an API for Bitcoin wallets and applications as a<br=
>
&gt; standard.<br>
&gt;<br>
&gt; ## Summary<br>
&gt;<br>
&gt; Bitcoin wallets should expose their address derivation and signing<br>
&gt; functions to external applications. The interface would be expressed a=
s<br>
&gt; follows in javascript:<br>
&gt;<br>
&gt; ```<br>
&gt; {<br>
&gt; // Wallet Metadata<br>
&gt; wallet: {<br>
&gt; name: &#39;Bitcoin Core&#39;<br>
&gt; },<br>
&gt;<br>
&gt; // Request access to the wallet for the current host<br>
&gt; async enable: (),<br>
&gt;<br>
&gt; // Request addresses and signatures from wallet<br>
&gt; async request ({ method, params })<br>
&gt; }<br>
&gt; ```<br>
&gt;<br>
&gt; In the web context the interface could be exposed at the top level of =
a<br>
&gt; webpage, for example under `window.bitcoin`. However this spec does no=
t<br>
&gt; intend to define any standards for how and where the interfaces should=
 be<br>
&gt; exposed.<br>
&gt;<br>
&gt; ## Motivation<br>
&gt;<br>
&gt; Due to the seldom available APIs exposed by wallets, applications (web=
 or<br>
&gt; otherwise) are limited in how they are able to interact. Generally onl=
y<br>
&gt; simple sends have been available. A more robust API that introduces ot=
her<br>
&gt; requests will promote richer Bitcoin applications.<br>
&gt;<br>
&gt; Additionally, wallet APIs have frequently included inconsistencies in =
their<br>
&gt; interfaces and behaviour. This has required applications to build and<=
br>
&gt; maintain a separate client for each wallet, increasing the risk of bug=
s and<br>
&gt; unintended behaviour as well as being a limiting factor for the adopti=
on of<br>
&gt; usable bitcoin applications.<br>
&gt;<br>
&gt; With a standardised wallet API:<br>
&gt;<br>
&gt; - Wallets have a clear API to implement<br>
&gt; - Applications have a clear expectation of wallet interface and behavi=
our<br>
&gt; - Applications become agnostic to the wallet specifics, increasing cho=
ice<br>
&gt; for users<br>
&gt;<br>
&gt; If more wallets implement the specification, applications will be deve=
loped<br>
&gt; more confidently by benefiting from the wallet interoperability. This<=
br>
&gt; creates a positive feedback loop.<br>
&gt;<br>
&gt; ## Specification<br>
&gt;<br>
&gt; For simplicity, the interface is defined in the context of web applica=
tions<br>
&gt; running in the browser (JS) however, they are simple enough to be easi=
ly<br>
&gt; implemented in other contexts.<br>
&gt;<br>
&gt; ### General Rules<br>
&gt;<br>
&gt; - For sensitive functions (e.g. signing), wallet software should alway=
s<br>
&gt; prompt the user for confirmation<br>
&gt;<br>
&gt; ### Types<br>
&gt;<br>
&gt; **UserDeniedError**<br>
&gt; An error type indicating that the application&#39;s request has been d=
enied by<br>
&gt; the user<br>
&gt; Type: Error<br>
&gt;<br>
&gt; **Hex**<br>
&gt; Type: String<br>
&gt; Example:<br>
&gt; `&quot;0000000000000000000a24677957d1e50d70e67c513d220dbe8868c4c3aefc0=
8&quot;`<br>
&gt;<br>
&gt; **Address**<br>
&gt; Address details<br>
&gt; Type: Object<br>
&gt; Example:<br>
&gt;<br>
&gt; ```<br>
&gt; {<br>
&gt; &quot;address&quot;: &quot;bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs&=
quot;,<br>
&gt; &quot;publicKey&quot;:<br>
&gt; &quot;02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e=
5a&quot;,<br>
&gt; &quot;derivationPath&quot;: &quot;84&#39;/1&#39;/0&#39;/0/0&quot;<br>
&gt; }<br>
&gt; ```<br>
&gt;<br>
&gt; ### API<br>
&gt;<br>
&gt; The wallet must implement the following methods.<br>
&gt;<br>
&gt; **enable**<br>
&gt;<br>
&gt; The enable call prompts the user for access to the wallet.<br>
&gt;<br>
&gt; If successful, it resolves to an address (`**Address**` type) of the<b=
r>
&gt; wallet. Typically the first external address to be used as an identity=
.<br>
&gt;<br>
&gt; **`UserDeniedError`** will be thrown if the request is rejected.<br>
&gt;<br>
&gt; **request**<br>
&gt;<br>
&gt; The request method must take one parameter in the following format:<br=
>
&gt;<br>
&gt; ```<br>
&gt; {<br>
&gt; &quot;method&quot;: &quot;wallet_methodName&quot;,<br>
&gt; &quot;params&quot;: [&quot;foo&quot;, &quot;bar&quot;, &quot;baz&quot;=
]<br>
&gt; }<br>
&gt; ```<br>
&gt;<br>
&gt; For a list of mandatory methods see Table<br>
&gt;<br>
&gt; The wallet should reject request calls unless `enable` has been resolv=
ed.<br>
&gt;<br>
&gt; Sensitive requests that involve signing should always prompt the user =
for<br>
&gt; confirmation<br>
&gt;<br>
&gt; On success the request should resolve to the response as defined in th=
e<br>
&gt; method table.<br>
&gt;<br>
&gt; **`UserDeniedError`** will be thrown if the request is rejected.<br>
&gt;<br>
&gt; **Mandatory methods**<br>
&gt;<br>
&gt; method: `wallet_getAddresses` params: [`index =3D 0, numAddresses =3D =
1, change<br>
&gt; =3D false`]<br>
&gt; return: `[ Address ]`<br>
&gt; error: UserDeniedError<br>
&gt;<br>
&gt; method: `wallet_signMessage` params: `[ message, address ]`<br>
&gt; return: Signature `Hex`<br>
&gt; error: UserDeniedError<br>
&gt;<br>
&gt; method: `wallet_signPSBT` params: `[ [psbtBase64, inputIndex, address]=
 ]`<br>
&gt; return: `psbtBase64`<br>
&gt; error: UserDeniedError<br>
&gt;<br>
&gt; method: `wallet_getConnectedNetwork` params: `[]`<br>
&gt; return: Network object `mainnet` | `testnet` | `regetst`<br>
&gt; error: UserDeniedError<br>
&gt;<br>
&gt; ## Rationale<br>
&gt;<br>
&gt; The purpose of the API is to expose a set of commonly used wallet<br>
&gt; operations. In addition, it should be flexible enough to serve for oth=
er<br>
&gt; requests such as node RPC calls.<br>
&gt;<br>
&gt; **Why is there a singular request call instead of named methods?**<br>
&gt; The transport layer for the requests cannot be assumed, therefore it i=
s<br>
&gt; much more flexible to instead define an abstract format.<br>
&gt;<br>
&gt; **Why are the mandatory methods so primitive? Where is getBalance,<br>
&gt; getUtxos, ... ?**<br>
&gt; A wallet need not worry about providing every possible scenario for us=
age.<br>
&gt; The primitives of keys and signing can expose enough to applications t=
o do<br>
&gt; the rest. Applications should have flexibility in how they implement t=
hese<br>
&gt; functions. It is the role of a library rather than the wallet.<br>
&gt;<br>
&gt; ## Security Implications<br>
&gt;<br>
&gt; Great care should be taken when exposing wallet functionality external=
ly as<br>
&gt; the security and privacy of the user is at risk.<br>
&gt;<br>
&gt; ### Signing<br>
&gt;<br>
&gt; Operations that trigger signing using private keys should be guarded b=
ehind<br>
&gt; confirmation screens where the user is fully aware of the nature of th=
e<br>
&gt; transaction. In the example of a PSBT signature request, the outputs, =
the<br>
&gt; inputs and which key is being used should be clearly marked.<br>
&gt;<br>
&gt; ### Privacy<br>
&gt;<br>
&gt; Some api methods expose metadata about the user, such as public keys.<=
br>
&gt; Depending on how privacy focused the wallet intends to be, the wallet =
could<br>
&gt; protect these behind a confirmation. Commonly the wallet just needs to=
 give<br>
&gt; the origin access to all of its public keys, however it could also all=
ow<br>
&gt; the option to expose only selected derivation paths.<br>
&gt;<br>
&gt; -monokh<br>
<br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000cda1e505b72038b7--