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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WzOuv-00087F-9F
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jun 2014 11:29:37 +0000
Received: from mail-lb0-f180.google.com ([209.85.217.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WzOut-00048Y-Ep
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Jun 2014 11:29:37 +0000
Received: by mail-lb0-f180.google.com with SMTP id w7so207213lbi.25
for <bitcoin-development@lists.sourceforge.net>;
Tue, 24 Jun 2014 04:29:28 -0700 (PDT)
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=suRpkhIDaabKPzCyXbwRqdygx35wyeu6guqPmiRuDUI=;
b=g1z1ngt92PrJbezyKfHEDVo6oK+/F0pbkqb/wISHyJLybX2R/0lNgjeh+5mypFgLmY
sTbvdTcbS5xl0lz/cI1Wfudm3AsbeIKJt4kIiaEcpjK/yKjN7N67Voblz57AKWK676F6
fLg2JP1YHIAZlsVe2k14PRGueufiQQJRurBXZPeUfzCO2IdrkOXjRSBncpo7odMg+KRq
98Av30KSczMJUr0bPXg6AFhmCC2w3uz/bG1/0Crgdc+omLV/8aTSd6iq+GiT1gylOm4b
vPtNWDD9N1taRMOClyzMO+z5tQhWv62K7BlgSnoRdyLpmcOyGYyAWU6ccnkYhCGyqgvD
sVBA==
X-Gm-Message-State: ALoCoQnIpECntCjPlRSAdX8yk1z6NFp4zuRnr0V9HWZeC972lCu40k9G1ADIWCXXYwRoosyb4VTj
MIME-Version: 1.0
X-Received: by 10.112.97.163 with SMTP id eb3mr152970lbb.67.1403609368468;
Tue, 24 Jun 2014 04:29:28 -0700 (PDT)
Received: by 10.112.185.4 with HTTP; Tue, 24 Jun 2014 04:29:28 -0700 (PDT)
X-Originating-IP: [85.53.135.230]
In-Reply-To: <CANEZrP1bNs4ahMzd7AfSH3P39Cx1rkmCkjnOMOM9T2Anr5wVOw@mail.gmail.com>
References: <CAC1+kJNjcPkaHiR8mzofwXE4+4UX5nmxX5Q3rZv37v-K40p1Tw@mail.gmail.com>
<CA+s+GJDVBQVu8yH9jLu_rQmk=dsJuMUctT-iK0zzOJRYgE8k9w@mail.gmail.com>
<CAC1+kJOQ2uBo2peYKZJyPSQL6qzk6Yu-cF-tPs3GzVS6cAc53w@mail.gmail.com>
<CANEZrP1bNs4ahMzd7AfSH3P39Cx1rkmCkjnOMOM9T2Anr5wVOw@mail.gmail.com>
Date: Tue, 24 Jun 2014 13:29:28 +0200
Message-ID: <CAC1+kJMn3p5H6A8GGiuF56d411zC4qsTomuy7A5e0+OQT78FGQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WzOut-00048Y-Ep
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Plans to separate wallet from core
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: Tue, 24 Jun 2014 11:29:37 -0000
On 6/24/14, Mike Hearn <mike@plan99.net> wrote:
> bitcoind already supports SPV mode, that's how bitcoinj clients work.
> However the current wallet code doesn't use it, it integrates directly with
> the full mode main loop and doesn't talk P2P internally. Which is the fine
> and obvious way to implement the wallet feature. I'm not totally convinced
> it should become an SPV wallet given the complexity of doing that. But if
> you did want to separate the wallet code from the full node then that'd be
> the way to do it.
>
> The question is; what does this buy us, and is it worth the potentially
> huge amount of time it could take? My gut feeling is we have bigger fish to
> fry. There's plenty of work to do just on the core consensus code, making
> Bitcoin Core into a competitive wallet as well would be an additional
> burden.
Exactly, this is part of my point, the qt-wallet does not support SPV
operation at this point, and that complex work should be done after
the wallet is separated. Thus the first version of the separated
wallet should be functionally equivalent to today's wallet, that is, a
full node wallet (even though I understand Wladimir's arguments
against full-node wallets).
>> I'm sorry, but I still don't know what Electrum has to do with all this.
>>
>
> People use Electrum as shorthand to mean "something a bit like the P2P
> network, but with trusted remote servers which build additional databases
> and thus support additional commands".
Ok, thanks. So a bitcoin core node which maintains and serves
additional indexes (say, an utxo index via rpc or something else) is
referred to as "an electrum" even though it doesn't use
electrum-server. Strange, but now I get it.
So in summary:
1) I accept the library approach over the "core-wallet protocol".
2) That doesn't necessarily mean that optionally maintaining
additional indexes in the core is not interesting for some use cases
(interesting for bitcoind, I don't care much if electrum-server
currently does this and more [with more dependencies]). Although
Pieter thinks that should also be separated into an "index node" too,
but I think that's another discussion.
3) The wallet doesn't currently operate as SPV and that work should be
done (if there's enough interest) only after the wallet is separated
from the core.
|
