1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CA+vKqYfNLvuQH2CEcgvJqPPOYg=1M6=1sTPm65xec7vdzTgP_A@mail.gmail.com>
References: <CA+vKqYfG=SoNAgTeD0C_Q7F2p6MWdWE90u7728g9s3=nkmNi4w@mail.gmail.com>
<CANEZrP0t0oXGz6uXaLrGHFKUeRNFBC_MKr7x3uTH3WPkTbe5tQ@mail.gmail.com>
<CA+vKqYfNLvuQH2CEcgvJqPPOYg=1M6=1sTPm65xec7vdzTgP_A@mail.gmail.com>
Date: Fri, 13 Mar 2015 11:04:57 -0700
X-Google-Sender-Auth: Lt5FJCgWMakvd24AKKyKSyHLjMw
Message-ID: <CANEZrP1a_hqkZSfnWbfzJj2Y7Z0yptUOuH5iFG=CB5hwjWG3Ew@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matias Alejo Garcia <matias@bitpay.com>
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 <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP32 Index Randomisation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<div dir=3D"ltr"><div class=3D"gmail_extra">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).</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">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.</div></=
div>
--089e0111b8fa9ed3f005112f5679--
|
