Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of mac.com
	designates 17.158.236.236 as permitted sender)
	client-ip=17.158.236.236; envelope-from=gronager@mac.com;
	helo=nk11p04mm-asmtp001.mac.com; 
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Michael Gronager <gronager@mac.com>
In-reply-to: <20130723093759.GB6198@vps7135.xlshosting.net>
Date: Tue, 23 Jul 2013 11:53:07 +0200
Content-transfer-encoding: quoted-printable
Message-id: <7B546311-BBC6-45CB-8983-87DF722F0FA1@mac.com>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
	<kslep0$hq7$1@ger.gmane.org>
	<20130723093759.GB6198@vps7135.xlshosting.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Precedence: list

>=20
> The only way to do this safely at an SPV security assumption, is by
> having an address-indexed committed merkle UTXO-set tree, like the
> one proposed by Alan Reiner, and being implemented by Mark
> Friedenback. I know Michael Gronager has something similar =
implemented,
> but I don't know whether it is script-indexed.

The MerkleTrie I have in libcoin is indexed on UTXOs only. However, =
adding
an extra index for scripts would be pretty easy (half day of coding), or =
even having the two merged into one index.

The burden imposed on validating nodes for keeping such an index is =
really minimal. When using the UTXO MerkleTrie I switch off the sqlite =
index of these and vise versa, so there are hardly any measurable timing =
difference.

However, the MerkleTrie index is currently re-build on startup (which =
takes ~30 sec on my laptop), keeping it synced with disk would be =
optimal and in the long run necessary as even the UTXO set will grow =
over time.

> To be actually useful,
> it likely needs to be enforced by miners - putting a significant
> burden on validation nodes. Still, if it can be done efficiently,
> I think this would be worth it, but more research is needed first in
> any case.
>=20