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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8CBE9FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 11:03:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E99E143
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 11:03:16 +0000 (UTC)
Received: by ioeg141 with SMTP id g141so197919330ioe.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 04:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=wnKHPxF/A2ZNKbF8HTItXynxhBM5ITpKDveeLrzHrzY=;
b=Q/g/CDKpoKE72ZLGWixihDrI3NQzFhT8sU03WgHWbu5sF9rnzzoDjgZWqFlvC00thQ
UftK08oz5JM02unalV5tlOREK6q9XXNM7DAdrY2sdfxLzeT9F9EMiuzkEb/O4inmvlsL
xtGBends5+OMZZ1PyR4zvFPTfBk6IzgVSyadU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=wnKHPxF/A2ZNKbF8HTItXynxhBM5ITpKDveeLrzHrzY=;
b=PBG4j3R5nwMRTCiNbyQzu04oDnzcRiXADflbqMoqLocuUTbSYduFVDkWZ4lILSshq0
ylFviPl5qU7bQKhcbsM149Nbp70Fbvi+kgZNsm11qiQjgMOz1sEr36DMtIO5hAagi7zy
5TDo3BF5sEQDrNrioIX2W/H1/9I+pHtCBC8auLrpzUxdoZim4KnnNv5F6VtdOeeYBX+Y
SRzaL2sb/p5leF2yrChIqISUgvFZuQ9Jok5Wk3M6a3BppdOAElc97K4e4E7NMFMwPchr
9bqc8nnBv27hOMAIcSudWDB0B0BZTw1QGTpfT36q1CsMPJDxhkJvstRPHegJa9nrS4fz
uddw==
X-Gm-Message-State: ALoCoQn385JmGVvAnOL9cvIRwESuv0OHZfwElluAsCoCWqVWgcmC18RR+xrmAEpyo4CncObcbJOo
MIME-Version: 1.0
X-Received: by 10.107.157.133 with SMTP id g127mr27432342ioe.102.1439290995315;
Tue, 11 Aug 2015 04:03:15 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Tue, 11 Aug 2015 04:03:15 -0700 (PDT)
In-Reply-To: <55C9BA0F.60408@jonasschnelli.ch>
References: <55C9BA0F.60408@jonasschnelli.ch>
Date: Tue, 11 Aug 2015 13:03:15 +0200
Message-ID: <CA+w+GKR1BNpVk4SAKExrkGDMzb+BQfinpmWGbNiMyM89DnzOFA@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/alternative; boundary=001a1140c7a0812371051d070c9c
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2015 11:03:17 -0000
--001a1140c7a0812371051d070c9c
Content-Type: text/plain; charset=UTF-8
Hey Jonas,
I think your analysis of what (some) users need is a good one.
We've discussed this before so I know you prefer your current approach, but
I personally would take a slightly different path to reach the same end:
1. Support serving of SPV wallets from pruned storage. This means some
protocol upgrades, BIPs, etc. It helps all SPV wallets, including on phones.
2. Then make a bitcoinj based desktop wallet app, that contains a
bundled bitcoind.
3. Make the app sync TWO wallets simultaneously, one from the P2P
network as today, and another from the local bitcoind via a local socket
(or even just passing buffers around internally)
4. The app should then switch from using the wallet synced to P2P to the
wallet synced to localhost when the latter is fully caught up, and back
again when the local node is behind.
5. If there's a discrepancy, alert the user.
There are big advantages of taking this path! They are:
- The switching back and forth between local full-security mode (which
may be behind) and remote SPV security (fully synced) is instant and
transparent to the user. This is important for laptop users who don't run a
local node all the time. The different audit levels can be reflected in the
UI in some way.
- The bitcoinj wallet code already has support for things like
multi-sig, BIP32, seed words, micropayment channels, etc. You can disable
Bloom filtering if you like (download full blocks).
- You can do a local RPC or JNI/JNA call to get fee estimates, if wanted.
- The modern JVM tools and languages are much, much more productive than
working with C++.
If you want a thing that runs a home server, then the best way to do that
IMO would be to bundle Tor and make it auto-register a Tor hidden service.
Then you can just define a QR code standard for 'pairing' a wallet to a
.onion address. Any bitcoinj based wallet can sync to it, and as it's your
own node, you can use a Bloom filter sized to give virtually no false
positives. No additional indexing is then required.
--001a1140c7a0812371051d070c9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Jonas,<div><br></div><div>I think your analysis of wha=
t (some) users need is a good one.</div><div><br></div><div>We've discu=
ssed this before so I know you prefer your current approach, but I personal=
ly would take a slightly different path to reach the same end:</div><div><o=
l><li>Support serving of SPV wallets from pruned storage. This means some p=
rotocol upgrades, BIPs, etc. It helps all SPV wallets, including on phones.=
</li><li>Then make a bitcoinj based desktop wallet app, that contains a bun=
dled bitcoind.</li><li>Make the app sync TWO wallets simultaneously, one fr=
om the P2P network as today, and another from the local bitcoind via a loca=
l socket (or even just passing buffers around internally)</li><li>The app s=
hould then switch from using the wallet synced to P2P to the wallet synced =
to localhost when the latter is fully caught up, and back again when the lo=
cal node is behind.</li><li>If there's a discrepancy, alert the user.</=
li></ol><div>There are big advantages of taking this path! They are:</div><=
/div><div><ul><li>The switching back and forth between local full-security =
mode (which may be behind) and remote SPV security (fully synced) is instan=
t and transparent to the user. This is important for laptop users who don&#=
39;t run a local node all the time. The different audit levels can be refle=
cted in the UI in some way.<br><br></li><li>The bitcoinj wallet code alread=
y has support for things like multi-sig, BIP32, seed words, micropayment ch=
annels, etc. You can disable Bloom filtering if you like (download full blo=
cks).<br><br></li><li>You can do a local RPC or JNI/JNA call to get fee est=
imates, if wanted.<br><br></li><li>The modern JVM tools and languages are m=
uch, much more productive than working with C++.</li></ul><div><br></div></=
div><div>If you want a thing that runs a home server, then the best way to =
do that IMO would be to bundle Tor and make it auto-register a Tor hidden s=
ervice. Then you can just define a QR code standard for 'pairing' a=
wallet to a .onion address. Any bitcoinj based wallet can sync to it, and =
as it's your own node, you can use a Bloom filter sized to give virtual=
ly no false positives. No additional indexing is then required.</div></div>
--001a1140c7a0812371051d070c9c--
|
