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
97
98
99
100
101
|
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 <ematiu@gmail.com>) id 1YWTtw-0005gd-MP
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 18:01:36 +0000
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;
Received: from mail-ie0-f174.google.com ([209.85.223.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWTtv-0007g7-CK
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 18:01:36 +0000
Received: by iecvj10 with SMTP id vj10so114247635iec.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Mar 2015 11:01:30 -0700 (PDT)
X-Received: by 10.107.163.65 with SMTP id m62mr51255887ioe.40.1426269683574;
Fri, 13 Mar 2015 11:01:23 -0700 (PDT)
MIME-Version: 1.0
Sender: ematiu@gmail.com
Received: by 10.50.33.74 with HTTP; Fri, 13 Mar 2015 11:01:03 -0700 (PDT)
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
X-Google-Sender-Auth: qVG27iH3lGBFfOArB_Rgeh_Owv0
Message-ID: <CA+vKqYfNLvuQH2CEcgvJqPPOYg=1M6=1sTPm65xec7vdzTgP_A@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.1 (-)
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
(ematiu[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YWTtv-0007g7-CK
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:01:36 -0000
> 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.
|
