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 ) 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?= In-Reply-To: Date: Thu, 2 Feb 2012 09:32:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com> References: <54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com> To: grarpamp 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 Subject: Re: [Bitcoin-development] Announcement: libcoin X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/