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
|
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 <mh.in.england@gmail.com>) id 1SbBct-0001Mn-HM
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Jun 2012 14:17:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SbBcq-0002wt-PG
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Jun 2012 14:17:51 +0000
Received: by wibhn6 with SMTP id hn6so1723093wib.10
for <bitcoin-development@lists.sourceforge.net>;
Sun, 03 Jun 2012 07:17:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.135.146 with SMTP id u18mr8579957wei.5.1338733062669; Sun,
03 Jun 2012 07:17:42 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.26.140 with HTTP; Sun, 3 Jun 2012 07:17:42 -0700 (PDT)
In-Reply-To: <4FCA33EB.5030706@gmail.com>
References: <4FCA33EB.5030706@gmail.com>
Date: Sun, 3 Jun 2012 16:17:42 +0200
X-Google-Sender-Auth: xd-2Q2ddEjslUUxXKEXMUyorniY
Message-ID: <CANEZrP2sDD0MhO5xHB==N-oCtChXJwDBa79X07MENFa_ZjqpFQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=001636eeeb98a6464004c1921418
X-Spam-Score: -0.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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1SbBcq-0002wt-PG
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Full Clients in the future - Blockchain
management
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: Sun, 03 Jun 2012 14:17:51 -0000
--001636eeeb98a6464004c1921418
Content-Type: text/plain; charset=UTF-8
Yeah, for actually storing transactions the approach Satoshi uses of
relying on a database engine makes sense and is what the code already does,
so I'm not sure why this is a problem.
The real problem with Satoshis code for scaling down to smaller devices
(and one day desktops too) is the need to store all the chain headers in
RAM. BitcoinJ avoids this but just creates more problems for itself in
other places, partly because we also try to avoid a database engine
(read/write traffic on phones can be insanely expensive, especially on
older ones, and so sqlite is known to be a serious cause of performance
pain on android apps).
--001636eeeb98a6464004c1921418
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yeah, for actually storing transactions the approach Satoshi uses of relyin=
g on a database engine makes sense and is what the code already does, so I&=
#39;m not sure why this is a problem.<div><br></div><div>The real problem w=
ith Satoshis code for scaling down to smaller devices (and one day desktops=
too) is the need to store all the chain headers in RAM. BitcoinJ avoids th=
is but just creates more problems for itself in other places, partly becaus=
e we also try to avoid a database engine (read/write traffic on phones can =
be insanely expensive, especially on older ones, and so sqlite is known to =
be a serious cause of performance pain on android apps).</div>
--001636eeeb98a6464004c1921418--
|
