Published on: 2015-03-13T21:34:31+00:00
The conversation revolves around the topic of web wallets and the concern over privacy in relation to a web wallet server. The sender is worried that their platform, BWS, may be considered a web wallet, but clarifies that private keys are not stored on the server. The recipient explains that they were referring to a setup similar to blockchain.info or CoPay, where the client has the private keys but relies on the server for wallet information. They also discuss the idea of having visibility of the wallet by the multisig facilitator for better user experience. The challenge of implementing push notifications in a decentralized way is mentioned. The recipient suggests following Gregory's approach, but acknowledges that the decision ultimately rests with the sender.The main focus of the discussion is on a web wallet server and the associated privacy concerns. It is mentioned that clients, being SPV (Simplified Payment Verification), can check their own balances and transaction history. This means that coordination tasks could be done by storing encrypted blobs on the server instead of giving it insight into the transactions. The fact that private keys are not stored on the server and addresses can be generated offline is highlighted. Copay is referenced as an example of using encrypted blobs to check balances and transaction history through Insight. However, it is believed that allowing some visibility of the wallet by the multisig facilitator would greatly improve the user experience. The engineering cost of preventing the server from knowing xpubs keys needs to be evaluated, and Subspace is suggested for further exploration.The context indicates that the main issue revolves around a web wallet server where clients are not SPV and rely on the server for balance and transaction history checks. The suggestion is made to store encrypted blobs on the server for coordination tasks instead of providing direct insight into the transactions. This approach is similar to the concept of Subspace. Even with measures in place to prevent the server from knowing the xpubkey, it still has access to all addresses and transactions due to the nature of web wallets. Therefore, limiting the information known by the server would not be worth the engineering cost as it would only reduce the server's knowledge from everything to 95%.BWS (Bitcore Wallet Service) is described as a platform that coordinates transaction proposals in multisignature wallets, stores BIP32 derivation indexes, accesses the blockchain, and provides functions like `getBalance` and `getTxHistory` to peers. It aims to provide an easy setup while ensuring privacy and security. The evaluation of BWS not having extended public keys reveals that it would have no way to verify addresses sent by peers, which could lead to broken functions like `getBalance` or `txHistory`. However, Gregory Maxwell has proposed a schema that may address this issue using "not extended" pubkeys, but further evaluation is needed.Bitcore-wallet-server (BWS) is identified as a facilitator for HD (Hierarchical Deterministic) multisig wallets. Currently, BWS instances hold the set of extended public keys of the wallet's peers to derive addresses. The concern raised is that this poses a privacy issue. To mitigate this concern, the suggestion is made to use pseudo-random BIP32 paths with a seed known only by the peers. This way, the server can verify submitted addresses without being able to derive future wallet addresses. The proposed approach involves giving the server the master pubkey P without the chaincode and generating addresses in a manner determined by the user. The server then computes the address based on the provided scalar value iL and checks for agreement. This approach is considered more private than sharing the chain code and is compatible with hardened derivation.The developers of bitcore-wallet-server (BWS) are seeking feedback on their usage of BIP32 paths. Currently, BWS instances hold the extended public keys of the wallet's peers to derive addresses, which raises privacy concerns. To address this, the team proposes using pseudo-random BIP32 paths with a seed known only by the peers. This would allow the server to verify addresses without being able to derive future wallet addresses. The proposed workflow involves the peer requesting the current index and creating an address using the index and pathSeed. The server then derives the address and adds it to the wallet.
Updated on: 2023-08-01T12:01:12.193147+00:00