Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.174 as permitted sender)
	client-ip=209.85.223.174; envelope-from=ematiu@gmail.com;
	helo=mail-ie0-f174.google.com; 
MIME-Version: 1.0
Sender: ematiu@gmail.com
In-Reply-To: <CANEZrP0t0oXGz6uXaLrGHFKUeRNFBC_MKr7x3uTH3WPkTbe5tQ@mail.gmail.com>
References: <CA+vKqYfG=SoNAgTeD0C_Q7F2p6MWdWE90u7728g9s3=nkmNi4w@mail.gmail.com>
	<CANEZrP0t0oXGz6uXaLrGHFKUeRNFBC_MKr7x3uTH3WPkTbe5tQ@mail.gmail.com>
From: Matias Alejo Garcia <matias@bitpay.com>
Date: Fri, 13 Mar 2015 15:01:03 -0300
Message-ID: <CA+vKqYfNLvuQH2CEcgvJqPPOYg=1M6=1sTPm65xec7vdzTgP_A@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP32 Index Randomisation
Precedence: list

> Could you describe what exactly BWS does?

Sure. BWS tasks are:

* Coordinate Transaction proposals in multisignature wallets:  provide
an 'always connected' node to distribute pending transaction proposals
 and receive the signatures from peers.
* Coordinate and store BIP32 derivation indexes. (If the BWS
disappear, peer can still access the funds by scanning the blockchain,
but having the index in a common accessable point in useful).
* Access the blockchain and provide functions like: `getBalance` and
`getTxHistory` to peers.
* Allow agents to notify incoming funds / or transaction proposals to peers.

BWS is designed to be extremely easy to setup and run. BitPay will
provide a public BWS instance, but companies and individuals can run
their own for privacy and security reasons.

> It sounds like the server doesn't have to actually derive the keys itself for any particular purpose
> beyond knowing the addresses are a part of the wallet. Could the server work if it didn't even
> know that, and was just a bucket of arbitrary addresses with the clients themselves deriving the
> addresses?

We have evaluated  BWS  not having the extended public keys (and it is
still an open possibility) but the main drawback we found is that BWS
will have no way to verify addresses sent by the peers (*).

A peer could send a fake address to BWS and then functions like
'getBalance' or 'txHistory' will be broken. Of course, the peers could
verify the addresses on getTxHistory or getBalance (by Address) but we
also want to allow thin-clients and agents with lower level of trust
(than the server) that can notify the wallet balance and incoming
transaction to peers using, for example, mobile push notifications.

(*):  Gregory Maxwell proposed an schema for doing this with the "not
extended" pubkeys, that we need to evaluate. That could be the best
solution.