Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YWTxb-0005yn-CV for bitcoin-development@lists.sourceforge.net; Fri, 13 Mar 2015 18:05:23 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.172 as permitted sender) client-ip=209.85.223.172; envelope-from=mh.in.england@gmail.com; helo=mail-ie0-f172.google.com; Received: from mail-ie0-f172.google.com ([209.85.223.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YWTxZ-0007sz-G9 for bitcoin-development@lists.sourceforge.net; Fri, 13 Mar 2015 18:05:23 +0000 Received: by ieclw3 with SMTP id lw3so118516350iec.2 for ; Fri, 13 Mar 2015 11:05:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr114508348igc.40.1426269897935; Fri, 13 Mar 2015 11:04:57 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.36.54.147 with HTTP; Fri, 13 Mar 2015 11:04:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Mar 2015 11:04:57 -0700 X-Google-Sender-Auth: Lt5FJCgWMakvd24AKKyKSyHLjMw Message-ID: From: Mike Hearn To: Matias Alejo Garcia Content-Type: multipart/alternative; boundary=089e0111b8fa9ed3f005112f5679 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YWTxZ-0007sz-G9 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP32 Index Randomisation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 18:05:23 -0000 --089e0111b8fa9ed3f005112f5679 Content-Type: text/plain; charset=UTF-8 It sounds like the main issue is this is a web wallet server of some kind. If the clients were SPV then they'd be checking their own balances and downloading their own tx history, which would mean the coordination tasks could be done by storing encrypted blobs on the server rather than the server itself having insight into what's going on (see: Subspace). So whilst you might be able to use some scheme to avoid the server knowing the xpubkey, if the server still knows all addresses and all transactions because the clients are web wallets ..... is there any point? It seems like maybe going from server knows everything to server knows 95% of everything: maybe not worth the engineering cost. --089e0111b8fa9ed3f005112f5679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It sounds like the main issue i= s this is a web wallet server of some kind. If the clients were SPV then th= ey'd be checking their own balances and downloading their own tx histor= y, which would mean the coordination tasks could be done by storing encrypt= ed blobs on the server rather than the server itself having insight into wh= at's going on (see: Subspace).

So whilst you might be able to use some scheme= to avoid the server knowing the xpubkey, if the server still knows all add= resses and all transactions because the clients are web wallets ..... is th= ere any point? It seems like maybe going from server knows everything to se= rver knows 95% of everything: maybe not worth the engineering cost.
--089e0111b8fa9ed3f005112f5679--