From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXy7b-0002VA-Ns for bitcoin-development@lists.sourceforge.net; Wed, 09 Apr 2014 19:25:19 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.170 as permitted sender) client-ip=209.85.223.170; envelope-from=laanwj@gmail.com; helo=mail-ie0-f170.google.com; Received: from mail-ie0-f170.google.com ([209.85.223.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WXy7a-0003zj-Tm for bitcoin-development@lists.sourceforge.net; Wed, 09 Apr 2014 19:25:19 +0000 Received: by mail-ie0-f170.google.com with SMTP id rd18so2943384iec.1 for ; Wed, 09 Apr 2014 12:25:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.60.103 with SMTP id g7mr6515799igr.20.1397071513621; Wed, 09 Apr 2014 12:25:13 -0700 (PDT) Received: by 10.64.70.131 with HTTP; Wed, 9 Apr 2014 12:25:13 -0700 (PDT) In-Reply-To: <534570A2.9090502@gmx.de> References: <534570A2.9090502@gmx.de> Date: Wed, 9 Apr 2014 21:25:13 +0200 Message-ID: From: Wladimir To: Thomas Voegtlin Content-Type: multipart/alternative; boundary=047d7b1117c14b99f704f6a10f14 X-Spam-Score: -0.6 (/) 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 (laanwj[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 X-Headers-End: 1WXy7a-0003zj-Tm Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:25:19 -0000 --047d7b1117c14b99f704f6a10f14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 9, 2014 at 6:09 PM, Thomas Voegtlin wrote: > Le 09/04/2014 17:54, Gregory Maxwell a =C3=A9crit : > > > 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) > Thanks for the explanation. Adding a RPC call for a "address -> utxo" query wouldn't be a big deal. It has been requested before for other purposes as well, all the better if it helps for interaction with Electrum. Spent history would be involve a much larger index, and it's not likely that will end up in bitcoin Wladimir --047d7b1117c14b99f704f6a10f14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Apr 9, 2014 at 6:09 PM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
Le 09/04/2014 17:54, Gregory Maxwell a =C3= =A9crit :

> 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<= br> > unmodified without the resource usage increasing route)
>

Electrum uses two large indexes:

=C2=A0 =C2=A0 =C2=A0address -> utxo

(patricia tree, aka "ultimate blockchain compression", see thread=
started by Alan Reiner in the bitcointalk forum)

<= /div>
Thanks for the explanation.

Adding a RPC call= for a "address -> utxo" query wouldn't be a big deal. It = has been requested before for other purposes as well, all the better if it = helps for interaction with Electrum.

Spent history would be = involve a much larger index, and it's not likely that will end up in bi= tcoin

Wladimir

--047d7b1117c14b99f704f6a10f14--