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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
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 <gronager@ceptacle.com>) id 1Rss5s-0002lr-LA
for bitcoin-development@lists.sourceforge.net;
Thu, 02 Feb 2012 08:32:36 +0000
X-ACL-Warn:
Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49]
helo=mail.ceptacle.com)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Rss5o-0004bB-Ad for bitcoin-development@lists.sourceforge.net;
Thu, 02 Feb 2012 08:32:36 +0000
Received: from localhost (localhost [127.0.0.1])
by mail.ceptacle.com (Postfix) with ESMTP id 929731696A2A;
Thu, 2 Feb 2012 09:32:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id s2yDxW1llbDu; Thu, 2 Feb 2012 09:32:25 +0100 (CET)
Received: from [10.0.1.28] (2508ds5-oebr.0.fullrate.dk [95.166.54.49])
by mail.ceptacle.com (Postfix) with ESMTPSA id 5B5E81696A1A;
Thu, 2 Feb 2012 09:32:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com>
Date: Thu, 2 Feb 2012 09:32:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com>
References: <D55C3D18-8286-44E9-B877-6FCE7C05E980@ceptacle.com>
<CAJna-HiS34V5rNrRfFOMRJ6JhRmS1aeEE3oA=o07Hgf4S6qNfw@mail.gmail.com>
<54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com>
<CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com>
To: grarpamp <grarpamp@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Rss5o-0004bB-Ad
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: Thu, 02 Feb 2012 08:32:36 -0000
I agree on your architectural considerations - and with libcoin you can =
have several wallets in the same application ( and several RPC servers =
for that matter). And ... they all use the same Node / blockchain.
You will also find the RPC server in libcoin blistering fast compared to =
the Satoshi client. (It was actually what got me to write libcoin in the =
first place...). The Satoshi client HTTP server executes all rpc =
commands in its own thread, but to do so, it needs to stop the thread of =
the Node, even though the command executed is just a query (i.e. not a =
SendTo), you hence have two threads blocking each other and when they =
wait, you wait... In libcoin all the query methods access the blockChain =
as a const object and they can hence safely query it without intervening =
the work of the Node thread. The exception are the SendTo methods that =
first query if a transaction can take place, then pushes it to the =
work-queue of the Node thread and again exits immediately. The actual =
execution then follows once the Node has finished its current tasks =
(e.g. validating a block).
I have attached the code for a very simple one node, two wallet, libcoin =
client below (~30 lines), and I have added it to the libcoin source as =
an example (example name: extrawallets).
Once running, you can access your extra wallet using the RPC interface:
./extrawallet extragetbalance
And youy normal wallet by:
./extrawallet getbalance
I'll leave the generalization to an n-wallet gui application to the =
reader ;)
Cheers,
Michael
....
// The derived classes below are only to get other class names (using =
the auto rpc name feature)
// I will put adding a "setName" method to the Method class on the todo.=20=
class ExtraGetBalance : public GetBalance {
public:
ExtraGetBalance(Wallet& wallet) : GetBalance(wallet) {}
};
class ExtraSendToAddress : public GetBalance {
public:
ExtraSendToAddress(Wallet& wallet) : GetBalance(wallet) {}
};
int main(int argc, char* argv[])
{ =20
logfile =3D CDB::dataDir(bitcoin.dataDirSuffix()) + "/debug.log";
Node node; // deafult chain is bitcoin
Wallet wallet(node, "wallet.dat"); // add the wallet
Wallet extra_wallet(node, "extra_wallet.dat"); // add the extra =
wallet
thread nodeThread(&Node::run, &node); // run this as a background =
thread
Server server;
// Register Server methods.
server.registerMethod(method_ptr(new Stop(server)));
// Register Node methods.
server.registerMethod(method_ptr(new GetBlockCount(node)));
server.registerMethod(method_ptr(new GetConnectionCount(node)));
server.registerMethod(method_ptr(new GetDifficulty(node)));
server.registerMethod(method_ptr(new GetInfo(node)));
// Register Wallet methods. - note that we don't have any auth, so =
anyone (on localhost) can read your balance!
server.registerMethod(method_ptr(new GetBalance(wallet)));
server.registerMethod(method_ptr(new SendToAddress(wallet)), =
Auth("username","password"));
server.registerMethod(method_ptr(new ExtraGetBalance(wallet)));
server.registerMethod(method_ptr(new ExtraSendToAddress(wallet)), =
Auth("username","password"));
server.run();
node.shutdown();
nodeThread.join();
}
On 02/02/2012, at 00:50, grarpamp wrote:
>> 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.
>=20
> 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...
>=20
> 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.
>=20
> 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.
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager@ceptacle.com
Web: http://www.ceptacle.com/
|
