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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@mac.com>) id 1V1ZHU-0007Ku-8d
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 09:53:20 +0000
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;
Received: from nk11p04mm-asmtp001.mac.com ([17.158.236.236])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V1ZHR-0006Jf-0f for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 09:53:20 +0000
Received: from [10.6.0.99]
(cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net [188.180.67.254])
by nk11p04mm-asmtp001.mac.com
(Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit
(built Jul
13 2012)) with ESMTPSA id <0MQD00E2YVGK2QD0@nk11p04mm-asmtp001.mac.com>
for bitcoin-development@lists.sourceforge.net; Tue,
23 Jul 2013 09:53:11 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.10.8794,1.0.431,0.0.0000
definitions=2013-07-23_03:2013-07-22, 2013-07-23,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0
classifier=spam
adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000
definitions=main-1307230027
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>
X-Mailer: Apple Mail (2.1508)
X-Spam-Score: -1.5 (-)
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
(gronager[at]mac.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1V1ZHR-0006Jf-0f
Cc: bitcoin-development@lists.sourceforge.net,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
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, 23 Jul 2013 09:53:20 -0000
>=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
|
