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 <l...@dashjr.org >> <mailto:l...@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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
