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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <grarpamp@gmail.com>) id 1RsjxA-0002ZQ-Rq
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Feb 2012 23:51:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=grarpamp@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RsjxA-00070y-1i
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Feb 2012 23:51:04 +0000
Received: by wibhq7 with SMTP id hq7so2067954wib.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 01 Feb 2012 15:50:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.103.97 with SMTP id fv1mr940706wib.17.1328140257903; Wed,
01 Feb 2012 15:50:57 -0800 (PST)
Received: by 10.180.103.227 with HTTP; Wed, 1 Feb 2012 15:50:57 -0800 (PST)
In-Reply-To: <54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com>
References: <D55C3D18-8286-44E9-B877-6FCE7C05E980@ceptacle.com>
<CAJna-HiS34V5rNrRfFOMRJ6JhRmS1aeEE3oA=o07Hgf4S6qNfw@mail.gmail.com>
<54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com>
Date: Wed, 1 Feb 2012 18:50:57 -0500
Message-ID: <CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= <gronager@ceptacle.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(grarpamp[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1RsjxA-00070y-1i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Announcement: libcoin
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, 01 Feb 2012 23:51:04 -0000
> However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this.
I'll be trying your implementation soon. And libbitcoin/subvertx too.
Partly because they're also non-interpreted, and partly to what seems
better architected...
To the minimal extent of my understanding... I'd like to see wallet
ops completely separated from background chain ops. ie: have
a chain daemon doing it's thing, updating, verifying, etc. The
generator doing it's thing. And a wallet app that can independently
manage separate wallets in parallel, referencing the live chain files
as needed. It seems a library would allow quality focus on the separate
functions and let apps/ui's use the fn's as desired on top. Right now, it
seems I have to run bitcoind and can only deal with one wallet at a time,
having to stop it, deal with state issues, swap in a new wallet, start
it, and repeat till illness ensues :( And when the chain is being processed
hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever
or errors out. If wallet ops or statistical queries on the chain need it for
integrity or reading, a db checkpoint/lock/logroll could be implemented into
the chain demon processes with a client lib api to trigger it as needed.
Don't know, just saying.
fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master,
you just need to compile and include it by hand if you want it and
your package manager doesn't have it.
|
