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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1WXv3p-0006o6-Bw
for bitcoin-development@lists.sourceforge.net;
Wed, 09 Apr 2014 16:09:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.17.21 as permitted sender)
client-ip=212.227.17.21; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.17.21])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WXv3o-0005yT-Bx
for bitcoin-development@lists.sourceforge.net;
Wed, 09 Apr 2014 16:09:13 +0000
Received: from [192.168.1.27] ([84.101.32.222]) by mail.gmx.com (mrgmx103)
with ESMTPSA (Nemesis) id 0LoVja-1XEOgl3jvm-00gb6f for
<bitcoin-development@lists.sourceforge.net>;
Wed, 09 Apr 2014 18:09:06 +0200
Message-ID: <534570A2.9090502@gmx.de>
Date: Wed, 09 Apr 2014 18:09:06 +0200
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com> <CAAt2M18z_Qkqat1OETiXAz0QQey4+y5J6=pC7nkoJfyfrpj3=A@mail.gmail.com>
<CAAS2fgScWkentFy7Ak0bpYVLsOFL+xkwPm5QRu9ENeX9oCtPug@mail.gmail.com>
In-Reply-To: <CAAS2fgScWkentFy7Ak0bpYVLsOFL+xkwPm5QRu9ENeX9oCtPug@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:Qgr6NsUMnhQZYCzl+sQHzoKKGToiSaASQ6k/YDWlzP1e7Ttlr7E
9iq7Fft7Dy0JZpW4PgOjGztwfNkNze45Ep2OOZ5h3d/GZ2OyXJQYn3Erk0K5SyqLGkpfmvF
4bYqo9iEYENr0PbVlN/qbU2nFlVhGhD6onIa8/AXUfBOjU31O7BMKQjMzhcCJWUwIoeZc9I
7xk99mjDtdA2auOcnS65g==
X-Spam-Score: -1.2 (-)
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
(thomasv1[at]gmx.de)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (thomasv1[at]gmx.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.21 listed in list.dnswl.org]
X-Headers-End: 1WXv3o-0005yT-Bx
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV
wallets
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: Wed, 09 Apr 2014 16:09:13 -0000
Le 09/04/2014 17:54, Gregory Maxwell a écrit :
> Sadly today Electrum requires more than a full node, it requires a
> number of large additional indexes over what a full node has and
> pruning is precluded. I don't think that increasing the resource
> utilization of the node is a good way to go there for the purposes
> expressed here. (not that electrum couldn't be used here, but not
> unmodified without the resource usage increasing route)
>
Electrum uses two large indexes:
address -> utxo
(patricia tree, aka "ultimate blockchain compression", see thread
started by Alan Reiner in the bitcointalk forum)
address -> spent history
The first index is not going to grow larger than what bitcoind already
needs to store, because bitcoind will always need to store utxos.
The second index threatens to become large. However, Electrum servers do
not keep the full histories, they prune older entries. Without adapting
Electrum clients, it would even be possible to keep only one bit per
address (to know whether that address has been used or not), and that
information is only used to restore wallets from seed, not during normal
operations.
If the first index (patricia tree) was implemented in bitcoind, that
would obviously be a big relief for electrum servers.
>> and that it might be an easier way to support
>> SPV clients than creating a new API in bitcoind for it since Stratum
>> itself already relies on bitcoind to provide it's services.
>
> Bitcoin's own P2P protocol is already the API for a ordinary SPV
> client. So I don't believe any new API would be require, except
> perhaps for some process management stuff (which also isn't provided
> for Electrum).
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
|
