Re: [bitcoin-dev] BIP Proposal: Wallet Interface
Obviously Bitcoin has a wallet api, intermingled with other protocol APIs:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
For security, a standard wallet API should write a token/port to a
local file where the user can grab that token and use it (that's
basically how the existing bitcoind does it, with a username/password
living in a file... not as nice as a token/port, IMO)
Probably any such standards document should do its best to be
compatible with the existing APIs that so many are already familiar
with. Or maybe I misunderstand the proposal.
- Erik
On Tue, Dec 22, 2020 at 9:48 AM 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: `"000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
>
> **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
Re: [bitcoin-dev] New PSBT version proposal
Hi All, The full modified BIP can be read at https://github.com/achow101/bips/blob/psbt2/bip-0174.mediawiki. I will open a PR to the BIPs repo soon after further discussion on this. Andrew On 12/22/20 3:12 PM, Andrew Chow wrote: > Hi All, > > I have some updates on this after speaking with some people off-list. > > Firstly, the version number will be set to 2. In most discussions, this > proposal was being referred to as PSBT version 2, so it'll be easier and > clearer to set the version number to 2. > > For lock times, instead of a single PSBT_IN_REQUIRED_LOCKTIME field, > there will be 2 of them, one for a time based lock time, and the other > for height based. These will be: > * PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10 > * Key: empty > * Value: 32 bit unsigned little endian integer greater than or equal > to 5 representing the minimum Unix timestamp that this input > requires to be set as the transaction's lock time. Must be omitted in > PSBTv0, and may be omitted in PSBTv2 > * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11 > * Key: empty > * Value: 32 bit unsigned little endian integer less than 5 > representing the minimum block height that this input requires to be set > as the transaction's lock time. Must be omitted in PSBTv0, and may be > omitted in PSBTv2. > > Having two lock time fields is necessary due to the behavior where all > inputs must use the same type of lock time (height or time). Thus if an > input requires a particular type of lock time, it must set the requisite > field. Any new inputs being added must be able to accommodate all > existing inputs' lock time type. This means they either must not have a > lock time specified (i.e. no OP_CLTV involved), or have branches that > allow the acceptance of either type. If an input has a lock time type > that is incompatible with the rest of the transaction, it must not be added. > > PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback > option if no input lock time fields are present. If there are input lock > times, all lock time calculations must ignore it. > > Any role which does lock time calculation will first check if there are > input lock time fields. If there are not, it must then check for a > PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the > transaction's lock time. If it does not, the lock time is 0. If there > are input lock time fields, it must choose the type which does not > invalidate any inputs. The lock time is then determined to be the > maximum value of all of the lock time fields for the chosen type. > > > Additionally, I would like to add a new global field: > * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05 > * Key: empty > * Value: A single byte as a boolean. 0 for False, 1 for True. All > other values ore prohibited. Must be omitted for PSBTv0, may be omitted > in PSBTv2. > > PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and > outputs can be added to the PSBT. This flag may be set to True when > inputs and outputs are being updated, signed, and finalized. However > care must be taken when there are existing signatures. If this field is > omitted or set to False, no further inputs and outputs may be added to > the PSBT. > > Several rules must be followed to ensure that adding additional inputs > and outputs will not invalidate existing signatures. First, an input or > output adder must check for any existing signatures in all of the other > inputs. If there are none, the input or output may be added in any > position. If there are one or more signatures, each signature's sighash > type must be examined. Inputs may only be added if all existing > signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all > existing signatures use SIGHASH_NONE. If an input has a signature using > SIGHASH_SINGLE, the same number of inputs and outputs must be added > before that input and it's corresponding output. For all other sighash > types (i.e. SIGHASH_ALL and any future sighash types), no inputs or > outputs may be added to the PSBT. Specific exceptions can be made in the > future for additional sighash types. > > Furthermore, these newly added inputs must follow additional lock time > rules. Because all signatures, regardless of sighash type, sign the > transaction lock time, newly added inputs when there are existing > signatures must have the same type of lock time used in the transaction, > and must be less than or equal to the transaction lock time. It must not > cause the transaction lock time to change, otherwise the signatures will > be invalidated. > > > Lastly, to uniquely identify transactions for combiners, a txid can be > computed from the information present in the PSBT. Internally, combiners > can create an unsigned transaction given the transaction version, the > input prevouts, the outputs, and the computed locktime. This can then be > used to calculate a txid and thus used as a way to identify PSBTs. > Combiners will
Re: [bitcoin-dev] New PSBT version proposal
Hi, On 12/22/20 10:30 PM, fiatjaf wrote: > Hi Andrew. > > I'm just a lurker here and I have not much experience with PSBTs, but still > let me pose this very obvious question and concern: isn't this change going > to create a compatibility nightmare, with some software supporting version 1, > others supporting version 2, and the ones that care enough about UX and are > still maintained being forced to support both versions -- and for no very > important reason except some improvements in the way data is structured? No, it is not just "improvements in the way data is structured." The primary reason for these changes is to allow PSBT to properly support adding inputs and outputs. This is a feature that many people have requested, and the ways that people have been doing it are honestly just hacks and not really the right way to be doing that. These changes allow for that feature to be supported well. Furthermore, it is possible to downgrade and upgrade PSBTs between the two versions, once all inputs and outputs have been decided. Since PSBTv2 is essentially just taking all of the normal transaction fields and grouping them all with the rest of the data for those inputs and outputs, it is easy to reconstruct a global unsigned transaction and turn a PSBTv2 into a PSBTv0. It is likewise just as easy to go the other way and break apart the global unsigned tx to turn a PSBTv0 into a PSBTv2. Originally, I had considered requiring that once a transaction was fully constructed it must be downgraded to a PSBTv0, but the structure changes that were made do make it easier to work with PSBT so I decided not to add this requirement. Perhaps to maintain compatibility PSBT_GLOBAL_UNSIGNED_TX shouldn't be disallowed in PSBTv2 once the transaction is constructed? It would make things much more confusing though as it would no longer be a clean break. Andrew Chow > Ultimately I don't think it should matter if some data is structured in > not-the-best-possible way, as long as it is clear enough for the computer and > for the libraries already written to deal with it. Backwards-compatibility > and general interoperability is worth much more than anything else in these > cases. > > Also let me leave this article here, which I find very important (even if for > some reason it ends up not being relevant to this specific case): > http://scripting.com/2017/05/09/rulesForStandardsmakers.html > > On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev > wrote > > Hi All, > > > > I have some updates on this after speaking with some people off-list. > > > > Firstly, the version number will be set to 2. In most discussions, this > > proposal was being referred to as PSBT version 2, so it'll be easier and > > clearer to set the version number to 2. > > > > For lock times, instead of a single PSBT_IN_REQUIRED_LOCKTIME field, > > there will be 2 of them, one for a time based lock time, and the other > > for height based. These will be: > > * PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10 > >* Key: empty > >* Value: 32 bit unsigned little endian integer greater than or equal > > to 5 representing the minimum Unix timestamp that this input > > requires to be set as the transaction's lock time. Must be omitted in > > PSBTv0, and may be omitted in PSBTv2 > > * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11 > >* Key: empty > >* Value: 32 bit unsigned little endian integer less than 5 > > representing the minimum block height that this input requires to be set > > as the transaction's lock time. Must be omitted in PSBTv0, and may be > > omitted in PSBTv2. > > > > Having two lock time fields is necessary due to the behavior where all > > inputs must use the same type of lock time (height or time). Thus if an > > input requires a particular type of lock time, it must set the requisite > > field. Any new inputs being added must be able to accommodate all > > existing inputs' lock time type. This means they either must not have a > > lock time specified (i.e. no OP_CLTV involved), or have branches that > > allow the acceptance of either type. If an input has a lock time type > > that is incompatible with the rest of the transaction, it must not be > added. > > > > PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback > > option if no input lock time fields are present. If there are input lock > > times, all lock time calculations must ignore it. > > > > Any role which does lock time calculation will first check if there are > > input lock time fields. If there are not, it must then check for a > > PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the > > transaction's lock time. If it does not, the lock time is 0. If there > > are input lock time fields, it must choose the type which does not > > invalidate any inputs. The lock time is then determined to be the >
Re: [bitcoin-dev] BIP Proposal: Wallet Interface
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 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
>> >
Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements
On Tue, Dec 22, 2020 at 12:22:37AM +, Pieter Wuille via bitcoin-dev wrote: > > Re-reading your proposed text, I'm wondering if the "consensus-only > validation" extension is intended to replace the > inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't > think it does, and regardless it doesn't seem very useful. > > What I'm suggestion could be specified this way: > * If validator understands the script: > * If signature is consensus valid (as far as the validator knows): > * If signature is not known to trigger standardness rules intended for > future extension (well-defined set of rules listed in BIP, and revisable): > return valid > * Otherwise: return inconclusive > * Otherwise: return invalid > * Otherwise: return inconclusive > > Or in other words: every signature has a well-defined result (valid, invalid, > inconclusive) + validators may choose to report inconclusive for anything > they don't understand. > > This has the property that as long as new consensus rules only change things > that were covered under for-future-extension standardness rules, no two > validators will ever claim valid and invalid for the same signature. Only > valid+inconclusive or invalid+inconclusive. > I've updated my PR at https://github.com/bitcoin/bips/pull/1048 Differences: 1. I compacted all the validation states into three: valid at time/age T/S, invalid, and inconclusive. 2. "Inconclusive" means either an "upgradeable rule" failed, e.g. use of a NOP or a bad network version, or the validator just didn't understand the scripts. 3. I removed the "Extensions" sections now everything is in the main protocol. 4. I removed the "to_sign" transaction from the wire serialization, since after all this, it can always be inferred from the message and address. (This does mean, however, that there is no way to sign for scriptPubKeys that don't have addresses, e.g. bare public keys or multisigs. I don't think it's worth complicated the protocol for such obscure things.) -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] New PSBT version proposal
On Wed, Dec 23, 2020 at 12:30:20AM -0300, fiatjaf via bitcoin-dev wrote: > Hi Andrew. > > I'm just a lurker here and I have not much experience with PSBTs, but still > let me pose this very obvious question and concern: isn't this change going > to create a compatibility nightmare, with some software supporting version 1, > others supporting version 2, and the ones that care enough about UX and are > still maintained being forced to support both versions -- and for no very > important reason except some improvements in the way data is structured? > Yes, software will have to support both versions for a long time (likely forever, at least in the case of Core). But I think this is okay, for a couple of reasons: 1. it is very easy to convert from the old to new format, and from new to old (unless the new one uses features unsupported by the old). Indeed, the conversion logic is essentially the same as the logic that the Extractor role uses, so there isn't even that much redundant code. 2. There actually isn't a lot of software using PSBT out there, and most of that that does use PSBT is under rapid development. The obvious exception to this deployed hardware wallets, but as far as "software developers supporting old things for the sake of old hardware wallets" I think this transition is an order of magnitude simpler to handle than many of the ad-hoc protocol changes that individual vendors have done. In other words this is a "fact of life", and not even one of the grosser ones. 3. PSBT is pretty-much a dumb pure data format, and the diff between the new format and the old is pretty small. > Ultimately I don't think it should matter if some data is structured in > not-the-best-possible way, as long as it is clear enough for the computer and > for the libraries already written to deal with it. Backwards-compatibility > and general interoperability is worth much more than anything else in these > cases. > The reasons for switching to PSBT 2 are actually more than just structuring the data in a cleaner way. I agree that if the point of this upgrade were just elegance, it would not be worth the compatibility loss. But there are practical limitations that this proposal eliminates: 1. PSBT provides no way to modify the set of inputs or outputs after the Creator role is done. 2. Because of this, it forces certain things (e.g. locktimes and sequence numbers) to be chosen by the Creator, who may not have all the relevant information, and who certainly might not have it before any Updaters have done their part. as well, of course, as elegance reasons: 3. Parsers of the existing PSBT need to understand the Bitcoin transaction format just to learn e.g. how many inputs and outputs there are. It is impossible to parse a PSBT without also parsing (almost) the whole transaction. 4. Similarly to cross-check fields like 'non_witness_utxo' which are committed to in the transaction, you have to parse the whole transaction just to make sure that the purely-redundant data is correctly redundant. 5. If you put a 0-input transaction into a PSBT (which would be pointless because there's no way to add inputs, but it's not forbidden so your software still has to deal with this somehow..), you need a different transaction parser than the normal one, because there is an ambiguity related to segwit that PSBT resolves differently. It's also worth considering that PSBT is a young protocol, and future extensions will be easier starting from PSBT 2 than starting from the original version. > Also let me leave this article here, which I find very important (even if for > some reason it ends up not being relevant to this specific case): > http://scripting.com/2017/05/09/rulesForStandardsmakers.html > -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Wallet Interface
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 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:
> > `"000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
> >
> > **Address**
> > Address details
> > Type: Object
> > Example:
> >
> > ```
> > {
> > "address": "bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs",
> > "publicKey":
> > "02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e5a",
> > "derivationPath": "84'/1'/0'/0/0"
> > }
> > ```
> >
> > ### API
> >
> > The wallet must implement the following methods.
> >
> >
